要旨
自動実装はしばしばcode generation問題として語られる。しかしそれは狭すぎる。難しいのはcodeを書くことではない。code changeの中でintent、responsibility、evidence、reversibilityを保存することである。Dynamic harnessは、自動実装を気の利いたassistantではなく、統治されたruntime actorに変える。
Governed auto-implementation loopはresearch intentから始まる。note、issue、design sketch、failure episode、product requestなどである。harnessはそれをscopeへ変換し、影響coordinateを特定し、implementation planを生成し、bounded patchを適用し、関連episodeをreplayし、riskを分類し、automatic merge、agent review、human approvalへrouteする。
1. Code generationとauto-implementationの違い
Code generationはfileを生成する。Auto-implementationはsystemを変える。この違いは重要である。生成されたfileが見事でも、system全体は悪化することがある。実装とはinterface、test、product intent、runtime evidence、accessibility、security、governance、operational costを保存しながら変更することである。必要なのはmodel callではなくcontrol loopである。
Governed auto-implementationには3つの不変条件がある。第一に、すべてのimplementationはintent objectに結びつく。第二に、すべてのimplementationは関連harness episodeのreplayで評価される。第三に、すべてのimplementationはmerge前にauthority riskで分類される。
2. Intent object
Intent objectは、なぜその変更が存在すべきかの構造表現である。human request、failed runtime episode、regression detector、roadmap、research noteから発生する。harnessは生のrequestをmachine-checkable objectへ変換する。
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である。自動実装は、何をするかだけでなく、何に触れてはいけないかを知る必要がある。negative scopeがなければ、implementation agentは隣接問題を解き、無関係なrefactorを行い、直近taskを楽にするためにauthority boundaryを変更しがちである。
3. 7段階ループ
Governed loopは7段階である。Intent parseはproseをstructured targetへ変換する。Scope resolutionはtargetをfile、API、data contract、UI surface、MARIA coordinateへ対応づける。Plan generationは最小実装案を出す。Patch synthesisはcodeを編集する。Replayはharness basisを実行する。Risk classificationはpatchがauthority、data、security、schema、prompt、workflow boundaryに触れたかを判定する。Approval routingはauto merge、agent review、human approvalのどれかを決める。
このloopはpatch synthesisとapprovalを意図的に分離する。Implementation agentはpatchを書ける。しかしpatchを進めてよいかを決めるのはharnessである。
4. Risk class
Auto-implementation changeは4分類できる。Class 1はcosmeticで、copy、layout、style、documentationなどbehaviorを変えないもの。Class 2はlocal behaviorで、component、utility、routeの boundedな振る舞いを変えるもの。Class 3はworkflow behaviorで、step order、retry、escalation、evaluationを変えるもの。Class 4はauthority mutationで、誰が決めるか、いつgateが発火するか、どのevidenceが必要か、何を自動修正できるかを変えるもの。
| Risk class | 例 | Default route |
|---|---|---|
| Class 1 | Text, responsive CSS, docs | build後にauto |
| Class 2 | Local UI logic, helper behavior | test後にagent review |
| Class 3 | Workflow DAG, retry policy, scoring | production-boundならhuman approval |
| Class 4 | Authority, schema, policy, prompt core | human approval必須 |
Dynamic harnessはここで保守的であるべきだ。code上は小さな変更でもauthority上は大きいことがある。例えばthresholdを0.82から0.75へ変えるのは1行だが、そのthresholdがhuman escalationを制御しているならauthority mutationである。
5. Reviewable artifactとしてのimplementation plan
Riskが高い時、patchの前にimplementation planをreviewできるべきである。Planにはaffected files、intended diffs、expected tests、expected score changes、rollback strategyが含まれる。これによりimplementation agentはcodeを書く前に説明責任を持つ。
良いplanは小さい。広いrefactorよりlocal patchを選び、新しい抽象より既存patternを選び、architecture ambitionよりtestable behaviorを選ぶ。harnessはevidenceなしにscopeを広げるplanを減点すべきである。
6. Merge predicateとしてのreplay
中心となるmerge predicateは、patchがcompileするかではない。compileは必要だが十分ではない。patchは関連runtime state vectorを改善または保存しなければならない。vectorにはquality、responsibility、evidence completeness、latency、cost、reversibilityが含まれる。
Class 1変更ではharness basisは小さくてよい。Class 3または4変更では、adversarial episode、rollback test、approval-path verificationを含める必要がある。
7. MARIA OS内部の自動実装
MARIA OS内部では、auto-implementationを制限されたauthorityを持つinternal agentとして扱うべきである。patchを提案し、testを実行し、failureを読み、draft pull requestを作ることはできる。しかしproduction schema、global policy、core prompt、自分自身のauthority拡張を静かに変更することはできない。それらは明示gateを必要とする。
この設計はautonomous implementationの利点を保存しながら、recursive authority creepを防ぐ。Implementation agentはsystemを改善できる。しかしsystemを改善する憲法そのものは決められない。
結論
Governed auto-implementationは、より良いpromptによるcode generationではない。code changeを囲むruntime control loopである。Dynamic harnessは、intent、scope、replay、risk classification、approval、rollbackという欠けていた構造を提供する。この構造があれば、内部自動実装は制御不能な生産性demoではなく、測定可能なengineering capabilityになる。