Welcome Devin
背景
昨年、日本からのインターンシップの学生さんに atWare Vietnam が関わっているプロジェクトの課題を解決するためのデモアプリを開発してもらいました。この課題に対してこういうアプリケーションを開発して、運用すれば改善できますと提案するためです。それから少し間が空いてしまったのですが、いよいよその課題が顕著になってきたこともありお客さんに提案、デモすることとなりました。 しかし、状況は少し変化していて、開発してもらった当時のままでは不都合があります。つまりデモアプリを改修する必要があるのですが、学生さんのスキルなどの事情に合わせてフレームワークを選定していたので、自分で改修しようと思うと、デモのためだけにフレームワークを習得して、既存のコードを理解しなきゃいけない。提案が通って本格的な開発をするとなれば、またスクラッチから設計し直して、弊社のエンジニアが開発していくことになるので、ここであまりコストをかけず、サクッと改修したい。 と、前置きが長くなりましたが、よい機会なのでどれくらい使えるのかの実体験も兼ねて AI にプログラミングをさせてみることにしました。ちょうど Devin 2.0 が出て安価で気軽に試せそうということもありました。
準備
ありがちですが、こういうツールを使おうとすると動くようにするまでの道のり、学習コストがとても高くて断念することがありますね。 Devin も動くようにするまでは少し面倒でした。何より、ちゃんと開発プロジェクトとして整っていないインターンシッププログラムですので、特に開発環境の構築手順が整備されておらず、結論から言うと現時点でも Devin の中で Web アプリケーションを動かして動作確認をするところまではできていません。そう、Devin はリモートの Devin の環境内で実際にアプリケーションを起動し、 Web ブラウザからアクセスして期待した動作になるかの検証までするらしいのです！ それでも他は特に困ることもなく、Onboarding Devin/Repo Setup あたりのドキュメントに沿って、アカウント作って、すでに存在した Git リポジトリ登録して、Slack チャンネル連携したら準備は整った模様。
まず最初にお決まり通り、以下のような依頼をして動くことを確認します。
Hey @Devin , please verify that you can:
- access the xxx/yyy repo
- run lint
- open a dummy draft PR with a simple change
これで、Web ページの title を微調整した Pull Request を投げてくれて、もうこの時点でスゲーってなります。
タスクの依頼
さすが AI、学習コストも高くなく、普通の言葉で開発の指示をすれば実装してくれます。
当初は、英語で簡単な修正、Please foo bar when hoge hoge. みたいに依頼してみてましたが、アプリケーションの表示内容に日本語が当然使われているので、そのうち日本語で応答してきました。じゃぁと日本語で依頼すると何の違和感もなく日本語でやりとりできます。少なくとも私のボキャブラリー乏しく、文法もいい加減な英語で依頼するくらいなら、日本語で丁寧に説明したほうがずっと良い。
ドキュメントには、現在の Devin は Junior Engineer だから、コード・リファクタリングとか、バグフィックス、UI の変更とかをやらせるのが良いとあります。今回もデモでそれっぽく動くように UI の見た目の変更とか、ワークフローの変更などをお願いしてみてます。
ChatGPT などもそうですが、細かく例示したり、省略することなく説明してあげるとちゃんとその通り実装してくれます。それでも、あいまいな部分があると、Open Questions で「どうすべきか」とか、「こういう計画で実装するけど問題あったら指摘してくれ」と聞いてきます。勝手に思い込みでやってしまわないのは偉い。
ただ、質問されても仮定で実装は進めていくので、質問に回答する前に実装が終わって、回答が仮定と違っていると再実装するみたいなことはありました。とにかく仕事が早い！
実装
実装が完了すると PR 作って、レビューの依頼がきます。その前に Devin の環境内で実際にアプリケーションを起動し、動作確認してから PR 作るらしいのですが、前述の通りその整備まではこちらの問題でてきておらず。なので、稀にちょっとしたチョンボ、export 漏れでアプリが起動しないとかありました。今回はバックエンドは Python なのですが、静的型付け言語だとこういうのは防げるのかもしれません。いや Devin の環境でちゃんと起動して動作確認できるような環境を整備せよってことなのですが… 依頼があいまいだったからか、想定した結果と違ってたときに指摘すると、その PR を捨てて（自分でクローズして）、別の PR を作ってくれました。先の修正にさらに修正を積み上げていくのではなく、最初からやり直したほうがよいという判断もできている模様。 いかにも「自動生成しました」ってコードではなく、ちゃんと意味を汲んだ名称だったり、機能の分離をします。逆にいえば、Devin が書く前のコードに倣って修正、拡張していくので、元のコードの名称やモジュール構成などをしっかりしていればよいけど、そこがイマイチだとイマイチのままツギハギだらけなコードになってしまうかもしれません。 今回はそういう観点でのコードのリファクタリングまではやってもらってないので、その実力は不明です。 やや余談ですが、Devin の画面（IDE）でコードを書くする様子が見えるのですが、試行錯誤しながら書き直してるようなこともあって、見てるだけでもおもしろい。ほんとにむちゃくちゃ手の速いエンジニアが作業してるみたい。
動作確認
最初は PR をまさに目でみてレビューして main ブランチにマージ、動作確認してましたが、PR をマージした時点で Devin 的にはそのタスクは終了したと判断してることもあり、PR を作った Devin の開発ブランチをローカルの環境で起動して動作確認するのがよさそう。なにか不都合があるとそのブランチで修正してくれます。当たり前といえば当たり前か。 期待した通り動作せず、エラーがあると、その内容を伝えると問題を推測して修正を試みます。原因究明のために print 文追加してと依頼し、その結果のログを伝えればそれで原因を特定してくれます。もしかするとこういうのも Devin の環境で起動できていれば自分でやったりするのだろうか。未確認。
所管
今ドキュメント見直してみると、 Devin’s strengths? に「Creating customized demos」、「Prototyping solutions」とあって、まさに今回の試みは強みを活かすことができたように思います。無事にデモできるレベル内容に仕上がりました。 Devin の全てを理解できているわけでも、試せてるわけでもないので、あまりいい加減なことを言うのは憚られるものの、まさにチームの Junior Engineer として、バグ修正やちょっとした小さな改修、タスクをやってもらうには十分なパフォーマンスだと思います。ちゃんと指示すればちゃんとやってくれますし、あまり不安を感じることもありません。ただ、あくまでもコードを読んでるだけなので、なぜそういう実装、UI になってるのか、意図や背景を察することはできてないようで、そういう間違いをすることはあります（指示してないのが悪い）。ドキュメントの Work With Your Existing Tools に Confluence や Google Drive なんかもあるので、もしかして仕様書、設計書などコード以外からもシステムを理解することができるのだろうか。未確認です。 少なくとも現時点では Devin だけでシステムの全てを開発することはできなくても、面倒なエラー処理含め、枝葉の大部分は担当してくれる頼もしいチームメンバーだと断言できます。 疑心暗鬼にまずは評価してから云々言ってるくらいなら、チームに加えて、できるタスクをどんどん与えていくのが良いのだろうなと思います。こんな面倒なタスクやらせるなよって言うことなく、常に「すぐに実装に取り掛かります」という素直で HRT に満ちた仲間です。
追記
無事に提案は通り、本格的に開発をすることになりました。 atWare Vietnam のエンジニアに根幹の部分をしっかり作ってもらって、あとは Devin にがんばってもらおうと思ってます。