ハーネスエンジニアリングのプラクティス P6. 多層検証ピラミッド（ループ位置に検証頻度を合わせる） 🎯 ポイント 全ステップで10分のE2Eテストを回したら、エージェントの思考は10分ごとに止まります。検証にも「軽重」の設計が必要です。 📝 概要 速く安い検証（型チェック・lint）は毎ステップ、中程度の検証（単体テスト）はマイルストーンごと、遅く高い検証（結合・E2Eテスト）は完了ゲートで実行します。検証のケイデンスをループ位置に合わせることで、レイテンシ税を最小化します。 🔍 解説 すべての検証を毎ステップで実行するのは非効率であり、逆にすべてを完了時にまとめて実行するのはリスクが高すぎます。テストピラミッドの考え方を検証タイミングにも適用するのがこのプラクティスです。型チェックやlintは数秒で終わるため毎ステップで実行してもレイテンシへの影響は軽微です。一方、E2Eテストは数分かかるため、頻繁に実行するとエージェントの作業効率を大きく損ないます。ループの内側に速い検証を、ループの外側に遅い検証を配置することで、フィードバックの速度と網羅性を両立させます。 🛠 実践方法 ・検証を3層に分類します：毎ステップ（型チェック・lint、数秒）、マイルストーン（単体テスト、数十秒）、完了ゲート（結合・E2E、数分） ・ハーネスのループ構造に検証タイミングを組み込み、各層が自動的に適切なタイミングで実行されるようにします ・各層のレイテンシを計測し、ループ内検証が遅すぎる場合はテストの範囲を絞るか並列化で対応します ・層の間に検証の死角がないか定期的に確認し、カバレッジのギャップを埋めます 💼 ユースケース ・ペアプログラミングで、編集のたびに型チェックだけ即座に実行し、影響範囲のテストだけを走らせる場面 ・issue-to-PRエージェントで、実装中は単体テストで検証し、完了宣言前にCI全体を実行する場面 ・CI自動メンテナンスで、トリアージは安いチェックで行い、修正の検証だけフルテストを回す場面 ⚠ 落とし穴 ピラミッドの層を間違えると、速度と品質の両方を失います。重い検証を頻繁に回せばレイテンシで死に、軽い検証しか回さなければリグレッションが流出します。また、「型チェックが通ったから大丈夫」という過信も危険です。各層の検証がカバーする範囲を正確に理解し、層の間に死角がないか確認することが重要です。 #HarnessEngineering# #TestingStrategy#

新しいブログを公開しました 📝 「Buzzword engineering」 新しい技術や概念が次々と生まれ、情報が飛び交う現代。「〇〇」という言葉の響きだけが先行して、本来の目的や技術の本質を見失ってしまうことはありませんか？🤓 Prompt Engineering、Context Engineering、Harness Engineering、そしてLoop Engineering——LLMの登場からわずか数年で、私たちは少なくとも四つの「Engineering」の誕生に立ち会いました。なぜ、前の名前が方法論として成熟する前に、次の名前が到着するのでしょうか 🤔 📖本稿では、この現象を「Buzzword engineering」と名付けて解剖しました。正体は、速度の非対称です。LLMによって方法論を「提案」するコストはほぼゼロになり、いまやLLM自身が提案の主体になり始めています。一方で「検証」は、プロダクトがユーザに使われて初めて完了するため、人間の行動速度に律速されたままです。提案は機械の速度で進み、検証は人間の速度で進む——その隙間に、検証待ちの名前が堆積していくのです。 🅱️ただし、本稿はバズワードを嗤う記事ではありません ⚙️ シュンペーターの「群生」やハイプサイクルが示すように、乱立はイノベーションの標準的な進行表に最初から書き込まれた現象であり、世界中のエンジニアの注意を揃える知識創造の第一工程でもあります。 ⚙️その上で提案するのは、週単位で回る「方法論の時計」と、年単位で回る「プロダクト価値の時計」とをつなぐ変速機、すなわちxOpsを整えることです。複利で増える評価資産、エージェントへの権限委譲を観測で運用する「自律性予算」、そして「命名するなら反証条件とevalを添えよ」という規範——LLM/エージェント時代のプロダクト開発の進む先を考えました。 方法論は減価し、評価資産は複利で増えます。次々と現れる新しい名前に少し疲れた方にこそ、読んでいただきたい一本です 🚀 👇日本語版はこちら #バズワードエンジニアリング# #AI#