ソフトウェアエンジニアリングのループにおける人間とエージェント

人間はソフトウェア開発プロセスから離れてvibe codingに徹するべきか、それとも開発者がすべてのコード行を検査するループの中にいるべきか？ 私は、アイデアを成果に変えるという目標に焦点を当てるべきだと考えています。人間の正しい役割は、エージェントに任せきりにするか、生成物を細かく管理するのではなく、動作するループを構築・管理することです。これを「ループ上（on the loop）」と呼びましょう。

ソフトウェアの作成者として、私たちはアイデアを動作するソフトウェアに変換し、学びながらアイデアを進化させ、反復することで成果を生み出します。これが「なぜのループ」です。AIの反乱が起きるまで、人間がこのループを回すことになります。私たちがその成果を望むからです。

ソフトウェアを構築するプロセスが「どのようにのループ」です。どのようにのループには、コード、テスト、ツール、インフラストラクチャといった中間成果物の作成、選択、使用が含まれます。また、技術設計やADRなどのドキュメントも含まれる場合があります。これらの多くを成果物として見ることに慣れていますが、中間成果物はあくまで目的を達成するための手段に過ぎません。

Figure 1: The why loop iterates over ideas and software, the how loop iterates on building the software

実際には、どのようにのループには複数のループが含まれています。最外側のどのようにのループは、なぜのループのために動作するソフトウェアを指定・提供します。最内側のループはコードの生成とテストを行います。その間のループは、上位レベルの作業をより小さなタスクに分解して下位ループに実装させ、結果を検証します。

Figure 2: The how loop has multiple levels of inner loops that work on smaller increments of the full implementation

これらのループは、設計レビューやテストステージなどのプラクティスに従う場合があります。マイクロサービスやCUPIDのようなアーキテクチャアプローチやデザインパターンを適用してシステムを構築することもあります。これらのプラクティスやパターンから生まれる中間成果物と同様に、それらはすべて私たちが本当に重視する成果を達成するための手段です。

しかし、目標を達成するために用いられる手段にこだわらない方がよいのでしょうか？ LLMsにどのようにのループを自由に任せてしまってもよいのでしょうか？

ループの外にいる人間

人間はなぜのループに留まり、どのようにのループはエージェントに任せることに喜びを見出している人が多くいます。これが「vibe coding」の一般的な定義です。Spec Driven Development (SDD) の一部の解釈も同様で、人間は望む成果の記述に労力を費やしますが、LLMがそれをどのように達成するかは指示しません。

Figure 3: Human runs the why loop, agent runs the how loop.

人間がどのようにのループに関与しないことの魅力は、私たちが本当に重視するのはなぜのループだからです。ソフトウェア開発は複雑な領域であり、過度に洗練されたプロセスや技術的負債への対応に陥りがちです。また、これまでのすべてのLLMモデルは、ユーザープロンプトを受け取って動作するソフトウェアを出力する能力を向上させてきました。出力に満足できない場合はLLMに伝えれば、別の反復を行ってくれます。

LLMが私たちなしでコードを書いたり変更したりできるなら、コードが「クリーン」であるかどうかを気にする必要があるでしょうか？ 変数名がその目的を明確に表現していなくても、LLMが理解できれば問題ないかもしれません。ソフトウェアが書かれている言語自体を気にする必要すらないかもしれません。

私たちが重視するのは外部品質であり、内部品質自体ではありません。外部品質とは、ソフトウェアのユーザーやその他のステークホルダーとして体験するものです。機能的品質は必須であり、システムは正しく動作する必要があります。また、本番ソフトウェアでは非機能的・運用的な品質も重要です。システムはクラッシュせず、高速に動作し、機密データをソーシャルメディアに投稿するようなことがあってはなりません。クラウドホスティングの費用が膨大になることも避けたいですし、多くの領域でコンプライアンス監査を通過する必要があります。

内部品質が外部の成果に影響する場合にのみ、私たちはそれを重視します。人間の開発者がコードベースを調べながら機能を追加したりバグを修正したりしていた時代には、クリーンなコードベースの方がより迅速かつ確実に作業できました。しかしLLMは開発者体験を気にするのでしょうか？

理論上、私たちのLLMエージェントは、非常に複雑でスパゲッティのようなコードベースを生成し、アドホックなシェルコマンドを実行してテスト・修正し、最終的に正しく、コンプライアンスを満たし、高性能なシステムを生み出すことができます。私たちはただRalph Wiggumのように群れをなしてデータセンターで稼働させ、沸騰する海からエネルギーを得るデータセンターで動作させれば、最終的には到達できるでしょう。1

実際には、クリーンに設計され、構造化されたコードベースは、乱雑なコードベースよりも外部的に重要な利点があります。LLMがコードをより迅速に理解・修正できる場合、作業が高速化し、迷走が少なくなります。私たちは、必要なシステムを構築する時間とコストを気にするのです。

ループの中にいる人間

内部品質を維持する唯一の方法は、どのようにのループの最下位レベルに深く関与し続けることだと考える開発者もいます。エージェントがコードの破損部分で迷走しているとき、人間の開発者がそれを理解して数秒で修正できることはよくあります。人間の経験と判断は、多くの状況でLLMを上回ります。

Figure 4: Human runs the why loop and the how loop

「人間をループの中に入れる」というとき、多くの場合、LLMが生成した各コード行を手動で検査するなど、最内側のコード生成ループ内で人間をゲートキーパーとして位置づけることを意味します。

プロセスに深く関わりすぎることの問題は、私たちがボトルネックになることです。エージェントは人間が手動で検査できる速度よりも速くコードを生成できます。AIを活用した開発者の生産性に関する報告はまちまちですが、その理由の少なくとも一部は、人間がLLMにコードを生成させることで節約した時間以上に、コードの指定とレビューに時間を費やしているためかもしれません。

私たちは古典的な「シフトレフト」の考え方を採用する必要があります。かつてはすべてのコードを書き、QAチームにテストを依頼し、リリースできるだけのバグを修正しようとしていました。その後、開発者が作業中にテストを書き実行することで、問題を即座に見つけて修正でき、プロセス全体がより高速かつ信頼性の高いものになることを発見しました。

人間に有効だったことは、エージェントにも有効です。エージェントは、私たちがチェックするのではなく、自分で生成したコードの品質を自ら評価できる場合、より良いコードを生成します。私たちは何を求めているかを指示し、それを達成するための最善の方法についてのガイダンスを与える必要があります。

ループ上にいる人間

エージェントが生成するものを自ら検査するのではなく、エージェントがより良く生成できるようにすることができます。どのようにのループ内の異なるレベルのループを制御する仕様、品質チェック、ワークフローガイダンスの集合体が、エージェントのハーネスです。これらのハーネスを構築・維持する新興のプラクティスであるHarness Engineeringが、人間がループ上で働く方法です。

Figure 5: Human defines the how loop and the agent runs it

「ループ上」の概念に似たものは、「The Future of Software Development Retreat」の参加者を含む人々によって「ミドルループ」としても記述されています。ミドルループとは、人間の注意をコーディングループよりも上位のループに移すことを指します。

ループの中とループ上の違いは、エージェントの生成物（中間成果物を含む）に満足できない場合に何をするかで最も顕著に表れます。「ループの中」の方法は、成果物を直接編集するか、エージェントに望む修正を指示することで、成果物を修正することです。「ループ上」の方法は、成果物を生成したハーネスを変更して、望む結果を生成させることです。

私たちはハーネスを継続的に改善することで、得られる成果の品質を継続的に向上させます。そして、さらに次のレベルに進むことができます。

エージェントのフライホイール

次のレベルは、人間がハーネスを自ら改善するのではなく、エージェントにハーネスの管理・改善を指示することです。

Figure 6: Human directs agent to build and improve the how loop

私たちは、エージェントにループのパフォーマンスを評価するために必要な情報を与えることで、フライホイールを構築します。良い出発点は、ハーネスにすでに含まれているテストと評価です。フライホイールは、より豊かなシグナルをフィードバックするにつれて、より強力になります。パフォーマンスを測定し、障害シナリオを検証するパイプラインステージを追加します。本番環境からの運用データ、ユーザー行動ログ、ビジネス結果をフィードバックすることで、エージェントが分析できる範囲と深さを広げます。

ワークフローの各ステップで、エージェントに結果をレビューさせ、ハーネスの改善を推奨させます。スコープには、それらの結果を改善し得るワークフローの上流のあらゆる部分の改善が含まれます。ここで得られるのは、それ自体を改善するための推奨を生成するエージェントハーネスです。

最初は推奨をインタラクティブに検討し、エージェントに特定の変更を実装するようプロンプトします。また、エージェントに推奨をプロダクトバックログに追加させ、優先順位付けしてスケジュールし、エージェントが自動フローの一部として取り上げ、適用、テストできるようにすることもできます。

信頼が得られるにつれ、エージェントはリスク、コスト、メリットを含むスコアを推奨に付与できるようになります。その後、特定のスコアを持つ推奨は自動的に承認・適用されるように決定することも可能になります。

ある時点で、これはループの外にいる人間、つまり旧来のvibe codingのように見えるかもしれません。私は、改善ループが収穫逓減に達するにつれて、頻繁に行われる標準的な作業ではそれが当てはまるだろうと思います。しかし、ハーネスをエンジニアリングすることで、単発の「十分に良い」ソリューションだけでなく、堅牢で、場合によっては反脆弱性のある、継続的に自己改善するシステムを得られるでしょう。