この記事の出発点は、記事自身が「かなり広く受け入れられている」と呼ぶ見方である。すなわち、AI コーディングツールは実際の本番コードベースでは苦戦しており、それらが余分に出荷するコードの多くは手戻りであって、コーディングエージェントは新規プロジェクトや小さな変更には役立つものの、大規模で成熟したコードベースではかえって開発者の生産性を下げかねない、という見方である。記事は、創業者たちからも同じ声(「スロップが多すぎる」「技術的負債の工場」)を聞いていると報告する。これに対する著者の主張は、コンテキストエンジニアリングの中核となる原則を取り入れれば今日のモデルでもかなりのところまで到達できる、そしてコーディングのための AI はおもちゃやプロトタイプ向けのものではなく、高度に技術的なエンジニアリングの技能である、というものである。この記事は、著者が Y Combinator で行った講演に基づいている。

記事が説明する一連の手法を、著者は 頻繁な意図的コンパクション と呼ぶ。これは、開発ワークフロー全体をコンテキスト管理を中心に設計し、コンテキスト使用率をおおよそ 40〜60% の範囲に保ち、作業を調査・計画・実装のステップに分けて、最もレバレッジの高い時点で人間がレビューするというものである。その根拠として記事はチーム自身の成果を報告している。たとえば、著者が一度も触れたことのない 30 万行の Rust コードベースである BAML で Claude Code を機能させ、バグ修正の PR が翌朝にはメンテナーに承認されたこと、また 2 人が 7 時間のセッションでキャンセルと WASM のサポートを追加する 3 万 5,000 行を出荷したことである。記事によれば、後者の作業はシニアエンジニアでもそれぞれ 3〜5 日かかると見積もられていた。

要点

  • 記事は、Claude Code のようなエージェントのターンは、どの時点をとってもステートレスな関数呼び出し、つまりコンテキストウィンドウを入力に受け取って次のステップを出力するものだと論じる。そのため(モデルの訓練やチューニングを除けば)コンテキストウィンドウの中身が出力品質を左右する唯一のレバーになるという。ウィンドウは正確さ、完全さ、サイズ、軌跡の観点で最適化すべきだとし、ウィンドウに起こりうる最悪の事態を、誤った情報、次に情報の欠落、次に過剰なノイズの順に挙げている。
  • コーディングエージェントをチャットボットのように使うのは素朴なアプローチとして、新しいセッションでもう少し誘導を加えてやり直すのはやや賢いアプローチとして示される。「意図的コンパクション」、すなわちいったん手を止めて進捗を progress.md のようなファイルに書き出し、それから新しいコンテキストを始めるやり方は、さらに一歩進んだものである(コンパクション を参照)。
  • サブエージェントは、擬人化された役割のためではなく、コンテキストを制御するためのものとして説明される。サブエージェントを使えば、探す・検索する・要約するといった作業を新しいコンテキストウィンドウの中で行えるので、親エージェントのコンテキストがそれらの呼び出しで濁らずに済む。
  • 調査・計画・実装のワークフローは、チームが頻繁な意図的コンパクションを実践するための方法である。関連するコードを理解するための調査、正確な手順と検証方法を示す計画、そしてフェーズごとの実装から成る。
  • 人間のレバレッジについて、記事は次のように論じる。悪いコード 1 行はただの悪い 1 行だが、計画の悪い 1 行は数百行の悪いコードを生む可能性があり、調査の悪い 1 行は数千行を生む可能性がある。したがって、コードだけをレビューするよりも、調査と計画を人間がレビューするほうが大きなレバレッジが得られるという。
  • 記事によれば、チームにとってこのワークフローで最も重要なのはメンタルアラインメントである。誰もが以前より多くのコードを出荷するようになると、個々のエンジニアにとって馴染みのないコードベースの部分が増えるため、チームは今ではプルリクエストだけでなく、仕様・計画・調査を通じて認識を揃えている。
  • チームは Sean Grove の「仕様駆動開発」に近いものを採用した(仕様駆動開発 を参照)。著者は、その移行に約 8 週間かかり、居心地の悪いものだったと報告している。仕様が信頼できる唯一の情報源になる一方で、著者自身は今もテストを注意深く読んでいるという。
  • 記事は、これが「魔法ではない」ことを強調する。このアプローチは人間が深く関与し続けてはじめて機能するとし、parquet-java から Hadoop への依存を取り除こうとして失敗した例を報告している。失敗の原因は、調査が十分に深くなかったことと、そのコードベースの専門家がいなかったことにあるとされる。

背景

報告されている成果はすべて著者とそのチーム自身のもので、自分たちのプロジェクトやペアリングセッションから得られたものである。著者は、3 人のチームが Opus に平均で月およそ 1 万 2,000 ドルを費やしていると記している。記事は、AI Engineer 2025 の 2 つの講演が自身の考え方を形作ったとし、コンテキストウィンドウを使えば使うほど結果が悪くなるという Geoffrey Huntley の見方を引用するとともに、シンプルなプロンプトでエージェントをループ実行させる彼の「Ralph」手法にも触れている(Ralph Loop を参照)。LLM はステートレスな関数であるという前提については HumanLayer の 12-factor agents を参照し、最後に HumanLayer の CodeLayer がプライベートベータであることを告知して締めくくっている。関連ページには コンテキストエンジニアリング、コンテキストロット、12 Factor Agents がある。