Bewerte KI-Code nicht am Diff

Viele Entwickler nutzen KI-Coding immer noch so:

Prompt → generierter Code → kurzer Review → Merge

Das fühlt sich schnell an. Manchmal ist es auch schnell.

Aber es hat ein verstecktes Problem: Du bewertest den Output, nicht das System, das diesen Output erzeugt hat.

Für kleine Änderungen funktioniert das oft. Es bricht zusammen, sobald Produktlogik, Security, Payments, Datenmodelle, Deployment oder User Flows betroffen sind — also überall dort, wo „sieht korrekt aus“ nicht dasselbe ist wie „ist korrekt“.

Der nächste Schritt im KI-gestützten Entwickeln ist deshalb nicht einfach ein besserer Prompt. Es ist ein besserer Engineering Harness um den Agenten.

Ein Harness ist die operative Schleife, die aus vager Absicht prüfbare Software macht.

Der bessere KI-Coding-Loop

die Schleife ist wichtiger als der einzelne Prompt

1. 01
   Intent
2. 02
   Contract
3. 03
   Builder
4. 04
   Unabhängiger Review
5. 05
   Failure Classification
6. 06
   Contract Update

Der entscheidende Shift:

Der KI-Agent ist nicht das Produktivitätssystem. Die Schleife um den Agenten ist das Produktivitätssystem.

Ein neues arXiv-Paper, Meta-Engineering Harnesses for AI-Native Software Production, beschreibt genau dieses Muster: Anforderungen werden zu expliziten Contracts, spezialisierte Agenten bauen und prüfen Arbeit, unabhängige Verification findet Fehler, und der Prozess verbessert sich durch strukturierte Failure Classification.

Für Entwickler ist der praktische Takeaway simpel:

Wenn KI subtile Fehler macht, ist die Lösung oft nicht „härter prompten“. Die Lösung ist, Arbeit contract-driven, reviewbar und lernfähig zu machen.

KI-Code ist leicht zu erzeugen und schwer zu vertrauen

KI-Coding-Tools erzeugen sehr plausiblen Code.

Das ist ihr Vorteil — und ihr Risiko.

Eine Implementierung kann kompilieren, bestehende Tests bestehen, im Diff sauber aussehen, lokale Konventionen treffen und trotzdem die eigentliche Produktanforderung verfehlen.

Das passiert, weil viele Fehler keine Codegenerierungsfehler sind. Es sind Contract-Fehler.

Der Agent wusste nicht, was wichtig ist. Der Reviewer wusste nicht, worauf er prüfen soll. Die Tests haben den echten Edge Case nicht abgebildet. Der Prompt hat eine Produktionsbedingung ausgelassen. Der Diff sah gut aus, weil die fehlende Logik nirgends explizit stand.

Stell dir vor, du fragst einen Agenten:

Add in-app payments to the product.

Der Agent baut vielleicht Payment Routes, Checkout UI, Webhook Handling, Datenbankfelder und Success States. Das kann beeindruckend aussehen.

Aber wenn die Anforderung nicht explizit ist, fehlen leicht Duplicate Webhook Handling, Refund-Verhalten, Tax Logic, Subscription Cancellation, Partial Payment States, Fraud Cases, Receipts oder Admin Reconciliation.

Die Implementierung kann relativ zum Prompt „korrekt“ sein und relativ zum Business falsch.

KI-Agenten brauchen nicht nur Anweisungen. Sie brauchen Contracts.

1

Contract vor Code: definiere, was wahr sein muss, bevor der Agent editiert

2

getrennte Rollen: Builder und Reviewer dürfen nicht dieselben Annahmen teilen

∞

Lernschleife: jeder Fehler sollte den nächsten Contract verbessern

Prompts bitten. Contracts begrenzen.

Ein Prompt sagt meistens, was du willst.

Ein Contract sagt, was wahr sein muss.

Schwacher Prompt:

Build a settings page where users can update their profile.

Besserer Contract:

Goal:
Users can update display name, avatar, timezone, and notification preferences.

Acceptance criteria:
- Valid profile changes can be saved.
- Invalid display names show inline errors.
- Avatar upload accepts png/jpg up to 5MB.
- Timezone defaults to the current account timezone.
- Notification preferences save independently from profile fields.
- Save button is disabled while submitting.
- Unsaved changes show a confirmation before leaving.

Must not break:
- Existing account settings routes.
- Existing notification delivery preferences.
- Current avatar rendering in the dashboard.

Evidence required:
- Unit tests for validation.
- Integration test for successful save.
- Manual browser check for unsaved changes warning.
- Screenshot or log proving avatar upload limit behavior.

Die zweite Version instruiert den Agenten nicht nur. Sie gibt dem Builder etwas zum Bauen, dem Reviewer etwas zum Prüfen, dem Tester etwas zum Beweisen und dem Menschen etwas zum Entscheiden.

Das ist der Anfang eines Engineering Harness.

Prompt vs. Contract

Prompt-only Workflow

• “Build this feature.”
• Diff anschauen und auf Intuition vertrauen.
• Bugs einzeln flicken.
• Der Agent sagt, er habe getestet.

Contract-driven Workflow

• Ziel, Non-Goals, Akzeptanzkriterien, Edge Cases und Proof Requirements.
• Implementierung gegen den ursprünglichen Contract prüfen.
• Fehler klassifizieren und den Contract verbessern, damit derselbe Fehler seltener wiederkommt.
• Der Agent liefert Command Output, Screenshots, Logs oder andere Belege.

Trenne Bauen von Prüfen

Wenn derselbe Agent Code schreibt und den Code bewertet, entsteht leicht Confirmation Bias. Das Modell verteidigt seine eigenen Annahmen. Es prüft dann oft, ob die Implementierung zu seiner Interpretation passt — nicht, ob diese Interpretation vollständig war.

Ein robusteres Muster ist einfach:

Builder Agent:
Implement this contract. Stay inside scope. Provide evidence for each acceptance criterion.

Reviewer Agent:
Review this implementation against the original contract. Do not assume it is correct.
Find missing requirements, untested behavior, regressions, and production risks.

Für größere Änderungen kannst du Reviews weiter aufteilen:

Nützliche Reviewer-Rollen

• Product Reviewer: erfüllt das wirklich Nutzer- und Business-Verhalten?
• Architecture Reviewer: passt es ins bestehende System statt eine Parallelwelt zu bauen?
• Security Reviewer: was könnte missbraucht, geleakt, umgangen oder überberechtigt werden?
• QA Reviewer: welche Edge Cases sind ungetestet oder nur Happy Path?
• Deployment Reviewer: was kann bei Migration, Rollout, Rollback oder Betrieb brechen?
• Evidence Reviewer: hat der Agent den Claim belegt oder nur behauptet?

Du brauchst nicht für jede kleine Änderung fünf Agenten. Das wäre Overkill.

Aber das Prinzip zählt:

Bauen und Verifizieren sollten nicht derselbe mentale Akt sein.

Menschliche Teams wissen das längst. Deshalb gibt es Code Review, QA, Security Review, Staging und Postmortems. KI-native Entwicklung braucht dieselbe Trennung — nur schneller und expliziter.

Failure Classification ist der eigentliche Lerneffekt

Viele Teams behandeln KI-Fehler als nervige Einzelfälle.

Der Agent hat Mist gebaut. Code fixen. Weiter.

Damit verschwendest du das wertvollste Signal.

Jeder KI-Fehler sollte eine Frage beantworten:

Was hätte diesen Fehler beim nächsten Mal verhindert?

Es gibt vier häufige Klassen.

1. Contract incompleteness

Die Implementierung ist gescheitert, weil die Anforderung fehlte.

The agent implemented checkout but did not handle duplicate webhooks.

Der flache Fix: dem Agenten sagen, er soll Duplicate Webhook Handling hinzufügen.

Der bessere Fix: den Payment Contract so ändern, dass Webhook Idempotency bei Payment-Arbeit immer explizit gefordert ist.

Das verbessert das System, nicht nur den aktuellen Diff.

2. Context failure

Der Agent ist gescheitert, weil er das bestehende Codebase-Wissen nicht hatte.

The agent created a new auth helper instead of using the existing session abstraction.

Der bessere Fix ist nicht nur, den doppelten Helper zu löschen. Der Setup-Kontext muss verbessert werden:

Authentication must use getCurrentSession().
Do not create parallel auth utilities.
Existing middleware lives in /src/server/auth.

Das Problem war nicht Modellintelligenz. Das Problem war fehlender Kontext.

3. Verification failure

Der Bug existierte, aber der Review hat ihn nicht gefunden.

The agent changed pricing behavior. Tests passed. Nobody reviewed billing edge cases.

Der bessere Fix: ein Billing-spezifisches Review Gate für alle Tasks, die Plans, Invoices, Checkout, Subscriptions oder Entitlements berühren.

4. Evidence failure

Der Agent behauptet, etwas funktioniere, beweist es aber nicht.

“Tested successfully.”

Kein Command. Kein Output. Kein Screenshot. Kein Repro-Pfad.

KI-Agenten klingen sehr gut nach „done“. Ein Harness zwingt sie, den Beleg zu zeigen.

Ein kleiner Workflow zum Klauen

Schreibe vor der nächsten KI-Coding-Aufgabe das hier:

CONTRACT

Goal:
What should change?

Non-goals:
What should not be changed?

Acceptance criteria:
What must be true when this is done?

Must not break:
What existing behavior matters?

Edge cases:
What weird or risky cases should be handled?

Evidence required:
What proof must the agent provide?

Dann nutze zwei getrennte Prompts.

BUILDER PROMPT

You are the builder.

Implement only what is described in the contract.
Do not expand scope.
If the contract is ambiguous, stop and ask.
After implementation, provide:
- summary of changes
- files changed
- tests run
- evidence for each acceptance criterion

REVIEWER PROMPT

You are the independent reviewer.

Review the implementation against the original contract.
Do not assume the implementation is correct.

Check:
- missing acceptance criteria
- untested behavior
- edge cases
- regressions
- security risks
- places where the code satisfies the prompt but not the product intent

Return:
- pass/fail
- critical issues
- non-critical issues
- missing evidence
- contract improvements

Wenn etwas fehlschlägt, patche nicht sofort den Code.

Frag zuerst:

Was this a code mistake, or did the contract allow the mistake?

Wenn der Contract den Fehler erlaubt hat, verbessere den Contract vor dem Code.

So wird dein KI-Workflow mit der Zeit besser.

KI-Coding ohne Selbstbetrug

Mach das

• ✓ Akzeptanzkriterien schreiben, bevor die Implementierung startet.
• ✓ Evidence zu “done” machen: Commands, Logs, Screenshots, Tests oder Traces.
• ✓ Einen unabhängigen Reviewer-Pass nutzen, der Contract und Diff gegeneinander prüft.
• ✓ Wiederholte Fehler in besseren Setup-Kontext, Checks oder Templates festhalten.

Vermeide das

• × Einen sauber aussehenden Diff als Korrektheitsbeweis behandeln.
• × Den Builder-Agenten seine eigene Arbeit ohne adversarial Review bewerten lassen.
• × Jeden KI-Fehler lokal flicken, ohne den Contract zu verbessern.
• × “Tested successfully” ohne tatsächliche Evidence akzeptieren.

Warum das wichtiger wird, je besser Modelle werden

Je besser Modelle werden, desto weniger interessant sind offensichtliche Syntaxfehler.

Die schweren Probleme wandern nach oben:

• War die Anforderung vollständig?
• Hat der Agent die Systemintention erhalten?
• Hat er die Business-Regel verstanden?
• Hat er Verhalten bewiesen?
• Hat er außerhalb des Scopes geändert?
• Hat der Reviewer die richtige Risikooberfläche geprüft?
• Hat der Prozess aus dem Fehler gelernt?

Deshalb ist es zu flach, KI-Coding nur am finalen Diff zu bewerten.

Der Diff sagt dir, was sich geändert hat.

Der Harness sagt dir, ob du der Änderung vertrauen kannst.

Die besten Teams haben die besten Loops

Die Zukunft von KI-Entwicklung gehört nicht dem Team mit den längsten Prompts. Sie gehört dem Team mit den besten Loops.

Der beste Loop ist:

Specify clearly.
Build independently.
Verify adversarially.
Classify failures.
Improve the contract.
Repeat.

KI-gestützte Entwicklung wird nicht zuverlässig, weil der Agent nie Fehler macht. Sie wird zuverlässig, weil jeder Fehler das System verbessert.

Der praktische Takeaway

Wenn du heute KI zum Coden nutzt, ändere eine Sache:

Schreibe vor der nächsten Aufgabe nicht zuerst einen Prompt.

Schreibe einen Contract.

Und lass die KI das Ergebnis gegen diesen Contract beweisen.

Dann fragst du nicht mehr:

Hat die KI Code erzeugt?

Sondern:

Hat dieses System verifizierte Software erzeugt?

Das ist der Unterschied zwischen KI als Autocomplete und KI als Engineering-Fähigkeit.

Quelle

• Meta-Engineering Harnesses for AI-Native Software Production, Satadru Sengupta, Tamunokorite Briggs, Ivan Myshakivskyi, arXiv:2605.25665, 2026.