生成AIにどこまで開発を任せるか(2025/03/02時点)
結論: デバッグやドツボにハマる問題があるため、rails generatorのようなScaffoldより柔軟性の高いツール、程度に任せる。
以下には、後ろにある考えなどを残しておく。
任せたいと思っていたこと
ざっくりコードを書く際の進め方は
- 実装する内容を理解する
- コードを読む・書く
- デバッグする
- リリース
でこれのどこまで任せられるかを知りたい。
今回試していないこと
cursor ruleなどの整備。
プロンプトに対する振る舞いが今後破壊的に変わり得る & 改善を自動テストしていくのが困難で、すぐに僕が迷走してしまう。
なので現状は使っていない（DevinのKnowledgeだけは使った）
利用したツール
- Cursor
- Tab
- Composer
- Devin
利用場面
- 個人ツール
- 会社での開発（Cursorのみ）
付き合い方
OK
- 単語のみから連想可能なもの
- Dockerのビルド速度改善して -> 並列化、など（ただ、何故かそこがボトルネックではないのにマルチステージビルドを入れ始めたりもする）
- Scaffolding
- 例: VSCodeの拡張機能を最小構成で作らせる、既存のコードから雰囲気を読み取り3層構造の大まかなものを作る
- 小さめのタスクで、かつ自分の手元の環境が整っていなかったりで面倒なもの
- バージョンアップしたらエラーになるケースなど https://github.com/rerost/giro/pull/134
NG
- 自分と並列で何かを進める。適宜モニタリングしないと、たまにドツボにハマってる
- 論理的になにかを試させる（このあたりは推論モデルを使ったツールが出てきたら改善するかも）
- パフォーマンス改善時に3倍早くできないのはなぜ？などを考えさせる
- 入り組んだDB周りのアレコレを調査 & 対応させる（他のことをしだす）
- 立ち戻ったり途中までのモノを捨てられず、ドツボにハマる
- 客観的に何かを示すことができない（解決不能な問題に取り組み続ける）
あと、たまに嘘を付くのがに注意。ハルシネーションは最近あまり体験していなかったのでちょっとびっくりした。
例: ボトルネックの分析するって言ったのに改善を始める
例: Pushしたって言っているのにPushされていない。確認もできていない
他にはVSCodeの拡張を作らせたら、僕にひたすら動作確認させてきたり。
あたりは難しい。
あと、手持ちの問題でChatGPTやClaudeが彷徨ってしまう問題がo3-miniでは解けていたのでツールがo3-miniに対応したら割と解決する問題かもしれないと思っている。
4oとo3-miniはローラーで潰そうとしたり、過去のLLMのアウトプットに引きづられている印象（= 生成AI系のツールがドツボにハマるケースと似ているように感じる）。
ので、LLM側の性能が伸びないことにはこのあたりは任せられないんじゃないかという仮説がある。
Devinがドツボにハマっていく現象について
デバッグは
- エラーメッセージから連想される修正をする
- 原因がわからないので、方針を切り替えて原因を特定するようにデバッグ・調査する
- 変数を減らすため、最小の再現環境を作る（Go Playgroundや、Dockerイメージ、インフラ構成、etc..）
- わからなくてヘルプを投げる（会社なら同僚など、OSSならissueなど）
という流れになっていて、解決したらそこで終了という形になっていると思う。
1 ~ 4は時間・金銭・脳みそのなど負荷がだんだんと増えていくので、良い塩梅で切り替えていく必要がある。
だが、多分このあたりはプロンプトでどうこうできるイメージはなく、人間が管理監督する必要がある。
このあたりは生成AIの性能とかではなく、一度問題に立ち戻させたりする必要があるのであまり簡単ではないのではないかなと思ってる。
デバッグの本質は20の質問（アキネーターとかがやってくれるやつ）と同じだと思っていて、いきなり具体的なものだけで解こうとするとドツボにハマる。
それぞれのステップで、どこかで打ち切り時間的・金銭的な大きい方法に切り替えていく必要がある。
が、試してみるとわかるが、生成AI自身の質問に引っ張られてどんどんドツボにハマっていく姿が見れる。
20の質問の答えがピザなときでも、
| 質問 | 人間の回答 |
|---|---|
| それは生き物ですか | No |
| 家に置いてあるものですか？ | No (家で使うものだが、常備するものではないのでNo) |
| 会社に置いてあるものですか？ | No |
| ... | ... |
| お店にあるものですか？ | Yes |
| レジですか | No |
| ... | .... |
のように、場所の質問で何かがおかしかったことに気づいてほしいが、どんどんドツボにハマっていっているのが見て取れる。
- 4o https://chatgpt.com/share/67bc9f56-72a8-8007-864a-58f9101ac61a
- o3-mini https://chatgpt.com/share/67bc9507-cd58-8007-82bb-8a72829000ec
- o1 Pro https://chatgpt.com/share/67bc9f83-e74c-8007-b78b-dfedacb4e687
- ちょっと希望がありそう
多分アキネーターができているので解決事態が難しいものではないと思うが、これがモノではなく概念であったり、デバッグの際の原因のような抽象的なものになってくると、切り口を変えたり以前のプロンプトを忘れる（もしくは何か問題がある）と推測する力が必要だと思っている。
結論
デバッグやドツボにハマる問題があるため、rails generatorのようなScaffoldより柔軟性の高いツール、程度に任せる。
特に僕はコードリーディングが早い方ではないので、小さく生成していくくらいがちょうどいいと思う。
ただしモデルの性能が上がると、一発で期待したコードが出力されるのでそれに比例してドツボパターンに陥ることが少なくなることを体感しており、デバッグすること自体が減っていくことを期待したい。
個人的な振り返り
期待通りだったこと
CIの整備が必要
特にe2eで広く薄くテストしておいて良かった。
生成AI系のツールを用いることで個人開発をしているツールのメンテとかはできるだろうと思い、CIやE2Eの設定を去年の秋頃しておいて良かった。
Google検索の代替
先にChatGPTに聞く。1月から新しい会社で働いているが、自分に取って新しいツールのキャッチアップなどには生成AI系のツールに助けられた。
ChatGPT ProやCursor、Copilotなど。
特に、
- Kotlinのこれは、Goでいうこれって理解であっている？などの質問
- Kotlinらしい書き方の訂正など
- 事前のバグ潰しや、開発中のバグ発生時の対応など
といった部分で助けられた。
ざっくり調べる、ができるようになったので、ざっくり理解したあと公式ドキュメントを読めば良いのでスムーズに行く
期待通りではなかったこと
ローカルLLMを開発に活用
- 当時の期待: 様々な制約でLLMを使った開発ができない企業などもあるはず。そこでも問題なく働けるようにしたい
- 今の思考: LLMを使えるように、法律やセキュリティの面でのルールや情報整備を行い、ツールを使えるようにしていったほうが良い（ルール整備がめちゃくちゃ大変だが）。性能がすぐに足りなくなる
フィードバックループについて
20の質問の部分とかぶるが、
- 人間: 実装 -> エラー -> 連想・ 解釈 -> 実装 -> エラー -> ....
- LLM: 実装 -> エラー -> 連想 -> 実装 -> エラー -> ....
と、エラーや発生したことへの解釈の有無が異なる。
人間と同じくらい解釈してくれると期待していたが、どうも生成AI自身が生成したコードになると視点が固定されてしまっているため、解釈がうまく行っているようには思えない。
なので、多分LLMにサービスを成長させる施策を考えさせ、実装し、リリースしてフィードバックを元に改善までを自律してさせるのは今は難しいと思っている。
Discussion