Devinを企業で使い始めたら困った話

多くの記事で、Cursor、Cline、DevinといったAIツールを用いた開発効率UPが書かれています。
自分の会社ではCursorとDevinを使用していて、Cursorについては文句なく有用である一方、Devinはいくつか負の影響をもたらしていることに気づいたので、以下のその内容をまとめます。

なおDevinに問題があるわけではなく、Devinを使う人/組織側の問題です。

エンジニアじゃないのにPR出してマージさせないで

社内の割と多くの人が、Devinのことを「非エンジニアでも開発することができる」キントーンのようなものと考えている人がいて、製品で生じたエラーについてDevinに修正を依頼した上に、PRをマージさせたケースがありました。^[1]
その結果、Devinが新しいバグを発生させていることに気が付かずリリースしてしまい、なぜか自分が担当した部分で、前までなかったバグが発生したとアラートが飛んでくることに😇

Devin公式ページを開くと出てくる紹介文の通り、Devinはエンジニアチームの活躍を大いに支援してくれるチームメイトであって、非エンジニアの希望をかなえてくれるドラえもんではありません。

Devin
is a collaborative
AI teammate

Built to help ambitious engineering teams achieve more.

「壊れました」「エラーを直してください」といったプロンプトで無駄にDevinを消費しないで

非エンジニアの人で、「Aの処理が失敗しました。エラーコードはerror001と出ていて、ログインユーザーはhogeです。原因を確認してください」という処理をDevinに出した結果、当てにならない回答が返ってきたのに対し繰り返し同様の粒度の低い質問を繰り返し、Devinのメモリ使用量を無駄に使っていたことが最近発覚しました。
DevinというかAIを用いたサービス全般を正しく使うには、プロンプトの粒度を高める+プロンプト固有のテクニックで良い回答がもらえるように人間がしなければなりません。考えを汲んでくれたり、「アレ」で通じるような相手ではありません。

原因と対策

どちらの問題の原因も、エンジニアでない人がDevinを利用し、エンジニアと同じ仕事をしたことによるものです。後者の「エンジニアと同じ仕事をする」ことを防止するためにいくつか考えられる取り組みを以下に上げます。

Devinができること、できないことを社内で教育する

一般的な人は、コンピュータ、イノベーション、DX、AIと流行っているカタカナ及びアルファベットの文字に対し、卍最強卍で何でも解決できるという風に思ってしまうところがあると思います。AIの得意不得意や、出来ないことをしっかりと説明し、適材適所としてAIを活用してもらう意識改革が必要に思います。

Devinを利用できるチームを開発チームに限定する

一般的な業務の質問をする分にはChatGPTなどのAIチャットサービス+モデルの設定だけで十分なので、コードに手を加えたりGithub操作まで行うことができるDevinは開発チーム以外には触らせないのがよいと思います。
自分の会社ではDevin講習会なんてものをやってしまっているので、今からこのように舵を取るのは至難ですが・・・

まとめ

Devinは画期的なツールだとは思いますが、そのような便利なツールが出てくれば出てくるほど、それを使う側の体制やナレッジによる問題と、他との差が浮き彫りになってくると思います。
ツールに対する理解と、ツールが出来ることに対する責務を負う人やチームをしっかり決めるという、基本的なマネジメントをすることでよりDevinを生産的に使えるのではないかといえます。

脚注

1. マージさせたのはCEOで、Githubの権限がありました