はじめに

Devin、試してみました。最近Devin含めAIに関する記事がたくさん書かれているので、真新しい知見などは現状はあまり書けないですが、一応使ってみての所感などを書いてみたいと思います。

Devinの性質

Devinの特徴って色々ありますが、公式ドキュメントを読んだり実際に使ってみて特に以下2つの性質を強く感じました。

エンジニアが複数のタスクを並行して進めることを助ける
50~80点くらいの大枠の実装を行う

エンジニアが複数のタスクを並行して進めることを助ける

以下公式からの引用です。

Start your day by putting multiple Devins to work in parallel

仕事始めに仕事を任せて、お昼にPRを確認する、といったことがベストプラクティスとして書かれています。

Devinを使っていて、よくCursorなどと比べてレスポンスが遅いといったことが取り上げられますが、そもそもDevinはバックグラウンドで働いてもらうものなので応答速度が遅くても大きな問題になりません。朝に依頼をして、昼までにできていればいいんです。

CursorのManualだとかChatみたいに依頼をしたらそのレスポンスを待つのでなく、Devinは依頼をしたら自分の別のタスクをこなすべきなんだと思います。

50~80点くらいの大枠の実装を行う

Do: Collaborate by Completing Partial Tasks
Why: Sometimes it’s faster for you to finish the last 20% of a task.

「Treat Devin like a junior engineer.」と書いてある通り、Devinくんは完璧ではありません。

20%どころか50%以上自分で書き直すみたいなこともあるのですが、私としてはそれでいいです。昼ごはん食べてる間に50%も完成させてくれるんですから、本当に助かります。

Devinを強強エンジニアだと考えて80点以上の出力を求めていると期待値がズレちゃうのかなと思います。

Devinの用途

レビュワーとして使う

自分で作成したPRだけでなく、Renovateで作成されたPRのレビューをしてもらっています。
Dependabot or RenovateのレビューにDevinを使うために以下の記事を参考にさせていただきました。

破壊的変更はどこで、それに関わる実装がコード内あるかなどをDevinに見てもらっています。

軽い実装を任せる

以下のようなシーンでDevinに開発を依頼することが多いです。

似たようなパターンの実装がすでにある場合
並走可能なタスクが複数ある場合
複雑なタスクではない場合

特に「似たようなパターンの実装がすでにある場合」は過去のPRなどの情報を渡し実装の流れを掴んでもらうことでかなり完成度が高いアウトプットが出る気がします。
これらに当てはまらない場合はCursorを使います。

コードベース調査や分析

自分があまり熟知していない機能の実装について質問します。私はサーバーサイドのエンジニアなので、iOSやAndroidアプリの実装を熟知していないため例えば「現在、iOS, Androidアプリケーションからxxxというエンドポイントを叩いている場所はあるか」など聞いたこともあります。
複数リポジトリを横断してコードを探索、分析できるのがDevinの強みだと思います。

Devin1.5からベータ版としてDevin Searchという機能が追加され、コード探索をそちらで行うことができるようになりました。

試してみましたが応答速度が通常のDevinに依頼するよりも速い気がします。
また、ChatGPTなどのDeep Researchみたいに、出力した文章内に、根拠となるコードの位置を逐次記載してくれます。サーチした内容をベースとして通常のDevinに依頼を投げることができるため「コード探索」→「コード修正」がスムーズに行えます。
今後使っていく機会が増えていきそうです。

あと、私の会社のビジネスサイドの人は、ある施策の進捗を把握するためにDevinにSQLを書かせていたりします。

気をつけていること・Tips

1. ACU10を超えないように注意する

公式ドキュメントのBest Practiceには以下のように書かれています

Try not to spend too many (>10) ACUs on one run. Devin’s performance degrades in long sessions.

体感としてもACU10を超えたあたりから、ハルシネーションが一気に増える印象を受けました。
1つのタスクが大きくなりすぎないようにできるだけ細かい粒度で指示を出す方が良さそうです。
Devinくんもそれをわかっているようで、以前一度に２つのエンドポイント作成を依頼した時に、すぐに実行に取り掛かるのではなく、１つずつエンドポイントを作成していく方針を提案してくれました。

このようにDevinくん側でもタスク分割を心がけてくれるのものの、エンジニア側でもできるだけシンプルなタスクを依頼することを意識した方が良さそうです。

「Devin使ってみてどうだった？～活用事例と導入時のポイント～」というセミナーに参加させていただいた時に得たTipsですが、タスクが大きくなりすぎた場合にPRを作らせてそこに今までやったことを書いてもらい、別のセッションを立ててそのPRを見せて続きをやらせるという技もあるようです。
このように適度にタスクの中間セーブポイントを作るのはとても有効だなと思います。

2. Devinに全部を完璧に作ってもらうのではなく大枠を作ってもらうイメージ

冒頭でも書きましたが、大枠を作ってくれればいいという気持ちで指示します。

100％完成されたアウトプットを求めようとしてDevinとのラリーが増えても、なぜか途中で指示通りに動いてくれなくなり非効率だなと感じることがあります。

Devinくんは応答に時間がかかる場合もあるので、大枠を作ってもらったあとは適宜Cursor等のエディターを使いながら手元で作業するのが効率がいいと感じます。

3. 大きなファイルの細かい修正は苦手？

Devinに巨大なyamlファイル内のlintエラーを修正させた時、応答にかなり時間がかかりACUを大きく消費しただけで期待する結果が得られなかったという経験があります。

かといってCursorのagentモードでもうまくいかなかったので、現状はこういった巨大なファイル内の細かい修正はあまりDevin等には頼まずに人力でやった方が早い気がします。

4. Knowledgeはエンジニアが使っているドキュメントを参照させる

こちらも先ほど言及したセミナーで得たTipsです。Devinに情報を閉じ込めてしまうと、その知見がエンジニア間に広まりづらくなる可能性があります。とても納得感があり、参考になりました。あくまで主役は人間なわけです。

私のチームではドメイン知識などに関するドキュメントがGitHubリポジトリに格納してあるので、それを参照してもらいます。
ADRなどのドキュメントが今後より価値が高くなりそうです。

まとめ

AIが発展するスピードがあまりにも速いので、ここで書いたこともきっとすぐに陳腐化するかもしれないですね。
まだまだみんなベストプラクティスを模索しているところで、特にknowledgeに関してはもっと実践を重ねる必要がありそうです。
例えば公式ドキュメントではknowledgeは細かい粒度で書いた方がいいと書かれていますが、一つの大きな粒度のknowledgeを作っているという人もいるようです。
今後も試行錯誤しながらよりよい使い方を模索していきたいです。