ループエンジニアリング：コード生成と検証の最適化

AI支援のコード生成は、コードを作成するために必要な時間を短縮する一方で、それを理解し検証するために必要な作業を増加させます。この記事では、人間の時間、注意、判断力を維持するプロセスを設計する方法を説明します。具体的には、評価候補を開発するプロセスを改善し、人間が評価に必要な証拠を整理します。 学べること 人間の時間、注意、判断力を維持する。 01 能力と信頼性を区別する 成功が何を証明し、最終的な判定が何を説明せずに残すかを理解する。 02 完了をチェック可能にする 仕様を独立したチェックと強制的な停止ルールに転換する。 03 エージェントが成功できるように準備する 利用可能なコンテキスト、作業ツール、要件を維持するハンドオフを提供する。 04 エラーを検出する。修正を検証する。 繰り返される失敗モードをターゲットを絞ったチェックと制限された修正に転換する。 05 人間によるレビューを容易にする 要件、コード、チェック結果、未解決の質問をまとめる。 06 どのチェックがコストに見合うかを測定する 時間、トークン、人間の労力を比較する。エージェントが変更されたらサポートを再資格認定する。 最適化する4つのループの概要です。 「外側のループ、内側のループ、ビルドループ、学習ループ」をスタンドアロンページとして開く ↗ プロセスを3つのパートで探求します：1. ターミナル評価 · 2. インナーループのエンジニアリング · 3. 学習ループ。 失敗パターンのカタログ、チェック、応答 契約、チェック結果、人間レビューパッケージを使用した説明的なウォークスルー はじめに AI支援ソフトウェア開発における2つの根本的な課題は、意図を正確かつ完全に指定すること、そして生成されたコードがその仕様を満たしていることを検証することです。この記事は、その方程式の後半、つまりAIが書いたコードの検証に主に焦点を当てています。 AI支援のコード生成は、同じ時間でより多くのコードを生成できます。50万人以上のGitHub開発者を対象としたNBERのワーキングペーパーによると、採用後21〜30週の間に、インタラクティブコーディングエージェントは週あたりの変更行数を958%、作成されたPR数を86%増加させ、週あたりのリポジトリリリースは20%増加しました。しかし、コードの作成とテストは、初期アイデアから製品ローンチまでの時間の約25〜35%しか占めない（Bain）と推定されています。より速く、より多くのコードを生成することは、ソフトウェア開発ライフサイクル（SDLC）の他の部分にどのように影響するのでしょうか？ デリバリーの問題 より速い生成は、デリバリーの一部にすぎません。 01 生成 AIが候補を生成します。 02 理解 人間が変更内容とその理由を再構築します。 03 検証 チェックとレビューにより、証拠が何を支持しているかを確立します。 04 リリース 変更を統合、デプロイ、観察します。 この記事は、生成された候補から情報に基づいた受け入れ決定までの作業を削減することに焦点を当てています。 より速いAI支援コード生成が作成する可能性のある検証のボトルネック より速く、より安価なコード生成は、下流プロセスに新たなボトルネックを作成したり、既存のボトルネックを悪化させたりする可能性があります。検証がより負担になる5つの理由があります。 人間がレビューできるよりも速く、より多くのコードが到着する。 エージェントは、この段落を読むのにかかる時間よりも短い時間で千行のコードを生成できますが、人間の読書速度は変わっていません。Osmani、Agentic Code Review。 Farosのテレメトリは、高いAI採用率と98%の統合PR数、91%のレビュー時間増加を関連付けています。Faros 2025。 その量はレビュー能力を超える可能性があります。Farosのより大規模な2026年のデータセットでは、人間またはエージェントによるレビューなしでマージされたPRが31.3%増加しており、著者らは、監視を回避する決定よりも、レビュー担当者が追いつけないことが原因である可能性が高いと示唆しています。Faros 2026。 間違ったコードでも非常に妥当に見える。 エラーを見つけるには、ファイル間の変更を追跡し、動作と要件を比較するために、より多くの時間が必要になる場合があります。JetBrains–Lund研究。 Sonarの2026年の調査では、開発者の61%が、AIは正しく見えるが信頼性の低いコードを生成できることに同意しました。Sonar。 METRの2025年初頭の研究でも、信頼性の低いAI出力（開発者が最終的に破棄した出力を含む）のレビュー、テスト、修正に費やされた時間が、タスク完了の遅延の一因であることが特定されました。METR分析。 理解の負債。 チームの誰も実装を書かなかった場合、レビューは人間が通常もたらす理解なしに始まります。Osmaniは、コードと人間の理解の間のギャップの拡大を「理解の負債」と呼び、お互いの差分を読むことがシステム知識を副作用として広めることがあったと述べています。Osmani、Agentic Code Review。 Anthropicによる52人のエンジニアが新しいライブラリを学習したトライアルでは、AI支援を使用したグループはほぼ同じ時間で完了しましたが、その後の理解度クイズでは17パーセントポイント低いスコア（50%対67%）でした。Anthropic。 変更が大きくなり、問題が増える。 FarosはAI採用を平均PRサイズの154%増加と、開発者あたりのバグ数の9%増加と関連付けています。そのより大規模な2026年のデータセットでは、その数値は54%と報告されています。Faros 2025、Faros 2026。 470のオープンソースPRの研究では、CodeRabbitはAI共著の変更がPRあたり約1.7倍の問題を抱えていることを発見しました。CodeRabbit。 平均すると、各レビューはより多くの変更と修正すべき内容をカバーする可能性があります。 チェックも信頼性が低い。 テストと静的解析は役立ちますが、誰も考えていなかった動作のテストを書くことはできません。AIが動作を変更し、数百のテストをそれに合わせて更新した場合、問題は「このコードは正しいか？」から、それらのテスト変更が必要だったかどうかへと移行します。Osmani、Comprehension Debt。 したがって、合格したテストスイートは、コードに合わせるためにテストが書き直されたことを意味する可能性があり、評価者のチェックと期待される結果が、ビルダーの変更権限の外に置かれる必要がある理由です。 私たちは過去12ヶ月間これらの方法を開発しており、独自のパイプラインを実行し、コード生成に使用してきました。例のコードをクリーンで分かりやすくするために、独自の実行結果よりも、分かりやすい例を選択しました。この記事では測定された節約量については報告していません。この方法は、ご自身のワークフローでテストされることを意図しています。 1. ターミナル評価 ターミナル評価とは何ですか？ ターミナル評価は、自律的な試行の結果のみを判断します。タスクと成功基準が与えられると、AIシステムは、定義された成功基準を満たす結果を生成したと信じるまで自律的に作業します。その後、評価者がその結果を基準に対してチェックします。コーディングワークフローでは、結果は候補であり、基準は合意された仕様です。 判定は合格または不合格、部分的なスコア、または複数のスコアになります。最終的な判定は、結果が基準を満たしたかどうかを私たちに伝えますが、システムがどのようにそこに至ったかについては何も伝えていません。 その判定により、2つの異なる質問をすることができます。 能力：この設定されたシステムはタスクを実行できますか？成功した結果は、テストされた条件下でそれが可能であることを示しています。 信頼性：どのくらい一貫して成功しますか？同等の条件下でタスクを繰り返すことで、その一貫性を推定できます。一度成功したシステムは、100回の試行のうち99回成功したシステムとは異なるものを証明しました。 どちらの質問も、モデル単体ではなく、設定されたシステムに関するものです。設定には、ベンダーのモデルとハーネス（合わせてベンダーのエージェント）、およびそれに追加するもの（カスタムハーネス、ツール、コンテキスト、操作制限、グラフ、パイプライン）が含まれます。これらをいずれか変更すると、結果が変わる可能性があるため、能力と信頼性は新しい設定で再測定する必要があります。公平な比較のために、同じタスクと成功基準を使用し、予算とリトライポリシーを比較可能にし、失敗した試行を含めてください。 テーマのバリエーション エージェントベースのベンチマーク（evals）、プロンプトエンジニアリング、仕様駆動開発（SDD）、ループエンジニアリングは、共有される基本的なプロセスの4つのバリエーションです。AIにタスクを与え、自律的にタスクを実行させ、結果を評価します。各バリエーションはそのプロセスの異なる部分を強調しますが、他のバリエーションによって強調されるプラクティスを採用することを禁止するものではありません。例えば、独立した評価者、強制的な停止条件、自動化された