頻繁な意図的コンパクション（frequent intentional compaction）とは、HumanLayer の コーディングエージェントのための高度なコンテキストエンジニアリング が、大規模で複雑なコードベースでコーディング エージェントを機能させるための一群の技法に与えた名前である。その内容は、開発ワークフロー全体をコンテキスト管理を 中心に設計し、エージェントにコンテキストを与える方法を全工程にわたって意図的に構造化し、問題の複雑さに応じて コンテキスト使用率をおおむね 40%〜60% の範囲に保つことである。これは、記事が「意図的コンパクション」と呼ぶもの ——コンテキストが埋まってきたら手を止め、目標、アプローチ、進捗、現在の失敗をファイルに書き出し、新しい コンテキストウィンドウでやり直すこと——を、ときおりの救済策からあらゆるタスクの構造へと拡張したものである。
用法
記事では、チームは機能やバグごとに 3 ステップ（「程度」の）ワークフローとしてこれを実践している。リサーチでは、 関連するファイル、情報の流れ、問題の考えられる原因についての理解を築く。計画では、正確な手順、編集する ファイルとその方法、各フェーズのテストと検証を定める。実装では、計画をフェーズごとに進め、検証済みの フェーズを終えるたびに現在の状況を計画ファイルへとコンパクションし直すことが多い。著者は、リサーチを省いたり 複数回行ったりすることもあると述べ、親のコンテキストをきれいに保つために検索と要約にはサブエージェントを使い、 git ワークツリーが必要なのは実装ステップだけだとしている。記事はチームのリサーチ、計画、実装用のプロンプトを 公開している。
適用される場面
記事はこれを、素朴なチャット形式の使い方がうまくいかない傾向があると報告されているブラウンフィールドの コードベースや複雑な問題向けに提示している。これは深く関与し続ける人間を前提とする。著者は、これは 「魔法ではない」と強調し、頻繁な意図的コンパクションは性能を高めるが、難しい問題に対して十分なものにするのは、 パイプラインに高いレバレッジを持つ人間のレビューを組み込むことだと述べる——リサーチや計画の誤りは多数の誤った コード行へと増幅されるため、コードだけでなくリサーチと計画をレビューするのである。そのレビューが浅いリサーチを 見逃すと、この手法は失敗する。記事は、parquet-java から Hadoop への依存を取り除く試みが、リサーチが十分に 深くなかったためにうまくいかなかったと報告し、少なくとも一人のコードベースの専門家がおそらく必要だと示唆している。 根拠は著者のチーム自身の経験（BAML の Rust コードベースでのバグ修正と 3 万 5 千行の機能追加、初日に 2 本、 8 日目に 10 本の PR を出したインターン）である。著者自身は、リサーチ／計画／実装がほとんどのチームにとって 正しいアプローチだとは考えていないと述べる一方で、どのチームにもメンバーの足並みをそろえ、不慣れなコードを 素早く学べるようにするプロセスが必要だと論じている。