開発者は1人。チームはなし。2つのAIコーディングエージェントが、並列でターミナルセッションを動かしているだけです。
4か月後：PRの受け入れ率81%、テストカバレッジ91%。不具合は報告からマージされる修正まで、だいたい30分で進みます。
より良いモデルではありませんでした。コードベースが「測る」ことを学んだ結果、それがこうなったのです。
「AI支援のあるコードベースにある“知性”は、モデルそのものよりも、コードベースがそれを取り囲むように組み込んだループの中に宿る。」
実際に何が変わったのか
CNCF Sandbox内のマルチクラスターKubernetes管理ダッシュボードであるKubeStellar Consoleが、その検証の場でした。そこでの経験から、AIコードベース成熟度モデルの5つの段階が生まれました。エージェントのはねっ返り（楽しい新鮮さ）から、ほぼ自律的な開発ループへと至る道筋です：
1. 指示された — 従来あなたが直し続けていたものを外部化する：CLAUDE.md、PRの作法、却下理由ガイド。これらをまとめると、AI PRが却下されていた理由のおよそ90%をカバーできました。
2. 測定された — テストは正しさを保証する“層”ではありません。自律的なワークフローでは、それは信頼の層です。32の夜間スイート、91%のカバレッジ。受け入れ率はカテゴリ別に記録されます。（この環境でフレークテストが不快感を与えるわけではありません。静かに、下流のあらゆるマージ判断を汚染してしまうのです。）
3. 適応する — 測定できるようになったら、自動化が自己調整するようにします。受け入れ率の低いカテゴリは優先度が下がり、CIのサイクルは実際に着地するものに寄せられます。
4. 自己維持可能 — コードベースが運用マニュアルになります。メンテナーが確認する前に、課題がトリアージされ、修正され、テストされ、キューに積まれていきます。
5. 命令ではなく問いかけをする — 「なぜこれを見つけられなかったの？」が「この不具合を直して」よりも勝ちます。前者はパッチを得るだけでなく、後者は根本原因をもたらし、新しいテストと、将来の失敗の“まとまり”そのものをブロックすることになります。
教訓
モデルは差別化要因ではありません。
「モデルはコモディティ（汎用品）で、別のものに差し替えるのは週末の作業です。周囲のフィードバックシステムを作り直すのが、仕事の四半期分です。」
重要なのは、指示ファイル、テストスイート、受け入れ指標、ワークフローのルールです。これが知性のインフラです。モデル選定の最適化に取り組むチームは、間違った変数を最適化しています。
特にオープンソースのメンテナーにとっては、この見方が燃え尽き問題を捉え直してくれます。コードベースが十分な判断をエンコードしていてエージェントがトリアージとPR生成を扱えるなら、メンテナーは日々のオペレーターからシステム設計者へと移行できます。
やるべきこと
- 「プロンプトを書いて、出力をレビューする」モードのままですか？ それは最初の段階です。通常のスタート地点。問いましょう：AIの出力を却下する最も一般的な理由は何ですか？書き留めます。これが2段階目です。
- テストはあるのに、まだドリフトしていますか？ まず決定性（determinism）です。フレークテストは自律的なワークフローでは致命的です。土台の上に何かを積む前に修正してください。
- カテゴリ別に受け入れ率をログに取っていますか？ たぶん、適応的な重み付け（adaptive weighting）の準備ができています。測定できるようになる前に自動化しないでください。
- エンジニアリング主導（leading engineering）をしていますか？ 使っているモデルの種類の最適化をやめましょう。何のフィードバックループが欠けているかを問いかけてください。
出典：Beyond prompting: How KubeStellar reached 81% PR acceptance with AI agents — The New Stack
✏️ KewBot（AI）で下書きし、Drewが編集・承認しました。
