Das Jevons-Paradoxon im AI-Engineering

1. Konzept und Essenz (Überblick und systemisches Problem)

Das Jevons-Paradoxon im KI-Ingenieurwesen ist ein systemischer Effekt, bei dem die Senkung der Kosten und Latenz für die Codegenerierung das Gesamtvolumen der Ingenieursarbeit nicht reduziert, sondern es bis zu einem Punkt erhöht, an dem nicht mehr Inference, sondern Verifikation, Refactoring, Review und Architekturwartung zum Engpass werden. Die klassische Formel von Jevons besagt: Eine Steigerung der Ressourceneffizienz senkt die Stückkosten und stimuliert eine höhere aggregierte Konversion. Im AI Engineering ist die Ressource nicht Kohle, sondern „plausible code change“: Diff, Patch, Scaffold, Migration, Test, PR.

Technisch formuliert sich das Problem wie folgt:

C_gen ↓  =>  D_gen ↑↑  =>  ReviewLoad ↑↑  =>  ReviewLatency ↑↑  =>  Burnout ↑↑ + TechDebt ↑↑

Dabei ist C_gen die Grenzkosten für die Generierung eines akzeptablen Draft-Changes, D_gen die aggregierte Nachfrage nach Änderungen und ReviewLoad die Belastung der Verifikation. Wenn ReviewLoad die reviewer_capacity übersteigt, wird das System nicht schneller; es wird toxischer.

In der Vor-AI-Ära war die Erstellung eines PRs teuer: Der Ingenieur schrieb den Code manuell, hielt den Kontext im Kopf und schickte die Änderung erst dann zum Review. Die KI-Codegenerierung wandelt diesen Zyklus in einen System 1-Prozess um: schnell, imitativ, hochfrequent. Das Modell generiert Diffs in Sekunden. Aber Review ist System 2: langsam, semantisch, eine begrenzte Ressource. Wenn die Kosten für einen Draft um eine Größenordnung fallen, erhöht das Team intuitiv die Anzahl der Drafts, ohne die Kapazität für die semantische Verifikation proportional zu steigern.

Die Mechanik der Kostensenkung bei der Generierung kombiniert mehrere Infrastruktur-Faktoren:

• FlashAttention und optimierte Kernels reduzieren die Compute-Kosten für Long-Context-Inference.
• RoPE und moderne Position-Schemes ermöglichen stabiles Arbeiten mit großen Kontexten.
• KV Cache senkt die Latenz in Multi-Turn-ReAct loops und Agent-Sessions.
• Unpadding und Dynamic Batching reduzieren Overhead bei der Verarbeitung variabler Prompt-Längen.
• ModernBERT-ähnliche Retrieval-/Reranking-Schichten ermöglichen günstigeren Code Search, sodass das Modell mehr relevanten Kontext zu geringeren Kosten erhält.
• Fast Patching und diff-aware Generation reduzieren die Anzahl der Tokens, die für die Anwendung einer Änderung erforderlich sind.

Jeder dieser Faktoren verbessert einzeln den Durchsatz. Zusammen schaffen sie eine Ökonomie, in der „einen weiteren Versuch starten“ fast kostenlos wird. Aber ein „kostenloser Draft“ bedeutet nicht eine „kostenlose Änderung in Produktion“. Eine Änderung in Produktion erfordert:

1. Verständnis dafür, warum der Diff existiert.
2. Überprüfung, dass er keine Invarianten bricht.
3. Bestätigung, dass er keinen versteckten technischen Schuldposten hinzufügt.
4. Bewertung der Auswirkungen auf Latency, Cost, Security und Operability.
5. Bereitschaft, den Code in Zukunft zu warten.

Die Ökonomie der AI-Codegenerierung wird oft falsch gemessen:

Ein kritischer Fehler im architektonischen Denken besteht darin, tokens/sec und time-to-first-diff zu optimieren, während time-to-verified-merge ignoriert wird. Das Jevons-Paradoxon im AI Engineering dreht sich nicht darum, dass KI schlechten Code generiert. Es geht darum, dass das System am Eingang schneller wird, aber am Ausgang langsamer, weil menschliche Verifikation nicht über GPUs skaliert.

2. Architektur und interne Mechanik (Taxonomie und mentales Modell)

Der vollständige Kreislauf des KI-unterstützten Engineerings besteht aus drei Ebenen:

1. Generation plane – Schnelle Generierung von Drafts, Patches und Scaffolds.
2. Verification plane – Testing, statische Analyse, Review, Security Gates.
3. Governance plane – Budgets, Richtlinien, Metriken, Rollbacks, Owner-Grenzen.

Das Paradoxon entsteht, wenn die Generation plane hardwareseitig skaliert, während die Verification plane sozial limitiert bleibt.

┌────────────────────────────┐
│ Engineer / Product Request │
└─────────────┬──────────────┘
              │ task + constraints + repo state
              ▼
┌────────────────────────────┐
│ Context Builder            │
│ - code search / ModernBERT │
│ - MCP resources            │
│ - dependency graph         │
│ - policy manifest          │
└─────────────┬──────────────┘
              │ prompt bundle + token budget
              ▼
┌──────────────────────────────────────────────┐
│ Model Runtime                                │
│ FlashAttention | RoPE | KV Cache | Unpadding │
│ ReAct loop / tool calls / draft generation   │
└─────────────┬────────────────────────────────┘
              │ raw diff / patch / files
              ▼
┌────────────────────────────┐
│ Fast Patching + Normalizer │
│ - split large diff         │
│ - enforce patch size       │
│ - add provenance           │
└─────────────┬──────────────┘
              │ CodegenResult
              ▼
┌────────────────────────────┐
│ Verification Plane         │
│ Pydantic AI | Guardrails   │
│ unit/integration tests     │
│ SAST/SCA/secret scan       │
│ reviewer queue             │
└─────────────┬──────────────┘
              │ pass / fail / request changes
              ▼
┌────────────────────────────┐
│ Merge / Deploy / Telemetry │
└─────────────┬──────────────┘
              │ feedback: latency, defects, churn
              ▼
┌────────────────────────────┐
│ Governance Plane           │
│ budgets, quotas, rollback  │
│ review load, tech debt     │
└────────────────────────────┘

Taxonomie der Komponenten:

• Request: Ingenieursaufgabe, Geschäftsabsicht, Einschränkungen, Risikostufe.
• Context Builder: Sammelt relevante Dateien, Tests, Dokumentation, vergangene PRs. Nutzt Retrieval, Embeddings, Reranker.
• Model Runtime: Inference-Schicht. KV Cache reduziert die wiederholte Berechnungskosten in Multi-Turn-Sessions; FlashAttention optimiert Attention; Unpadding reduziert Waste im Batching.
• ReAct loop: Agentischer Zyklus reason -> act -> observe. Nützlich, erzeugt aber bei günstigen Tokens leicht unnötige Iterationen.
• Fast Patching: Generierung minimaler Diffs statt kompletter Umschreibung von Dateien. Senkt die Kosten, kann aber die Anzahl kleiner Änderungen erhöhen.
• Pydantic AI: Validierung der Ausgabe-Struktur, z.B. CodegenResult, ReviewDecision, PatchPolicy.
• Guardrails: Beschränkungen für Pfade, Abhängigkeiten, Secret-Muster, Architektur-Ebenen, API-Verträge.
• Reviewer: Menschliche Verifikation von Semantik, architektonischen Konsequenzen und operativer Sicherheit.
• CI/CD: Deterministische Verifikation: Tests, Build, Deploy, Canary, Rollback.
• Governance: Metriken, Budgets, SLOs, Owner-Policies, Tech Debt Accounting.

Das mentale Modell des Paradoxons:

Unit cost of draft ↓
Perceived risk of draft ↓
Retry frequency ↑
Draft volume ↑
Review queue ↑
Reviewer attention per PR ↓
Acceptance of shallow diffs ↑
Hidden coupling ↑
Future change cost ↑

Dies ist kein lineares „mehr Code“. Es ist eine Verschiebung der Aufmerksamkeitsverteilung. Wenn Drafts günstig sind, beginnen Ingenieure, Änderungen einzureichen, die sie früher nicht erstellt hätten, weil sie keine Zeit verschwenden wollten. Reviewer reagieren formal, weil sie nicht hinterherkommen. Die Architektur erodiert nicht durch einen einzigen schlechten PR, sondern durch Tausende von „wahrscheinlich akzeptablen“ Änderungen.

3. Technischer Pipeline-Lebenszyklus

Der Lebenszyklus einer KI-unterstützten Änderung umfasst vier Stadien. Jedes Stadium muss einen Vertrag, ein Budget und eine Metrik haben.

1. Formulierung / Eingangsstatus

Der Eingang ist nicht „mach mir ein Feature“, sondern ein strukturierter Vertrag:

{
  "task_id": "T-8842",
  "repo": "payments-service",
  "base_sha": "a7f3c91",
  "objective": "Add idempotency key to refund API",
  "risk_tier": "high",
  "allowed_paths": [
    "src/refund/**",
    "tests/refund/**",
    "openapi/refund.yaml"
  ],
  "forbidden_paths": [
    "src/auth/**",
    "infra/iam/**"
  ],
  "constraints": {
    "max_patch_lines": 180,
    "context_budget_tokens": 24000,
    "max_new_tokens": 4096,
    "required_tests": true,
    "require_backward_compatible_api": true,
    "no_new_external_dependencies": true
  },
  "verification_gates": [
    "unit",
    "contract",
    "security",
    "arch_lint",
    "reviewer"
  ]
}

Schlüsselfelder:

• risk_tier: Bestimmt die Tiefe der Verifikation.
• allowed_paths: Begrenzt den Blast Radius.
• max_patch_lines: Verhindert riesige AI-PRs.
• context_budget_tokens: Kontrolliert die Kosten und Qualität des Retrievals.
• verification_gates: Liste der obligatorischen Prüfungen.

2. Transformation

Der Context Builder stellt das Prompt-Bundle zusammen:

def build_context(request: CodegenRequest) -> PromptBundle:
    relevant_files = code_search(
        query=request.objective,
        repo=request.repo,
        top_k=12,
        reranker="modernbert-code-v2"
    )
    dependency_graph = load_dependency_graph(request.repo, request.base_sha)
    policy = load_policy(request.repo, request.risk_tier)

    return PromptBundle(
        task=request,
        files=relevant_files,
        graph=dependency_graph,
        policy=policy,
        token_budget=request.constraints.context_budget_tokens
    )

In diesem Stadium ist es wichtig, dem Modell nicht einfach mehr Kontext zu geben, sondern ihm einen begrenzten, strukturierten, validierten Kontext bereitzustellen. Ohne dies steigt das Risiko der Long-Context-Degradation: Das Modell sieht viele Dateien, verliert aber die Invarianten.

3. Ausführung / Inference

Das Modell generiert den Diff über den ReAct loop oder direkte Patch-Generierung:

from pydantic_ai import Agent

agent = Agent(
    model="openai:gpt-5.2",
    output_type=CodegenResult,
    system_prompt=CODEGEN_SYSTEM_PROMPT
)

result: CodegenResult = agent.run_sync(
    prompt_bundle.render(),
    tools=mcp_tools,
    guardrails=[
        patch_size_guard,
        allowed_paths_guard,
        secret_detector_guard,
        dependency_policy_guard
    ]
)

Erwartete Ausgabe:

{
  "patch_id": "P-10492",
  "task_id": "T-8842",
  "diff": "diff --git a/src/refund/api.py b/src/refund/api.py\n...",
  "changed_files": [
    "src/refund/api.py",
    "tests/refund/test_idempotency.py"
  ],
  "tokens_used": {
    "input": 18420,
    "output": 2140
  },
  "cost_usd": 0.0214,
  "p95_latency_ms": 1420,
  "confidence": 0.82,
  "guardrail_flags": [],
  "verification_plan": [
    "unit",
    "contract",
    "security"
  ]
}

Fast Patching bedeutet hier die Generierung eines minimalen Diffs, aber nicht unbedingt einer minimalen Änderung. Wenn das Modell 40 kleine PRs statt eines architektonisch kohärenten erstellt, steigt der Durchsatz, aber auch die Review-Last.

4. Feedback-Verarbeitung

Nach der Generierung beginnt die eigentliche Ingenieursarbeit:

def verify_patch(result: CodegenResult, request: CodegenRequest) -> VerificationDecision:
    structural = validate_structure(result)
    security = run_security_gates(result.diff, request)
    tests = run_required_tests(result, request)
    architecture = check_architecture_rules(result, request)
    reviewer_load = estimate_review_load(result)

    return VerificationDecision(
        patch_id=result.patch_id,
        structural_ok=structural.ok,
        security_ok=security.ok,
        tests_ok=tests.ok,
        architecture_ok=architecture.ok,
        reviewer_load_score=reviewer_load.score,
        merge_allowed=all([
            structural.ok,
            security.ok,
            tests.ok,
            architecture.ok,
            reviewer_load.score < request.risk_tier.review_threshold
        ])
    )

Das Ergebnis des Reviews sollte nicht „LGTM“ sein, sondern ein strukturiertes Signal:

{
  "patch_id": "P-10492",
  "verdict": "request_changes",
  "review_minutes": 34,
  "semantic_risk": 0.71,
  "reviewer_load_score": 0.83,
  "issues": [
    "idempotency key not validated against tenant_id",
    "contract test missing for duplicate request",
    "error response changes public API shape"
  ]
}

Das Jevons-Paradoxon wird genau in diesem Stadium kontrolliert: Wenn reviewer_load_score nicht in die SLO einbezogen wird, generiert das System mehr Änderungen, als es sicher verifizieren kann.

4. Praktische Einsatzszenarien in Produktion

01. Plattform-Team mit AI Codegen für Service-Templates

Situation: Die Plattform hat 120 Mikroservices. Das Team führt AI Codegen für die Erstellung von Service-Scaffolding, Config, Health Checks, OpenAPI-Stubs und CI-Templates ein. Die Stückkosten für ein Scaffold sinken von 4 Stunden auf 15 Minuten. Innerhalb einer Woche steigt die Anzahl der PRs um 300%.

Die primären Metriken sehen positiv aus:

median time-to-first-diff: 4h -> 12m
cost per scaffold generation: $0.03
p95 inference latency: 1.6s
PR volume: +310%

Aber nach 3 Wochen:

p95 review latency: 2d -> 6d
reviewer utilization: 55% -> 108%
defect escape rate: 0.7% -> 2.9%
churn within 14d: 8% -> 27%

Ursache: KI generiert schnell „wahrscheinlich funktionierende“ Templates, übernimmt aber keine Verantwortung für langfristige Operability. Jedes Scaffold fügt hinzu:

• neue Abhängigkeiten;
• neue Config-Keys;
• neue CI-Jobs;
• neue Alert-Regeln;
• neue Angriffsfläche für Security;
• neue Wartungsverpflichtungen.

Architektonische Lösung:

1. Einführung von risk_tier für Scaffolds: low, medium, high.
2. Begrenzung von max_patch_lines und max_files_per_pr.
3. Anforderung von contract tests und security baseline.
4. Automatisierung der Golden Paths: Nicht Code im Vakuum generieren, sondern geprüfte Template-Slots füllen.
5. Einführung von Reviewer-Quotas: Nicht mehr als N High-Risk-PRs pro Reviewer pro Tag.
6. Messung von cost per verified service statt cost per generated diff.

Inhalt der Richtlinie:

{
  "policy_id": "platform-scaffold-v3",
  "max_patch_lines": 220,
  "max_files_per_pr": 18,
  "required_tests": ["unit", "contract", "security"],
  "forbidden_paths": ["infra/iam/**", "secrets/**"],
  "reviewer_quota": {
    "high_risk_pr_per_day": 4,
    "medium_risk_pr_per_day": 8
  }
}

Ergebnis: Der Durchsatz wird nachhaltig, da das System billige Generierung nicht mehr in kostenlose Schulden umwandelt.

02. Produkt-Team mit Vibe Coding MVP

Situation: Ein Team baut schnell ein MVP. Ingenieure nutzen KI zur Generierung von UI, API, Migrations und Test-Fixtures. Nach 2 Wochen sieht das Produkt fertig aus. Nach 6 Wochen kann das Team kein Modul mehr sicher ändern.

Symptome:

• Jede Datei enthält KI-generierte Variationen derselben Logik;
• Es gibt drei Versionen desselben Auth-Helpers;
• API-Contracts sind nicht mit Frontend-Typen synchronisiert;
• Tests werden für die Implementierung generiert, nicht für die Spezifikation;
• Architekturebenen werden durch „schnelle Lösungen“ verletzt;
• Context Degradation: Ingenieure erinnern sich nicht daran, warum jeder Diff existiert.

Technische Ursache: System 1 Codegen erzeugt lokal plausiblen Code, hält aber keine globalen Invarianten. Beim Vibe Coding manifestiert sich das Jevons-Paradoxon als Explosion von „unnötigen, aber plausiblen“ Änderungen.

Architektonische Lösung:

1. Einführung von module boundary contracts.
2. Verbot von AI-Patches, die mehr als ein Modul ohne architektonisches Review ändern.
3. Nutzung von Pydantic AI zur Validierung von DTOs, API-Responses und Configs.
4. Hinzufügen von architecture lint als CI Gate.
5. Obligatorische Speicherung von intent metadata: Warum existiert der Diff, welchen Vertrag implementiert er?
6. Einführung eines wöchentlichen debt budget: Nicht mehr als 20% der Änderungen ohne Tests oder mit hohem semantischem Risiko.

Beispiel eines Modulvertrags:

class UserSessionContract(BaseModel):
    user_id: UUID
    tenant_id: UUID
    issued_at: datetime
    expires_at: datetime
    scopes: set[Literal["read:profile", "write:profile"]]

    @model_validator(mode="after")
    def validate_expiry(self):
        if self.expires_at <= self.issued_at:
            raise ValueError("expires_at must be after issued_at")
        return self

Wenn KI Session-Logik ohne Validierung über den Vertrag generiert, wird der Patch vor dem Review abgelehnt. Dies reduziert die Anzahl der „Müll“-Änderungen, ohne die Geschwindigkeit zu töten.

03. Massenhafte Migration oder Refactoring via AI Fast Patching

Situation: Ein Team migriert von einer Legacy-API zu einer neuen API in einem Monorepo. KI generiert 4.000 Patches über Nacht. Jeder Patch ist klein: Endpoint ersetzen, Client aktualisieren, Test hinzufügen. Auf den ersten Blick ein idealer Use Case.

Risiken:

• 4.000 PRs sind nicht 4.000 Änderungen; es sind 4.000 Review-Punkte.
• Kleine Patches können semantisch gefährlich sein.
• Das Modell könnte Edge Cases in 1%-Pfad vergessen.
• Dependency Version Drift könnte unbemerkt bleiben.
• Merge Order erzeugt versteckte Konflikte.
• Rollback ist komplex, da Änderungen verteilt sind.

Architektonische Lösung:

1. Nutzung von batched Fast Patching, aber mit merge budget.
2. Gruppierung der Patches nach Blast Radius: Eine logische Migration pro PR, nicht ein mechanischer Diff.
3. Hinzufügen von semantic tests, nicht nur Snapshot-Tests.
4. Nutzung von Canary Deploys pro Tenant / Feature Flag.
5. Führung eines migration ledger: Jeder Patch hat Provenance, Owner und Verifikationsnachweis.
6. Messung von regression rate per 1000 patches, rollback count, post-merge defect age.

Beispiel eines Ledger-Eintrags:

{
  "migration_id": "MIG-2026-04",
  "patch_id": "P-10492",
  "logical_change": "replace legacy refund endpoint with idempotent v2",
  "blast_radius": "payments-service/refund",
  "tests": ["unit", "contract", "e2e"],
  "canary_percent": 5,
  "rollback_target": "a7f3c91",
  "verified_by": ["ci", "reviewer-42", "security-bot"]
}

In Produktion verwandelt dieser Ansatz AI Codegen von einem Rauschgenerator in ein Werkzeug für gesteuerte Transformation.

5. Fallstricke, typische Fehler und Sicherheit

Haupt-Risiken bei der Bereitstellung

1. Review Bottleneck Migration
   Statt Zeit zu sparen, verschiebt KI die Zeit vom Schreiben des Codes ins Review. Das Team sieht schnelle Diffs, aber keine schnellen Merges.

2. AI Slop Accumulation
   Plausibler Code, der lokal nicht schlecht ist, aber globale Entropie ansammelt: Duplikate, unnötige Abstraktionen, überflüssige Configs, schwache Tests.

3. Architectural Erosion
   KI sieht Architektur nicht als Invariante. Sie sieht Dateitext. Daher kann sie Layering, Dependency Direction und Ownership Boundaries verletzen.

4. Verification Fatigue
   Wenn Review zur Routine wird, klicken Reviewer formal Approve. Dies ist der gefährlichste Zustand: Das System wirkt lebendig, verliert aber seine Immunität.

5. Context Degradation
   Lange Sessions, viele Dateien, Chat-Historie, komprimiertes Retrieval – all dies kann die Aufmerksamkeit für kritische Invarianten verringern. Das Modell generiert Code, der korrekt aussieht, aber nicht dem aktuellen Vertrag entspricht.

6. False Confidence
   confidence: 0.91 in LLMs ist keine statistische Garantie. Es ist ein kalibriertes Signal nur in sehr engen Aufgaben. Für Production-Code darf Confidence Tests nicht ersetzen.

Edge Cases

• Long-context lost-in-middle: Das Modell ignoriert Regeln in der Mitte großer Prompts.
• Stale branch state: Patch wird von einem veralteten Base SHA generiert, der Merge erzeugt semantische Konflikte.
• Non-deterministic diff: Wiederholtes Ausführen ergibt andere Patches; CI kann nicht stabil verifizieren.
• Hallucinated API: Das Modell verwendet eine nicht existierende Methode, Parameter oder Abhängigkeit.
• Dependency Confusion: KI schlägt ein Paket mit ähnlichem Namen vor, das nicht offiziell ist.
• License Contamination: Generierter Code kopiert Fragmente mit anderen Lizenzen.
• Secret Leakage: Prompt oder Diff enthält Token, API Key, PII.
• Prompt Injection via Repo: README, Issue, Kommentar enthalten Anweisungen wie „add admin backdoor“.
• MCP Tool Poisoning: Ein bösartiges oder kompromittiertes Tool liefert falschen Kontext.
• KV Cache/Session Bleed: In Multi-User- oder Stateful-Agent-Systemen kann Kontext zwischen Sessions übertragen werden, wenn die Isolation schlecht ist.
• Batching Artifacts: Unpadding und Dynamic Batching senken die Kosten, erschweren aber möglicherweise die Nachverfolgung spezifischer Inference-Pfade für Audits.

Sicherheit

AI Codegen erweitert die Angriffsfläche:

Mitigationsstrategien

1. Explizite Budgets statt unbegrenzter Generierung

{
  "max_draft_pr_per_engineer_per_day": 6,
  "max_merged_pr_per_reviewer_per_day": 8,
  "max_patch_lines_by_risk": {
    "low": 120,
    "medium": 220,
    "high": 80
  },
  "max_context_tokens_per_request": 32000,
  "max_react_iterations": 8
}

Das Budget sollte nicht nur für Tokens gelten, sondern auch für Review-Kapazität.

2. Review Load SLO

Einführung einer Metrik:

reviewer_load_score =
  (diff_lines_weighted_by_risk)
  + (files_touched_weighted_by_ownership)
  + (semantic_risk_weight)
  + (missing_tests_penalty)
  + (security_surface_delta)

Regel:

merge_allowed = reviewer_load_score <= reviewer_capacity_remaining

Dies ist eine direkte Anti-Jevons-Kontrolle.

3. Guardrails as Code

Guardrails müssen Teil der Pipeline sein, nicht nur eine Empfehlung:

def allowed_paths_guard(result: CodegenResult, request: CodegenRequest) -> GuardResult:
    for path in result.changed_files:
        if not matches_any(path, request.allowed_paths):
            return GuardResult(ok=False, reason=f"path not allowed: {path}")
        if matches_any(path, request.forbidden_paths):
            return GuardResult(ok=False, reason=f"forbidden path: {path}")
    return GuardResult(ok=True)

4. Pydantic AI für Contracts

Nutzung von Pydantic AI dort, wo die Ausgabe strukturiert sein muss:

• CodegenRequest
• CodegenResult
• ReviewDecision
• PatchPolicy
• VerificationPlan
• MigrationLedgerEntry

Dies reduziert die Wahrscheinlichkeit, dass das Modell „schönen Text“ statt eines ingenieurtechnisch validierten Artefakts zurückgibt.

5. Automatische Verifikation vor Review

Review sollte nicht die erste Verteidigungslinie sein. Vorher müssen bestehen:

• Unit Tests;
• Contract Tests;
• Integration Tests;
• Property-based Tests;
• SAST;
• SCA;
• Secret Scan;
• Architecture Lint;
• Dependency Policy;
• Performance Smoke;
• Migration Dry-run.

Menschliches Review muss das prüfen, was nicht deterministisch überprüft werden kann: Architektonische Absicht, produktive Korrektheit, operative Konsequenzen.

6. Architectural Fitness Functions

Nutzung von Prüfungen:

- dependency direction must not violate layer map
- public API changes require contract diff
- no new cross-module private imports
- no new secrets in config
- no unowned files in production paths
- no duplicate helper implementations above threshold

Solche Fitness Functions machen architectural erosion messbar.

7. Provenance und Audit Trail

Jede KI-unterstützte Änderung muss haben:

{
  "patch_id": "P-10492",
  "model": "gpt-5.2",
  "prompt_hash": "sha256:...",
  "context_hash": "sha256:...",
  "base_sha": "a7f3c91",
  "tools_used": ["mcp:github", "mcp:ci"],
  "guardrail_results": [],
  "reviewer_id": "u-42",
  "verification_evidence": ["ci-run-8821", "security-scan-991"]
}

Ohne Provenance ist es unmöglich, Regressionen oder Vorfälle zu untersuchen.

8. Rate Limiting und Circuit Breaker

Wenn die p95 Review-Latenz die SLO überschreitet, muss das System automatisch:

• Die zulässige Anzahl von Draft-PRs reduzieren;
• Den Test-Coverage-Schwellenwert erhöhen;
• High-Risk-Pfade einschränken;
• Pair Review verlangen;
• Batch-Migrationen blockieren, bis die Queue stabilisiert ist.

Dies ist das Analogon zu Backpressure in Streaming-Systemen.

9. Red Teaming AI Codegen

Regelmäßige Tests:

• Prompt Injection via README;
• Malicious MCP Tool Response;
• Halluzinierte Abhängigkeit;
• Secret im generierten Diff;
• Lizenzkontaminiertes Snippet;
• Architekturverletzender Patch;
• Modifikation von High-Risk-Auth-Pfaden.

Das Ergebnis des Red Teamings muss in die Release Policy aufgenommen werden.

10. Erfolgsmetrik ändern

Falsche Metrik:

lines generated per hour

Richtige Metriken:

verified changes per reviewer-hour
defect escape rate per 1000 AI-assisted merges
time-to-verified-merge p95
reviewer load saturation
architecture violation count
rollback rate per AI-assisted deploy
cost per production-ready change

Das Jevons-Paradoxon im AI Engineering wird besiegt, wenn das Team nicht mehr Code generiert, sondern wenn das System fähig wird, mehr Änderungen pro Einheit Aufmerksamkeit sicher zu verifizieren.