ごきげんよう🙋♀️あっきー(@kuronekopunk)です。
先日、開発支援AIエージェントのDevinくんをお迎えしました。
セットアップに若干苦労した話と、初稼働時のDevinくんの成果についてまとめます。
Devinのセットアップ
リポジトリの初回セットアップでは以下の画面で Install Dependencies、Lint、Test、Additional Notesなどが必要になります。
Install Dependencies
最初、「左に必要なコマンドを全部書けばいいのね」と勘違いしてDB作成などもInstall Dependenciesに含めてしまい躓いていました。
中央の説明を読んで、公式の説明動画を見れば一発で分かるのですが、時間が経つと右側にVSCodeが開き操作が可能になります。
まずはターミナルから必要なセットアップを行い、npm installやbundle installなど都度の依存関係のインストールのみを左側に記載する必要がありました。
何度かDevinを動かして分かったのは、Install DependenciesはDevin起動時にスナップショットから起動してから毎回実行されるコマンドのようで、DBのmigrationなども含むほうが良さそうでした。
複数行書けるため、最終的にこのような形になりました。
cd ~/repos/${リポジトリ名}
docker compose build
docker compose run --rm app yarn install
docker compose run --rm app bundle install
docker compose run --rm app bundle exec rails db:migrate
Additional Notes
悩ましかったのがAdditional Notesです。プレースホルダーも無かったので、左下にあったAsk AIに聞いてみたところ良いサンプルが得られました。
以下もらった内容
DockerComposeを使用している環境の場合、Additional Notesには以下のような情報を記載することをお勧めします：
### 開発サーバーの起動方法
開発サーバーを起動:
docker-compose up
バックグラウンドで起動:
docker-compose up -d
### テスト実行
単体テスト:
docker-compose exec app npm test
E2Eテスト:
docker-compose exec app npm run test:e2e
### データベース操作
マイグレーション:
docker-compose exec app npm run migrate
データベースリセット:
docker-compose exec app npm run db:reset
### 基本的なトラブルシューティング
コンテナの再起動:
docker-compose restart
環境の再構築:
docker-compose down
docker-compose up -d
### 使用ポート
- アプリケーション: localhost:3000
- データベース: localhost:5432
このフォーマットで書けばいいことが分かったので、ローカルのCursor Agentを使いました。
README.mdとdocker-compose.ymlを参照させ「同じフォーマットでこのプロジェクトの説明を作って」と依頼し、ポート関係やその他Dockerで利用されているコンテナ情報をまとめたAdditional Notesを作成してもらいました。
Devinくんの初仕事
Devinは公式の説明にもあるようにジュニアエンジニア相当の能力を持つため、まずは簡単な仕事から始めることにしました。
RubocopTodoで除外設定されているLint違反の改修をお願いしました。基本的にrubocop --only 対象のCop名 --autocorrectで一発で解消されるような簡単なタスクです。
作業を眺めていると、--autocorrectについて説明したうえでタスクを依頼したものの、自分でファイルを編集して修正をしてPRを作成してくれました。
GitHubにpushされるとCIが動くのですが、まずはローカルで検証してからpushしてほしいところでした。
ローカルでLintとTest実行を指摘してやってもらうと、タスク完了後に「LintとTestを実行してからPRを作成する」というナレッジの追加を提案してくれました。
CIの完了を待たせるのはコストが掛かりそう
push後はCIの完了をghコマンドのwatchで監視していて、常に起動しっぱなしになってしまっていました。弊社のCIは10分くらいで終わるのでギリギリ待たせても良いかなと思うのですが、コスト節約を考えると「ローカルで全て通っていればCIを待つ必要はない」などのナレッジを追加する必要があるかもしれません。
かかったコスト
初回PRでは環境セットアップが上手くいっていなかったこともあり、躓き数回トライをして複数セッションを使って、10ACU（約$20）くらいかかってしまいました。
後続の似たPRでは1〜3ACUくらいで実行ができていました。
安いとは思いますが、まだ子守が必要なためもう少し自走できるようになってくれると嬉しいです。
開発支援AIエージェントの可能性
CursorやGitHub Copilotは自身のPCを開いていないと進められませんが、Devinは出先やPCを開かない状況でも開発を進めることができる点がメリットに感じました。
逆にPCを開いていられる場合は、ローカルで同じリポジトリを複数個cloneしてCursorやClineを複数起動すれば並列化も可能に感じるため、Devinのメリットが相対的に小さくなるようにも感じています。
現在、弊社ではDevin、GitHub Copilot、Cursorを並行利用していますが、各ツールごとに特性もあるため、それぞれのナレッジやrulesを蓄積し、お互いに育てあってより良いナレッジを作っていければと思います。
またここで育ったナレッジは新入社員が入ったタイミングでも効果を発揮するため、各ツールによらない総合的なドキュメント整備を考えています。
ナレッジの蓄積、ドキュメント整備について
前項で書いた『共通のナレッジを作る』について詳しく説明します。
以下の記事の『育てやすい構成にする』章のイメージで、共通のruleを特定のフォルダに作り、各Rules（.cursor/rules、.cline/rules、.github/copilot-instructions.md）にまとめるGitHub Actionを作るのが良いかなと考えています。
Devinだけはナレッジ管理がWeb上という点が逆にデメリットになりそうに感じています。.devin/rulesのような機能の導入があると嬉しいです。
参考：https://zenn.dev/ks0318/articles/b8eb2c9396f9cb?s=31#2.-育てやすい構成にする
さいごに
Devinの語尾を「〜デビ」にしていないのが少し心残りです🥹
先日Cursorのビジネスプラン導入も行いました。Devinだけに限らず、より生産性を上げていける方法を今後も模索していきたいと思います。
Discussion