要旨
自動実装は、コード生成の問題として捉えられることがよくあります。その枠組みは狭すぎます。難しいのはコードを生成しないことです。難しいのは、コードを変更する際に、意図、責任、証拠、可逆性を維持することです。動的ハーネスは、自動実装を投機的なアシスタントから管理されたランタイム アクターに変えることができます。
管理された自動実装ループは、メモ、問題、設計スケッチ、失敗エピソード、製品リクエストなどの調査目的から始まります。ハーネスは、そのインテントを解析してスコープに入れ、影響を受ける座標を特定し、実装計画を生成し、境界付きパッチを適用し、関連するエピソードを再生し、リスクを分類し、結果を自動マージ、エージェントのレビュー、または人間の承認にルーティングします。
1. コード生成と自動実装の違い
コード生成によりファイルが生成されます。自動実装はシステムを変更します。生成されたファイルは印象的ですが、システムは悪化する可能性があるため、この区別は重要です。実際の実装では、インターフェイス、テスト、製品意図、実行時の証拠、アクセシビリティ、セキュリティ、ガバナンス、および運用コストを維持する必要があります。これには、モデル呼び出しだけでなく、制御ループが必要です。
したがって、管理された自動実装には 3 つの不変条件があります。まず、すべての実装をインテント オブジェクトにリンクする必要があります。次に、すべての実装は、関連するハーネス エピソードを再生して評価する必要があります。第三に、すべての実装をマージする前に、権限リスクによって分類する必要があります。
2. インテントオブジェクト
インテント オブジェクトは、変更が存在する理由を構造化して表現したものです。それは、人間のリクエスト、ランタイムの失敗エピソード、回帰検出器、製品ロードマップ項目、または調査メモから発生する可能性があります。ハーネスは、生のリクエストをマシンチェック可能なオブジェクトに変換します。
type ImplementationIntent = {
id: string
source: "human" | "episode" | "regression" | "roadmap" | "research"
summary: string
coordinates: string[]
expectedBehavior: string[]
forbiddenChanges: string[]
evidenceRequired: string[]
approvalPolicy: "auto" | "agent-review" | "human"
}キーフィールドは「forbiddenChanges」です。自動実装では、何をすべきかだけでなく、何を触ってはいけないのかを把握する必要があります。ネガティブな範囲がなければ、実装エージェントは隣接する問題を解決したり、無関係な領域をリファクタリングしたり、権限境界を変更したりする傾向があります。これらの変更により当面のタスクが容易になるからです。
3. 7段ループ
管理されたループには 7 つのステージがあります。インテント解析は散文を構造化されたターゲットに変換します。ファイル、API、データ コントラクト、UI サーフェス、および MARIA 座標をターゲットとするスコープ解決マップ。計画の生成では、実行可能な最小の実装が提案されます。パッチ合成ではコードを編集します。リプレイはハーネスベースを実行します。リスク分類により、パッチが権限、データ、セキュリティ、スキーマ、プロンプト、またはワークフローの境界に触れたかどうかが決まります。承認ルーティングは、変更を自動的にマージできるか、エージェントのレビューが必要か、人間による待機が必要かどうかを決定します。
このループは、パッチの合成を承認から意図的に分離します。実装エージェントはパッチを作成できますが、そのパッチを続行できるかどうかはハーネスが決定します。
4. リスククラス
自動実装の変更は 4 つのリスク クラスに分類されます。クラス 1 は表面的なもので、動作を変更しないコピー、レイアウト、スタイル、ドキュメントです。クラス 2 はローカル動作です。コンポーネント、ユーティリティ、またはルートは、境界のあるサーフェス内で動作を変更します。クラス 3 はワークフローの動作です。この変更により、ステップの順序付け、再試行、エスカレーション、または評価の方法が変更されます。クラス 4 は権限の突然変異です。この変更は、誰が決定できるか、いつゲートが作動するか、どのような証拠が必要か、または何を自動的に変更できるかに影響します。
| Risk class | Examples | Default route |
|---|---|---|
| Class 1 | Text, responsive CSS, docs | Auto after build |
| Class 2 | Local UI logic, helper behavior | Agent review after tests |
| Class 3 | Workflow DAG, retry policy, scoring | Human approval if production-bound |
| Class 4 | Authority, schema, policy, prompt core | Human approval required |
ここでのダイナミック ハーネスは保守的である必要があります。コード内では小さな変更に見えても、大きな権限を持つ可能性があります。たとえば、しきい値を 0.82 から 0.75 に変更するのは 1 行かもしれませんが、そのしきい値が人間のエスカレーションを制御する場合、それは権限の突然変異です。
5. レビュー可能な成果物としての実装計画
リスクが高い場合は、パッチを適用する前に実装計画を検討する必要があります。これには、影響を受けるファイル、意図された差分、予想されるテスト、予想されるスコアの変更、およびロールバック戦略が含まれます。これにより、実装エージェントはコードを記述する前に責任を負うことになります。
良い計画は小さなものです。広範なリファクタリングよりもローカル パッチを、新しい抽象化よりも既存のパターンを、アーキテクチャ上の野心よりもテスト可能な動作を好みます。このハーネスは、証拠なしに範囲を拡大する計画を罰すべきである。
6. マージ述語として再生する
マージ述語の中心は、パッチがコンパイルされるかどうかではありません。コンパイルは必要ですが不十分です。パッチは、関連する実行時状態ベクトルを改善または維持する必要があります。そのベクトルには、品質、責任、証拠の完全性、待ち時間、コスト、可逆性が含まれます。
クラス 1 の変更の場合、ハーネスの基準は小さい場合があります。クラス 3 または 4 の変更の場合、根拠には敵対的なエピソード、ロールバック テスト、および承認パスの検証が含まれている必要があります。
7. MARIA OS の内部自動実装
MARIA OS 内部では、自動実装は権限が制限された内部エージェントとして扱われる必要があります。パッチの提案、テストの実行、障害の検査、およびドラフト プル リクエストのオープンが可能です。実稼働スキーマをサイレントに変更したり、グローバル ポリシーの変更を展開したり、コア プロンプトを書き換えたり、独自の権限を拡張したりすることはできません。これらの操作には明示的なゲートが必要です。
この設計は、再帰的な権限のクリープを防止しながら、自律実装の利点を維持します。実施主体はシステムを改善することはできるが、システムを改善するための構成を決めることはできない。
結論
管理された自動実装は、より適切なプロンプトを備えたコード生成ではありません。これは、コード変更に関するランタイム制御ループです。ダイナミック ハーネスは、意図、スコープ、リプレイ、リスク分類、承認、ロールバックなどの欠落している構造を提供します。この構造により、内部の自動実装は、管理されていない生産性のデモではなく、測定可能なエンジニアリング能力になります。