AIエージェントと無能なオペレーターGebAlgebraによって積み上げられた使えないコードの塊
これは私がAIエージェントでWebアプリを作ろうとして、盛大に失敗した記録です。
書いたコードは以下のリポジトリにあります。
やったこと
AIエージェントを使って新しいアプリを作ろうとしました。
まず、大まかなドメインモデルを考えて型として実装してから、それを使ったサービス → UIの順でAI (Cline, Cursor) に実装指示をしました。
しかし、UI実装中に、AIと一緒にこれまで作ってきたコードがほとんど使えないことに気づきました。
UIに必須のサービスが定義されていなかったり、不要なサービスが定義されていたり。
挙句、ドメインモデル自体も結構間違っていたことに気づきました。
私は全てのコードを投げ捨て、これを書いています。
別にAIに丸投げして中身を見ていなかったわけではありません。
AIが従うべき開発ルールやフローを明文化して従わせていましたし、そのフローの中で都度コードレビューを挟むようにしていました。
レビューの中でも、AIのミスを直し、正しくできていると思ってから先に進んでいました。
何が間違っていたのか？
詳細な計画が必要だった
まだ世の中に存在しないサービスを作る場合、詳細な計画がなければ、AIに正しい指示を出すことはできません。
計画がなければ、私もAIもアプリのイメージが曖昧になり、どこに向かえばよいのか分からなくなってしまいます。
実際、実装計画を作成するように指示するたびに、AIは誤った計画を立て、何を実装すればいいのか私自身も見失ってしまい、修正ができなかったのです。
思考の隙間をAIに埋めてもらえると期待したのが間違いでした。
『AIエージェントがたった一行の指示でポケモンゲームを作った！』みたいなことを期待してしまったのですが、新しいサービスを作る場合はそういうことは起こらないと思います。
これができるのは、「ポケモン」という1単語で、AIが何を実装すべきか明確にイメージできるからです。
機能はひとつずつ完成させる
アプリは小さな機能ごとに分割し、ひとつひとつ作りきっていくべきでした。
AIは非常に高速でコードを書いてくれるため、一行の指示で大量のコードを生成させる誘惑に駆られ、すべてを一度に作ろうとしてしまいました。
しかし、それは大きな間違いでした。
アプリ全体を一気に実装しようとするのは避けるべきです。
これは、AIの出力をできるだけ早く検証するために重要なポイントです。
計画はあくまで「計画」に過ぎず、間違っている可能性もあります。
計画の正否は、計画内のすべてのタスクが完了して初めて分かるものです。
失敗の影響を最小限に抑えるためにも、「小さく計画し、小さく実装し、小さく検証する」ことが肝心です。
次はどうする？
まず、何を作るのかをはっきりと定めてから作り始めるべきです。
（なんでこんな当たり前のことを書いているのか...）
少なくとも、メインのユーザーストーリーと、それを支える各ページのワイヤーフレームは作成しておく必要があります。
これにより、アプリがどのように動作すべきか、またどんなサービスやオブジェクトが必要かが明確になります。
そして、ユーザーストーリーとワイヤーフレームから導き出されるドメインモデルも作っておくべきです。
これにより、各小さな機能同士の一貫性が保たれ、最終的に一つのアプリとして組み立てやすくなります。
その上で、計画に基づいて、AIに対する各タスクの受け入れ基準を明確にしておくことが必要です。
この基準があれば、AIの出力が正しいかどうかをすぐにチェックすることができます。
具体的には、まずUIの動作を明確に決めてAIに作らせる、その後、「このUIが動くように」という条件で必要なサービスを作らせる、といった具合です。
これらの基準をAIに伝える必要もあります。 方法はなんでもよく、自然言語で伝えたり、関数のインターフェースやUIのモックなどがあります。
場合によっては、説明するより自分で実装した方が早いこともあると思います。
最後に、やはり「小さく計画し、小さく実装し、小さく検証する」ことが肝心です。
一つの機能を端から端まで作り上げ、思った通りに動くかをできるだけ早く確認するため、アプリ全体を小さく管理しやすい機能に分割し、それをひとつずつ実装していくのが良いと思います。
結論
これは私の失敗の記録です。
今回学んだことを活かし、再びAIエージェントを使って同じアプリを作り直すつもりです。
しかし、各タスクの受け入れ基準を明確にし、伝えるのは結構大変です。
そのため、AIエージェントを使ったコーディングが本当に高速なのか、ちょっと疑問に感じてきています。
まだ可能性は感じているので、今後も実験を続け、また報告していきます。
Discussion