コーディングエージェントはもはや当たり前になってきています。エージェントにコードを作らせるとき、ブレなくコードを生成できるプロンプトを作るのが大事です。
ここでプロンプトには、AGENT.mdなどのファイルも含みます。
コンテキストに乗るもの全てなので、実際にはコンテキストをちゃんと健全に保つことが大事ということになるのですが、入力プロンプトが中でも重要なのでここではプロンプトとしておきます。
最初に与える設計などの情報をちゃんと作るのはもちろんのこと、途中の指示も「この機能いれて」「やっぱこうしよう」「ここは不要だった」のように機能を入れたり削ったり変えたりしていると、エージェントだけではなく人間がコードを書くときにも、コードが汚れていきます。
エージェントの場合、そういった試行錯誤がコンテキストに残ると、生成の性能も悪くなります。
指示をするとき、的確に指示をすることが大切です。
そうすると、「何をどのようにするか」ということを的確に指示することが大切です。またそのとき、修正や変更であれば技術的に何がおきて何を行うのかを把握しておくことが重要です。
Webの画面であれば、DOMやCSSの最低限の仕組みや挙動がわかっている必要があります。
データを操作する場合に、データ構造がどうなっているかの把握が必要です。
ここで「何をどのようにするか」の「どのように」は やってみないとわからない面もあるので、試行錯誤になるのは仕方ないこともあります。
けど、「何を」はそれなりに精度高く決まるはずです。
プロジェクトの開始で、データベースを扱うシステムであれば、「何を」はデータ構造として現れます。
データ構造の変更は、上から下までの構造変更が行われ、コードが不安定になりがちです。これは人間がやってもそう。
また、すでにデータが入っている場合、後方互換を考えたりすると、最初からできていれば不要なロジックが入り込むことになります。
データ構造が大切なのは、内部構造として重要だからというだけではありません。「何を」をあらわすので、データ構造があいまいということは「何を」の把握があいまいであることを示しています。
単にコードを動かすための内部構造ではなく、仕様を固めて作るものを把握した結果が現れるものだと考えるのがいいです。
データ構造があいまいなとき、ユーザーインタフェースもなにか矛盾があったり足りないことがあったり、実はちゃんと実装できるアイデアになってないこともよくあります。
最初は実装ができるのだけど、ちゃんと機能を作りこもうとしたときに、何かが足りなかったり、構造として適切ではないことに気づいたりします。
なので、最初にデータ構造は可能な限り考え抜くのが大切です。
アプリケーション全体をちゃんと考える、その考えた結果がデータ構造としてあらわれることになるのですけど、そうやってアプリケーションを考えるとき、そのアプリケーションの意味をちゃんと考えるのが大切です。
「だれがどのような目的で使うのか」ということです。
アプリケーション設計に不慣れなうちは、機能の積み上げとしてアプリケーションを考えがちです。けれども機能だけを考えていると、やはりどこかでブレが発生します。
ユースケース図でいえば、アクターやユースケースをちゃんと考えて、そこからデータ構造を見出し、そのあとに具体的な機能を載せていくという考え方です。
いろいろ手法はありますが、個人的にはユースケース図+ロバストネス図を基本にしたICONIXが好きです。
エージェントが書くのだから試行錯誤でいい、という意見もあるかもしれませんが、要件定義をちゃんとやるというのは、一度とことんやってみることが大事だと思います。やってみて、「ここまでは 考える必要なかったな」と塩梅を掴んでうまくなるんではないかと。
あと、「何を」をちゃんと見ずに機能を積み重ねていくと、最初は使えるのだけど、機能を足していくごとにやりたいことが実現しづらくなって、使えはするけど使いづらいということにもなりがちです。
必要なのは要件定義というか要件分析かも。
と書いたこと、実のところコーディングエージェントの話ではなく、昔から言われている要件定義の話です。
ぼくのブログでも例えば20年前のこれと言ってることは変わってない。
わかりやすいドキュメントの書き方 - きしだのHatena
今まではコードを手で書いているあいだに気がついて補正していたものが、コーディングエージェントによってそういった部分がなく指示がそのままコードになり、誤魔化しが効かなくなっています。
コーディングエージェントの時代には要件定義の技術がより大切になると思います。
要件定義の肝についてはこちら。
ユースケース図やロバストネス図を使った要件分析についてはこちら。
ユースケース図を広めたヤコブソンの最近の本はこちら。
