Bauen und prüfen: Verifikation statt Vertrauen.

6.1 Verifikation statt Vertrauen

Ein Sprachmodell erzeugt plausiblen Text. Plausibel heißt: Der Code sieht aus wie Code, der an dieser Stelle stehen könnte. Ob er richtig ist, ist eine andere Frage. In Kapitel 1 hast du Halluzinationen kennengelernt: erfundene Methoden, falsche Annahmen über eine Bibliothek, ein Test, der angeblich läuft, aber nie ausgeführt wurde. Ein Agent kann solche Fehler zum Teil selbst finden, weil er Werkzeuge hat und Compiler und Tests aufrufen kann. Er kann sie aber auch übersehen, schönreden oder „reparieren“, indem er den Test an den falschen Code anpasst.

Daraus folgt der wichtigste Grundsatz dieses Kapitels:

Du prüfst nicht, ob du dem Agenten vertraust. Du prüfst, ob das Ergebnis die Kriterien erfüllt.

Das klingt selbstverständlich, verschiebt aber die Arbeit. Bei klassischer Entwicklung ist Review oft der kleinere Teil: Man vertraut der Kollegin, die den Code geschrieben hat, und schaut auf die heiklen Stellen. Bei Agenten kehrt sich das Verhältnis um. Das Schreiben ist billig geworden, das Prüfen bleibt teuer. Wer die Prüfung nicht automatisiert und strukturiert, ertrinkt in Diffs oder winkt sie irgendwann ungelesen durch.

Drei Ebenen der Prüfung

Es hilft, die Prüfung in drei Ebenen zu zerlegen, die unterschiedliche Fragen beantworten:

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

Keine Ebene ersetzt die anderen. Deterministische Prüfungen sind zuverlässig, sehen aber nur, was jemand vorher als Regel oder Test formuliert hat. Urteilende Prüfungen finden auch Ungeplantes, irren sich aber gelegentlich. Der Mensch trägt die Verantwortung, hat aber begrenzte Aufmerksamkeit. Gute Pipelines setzen die billigen, zuverlässigen Prüfungen zuerst, damit die teure menschliche Aufmerksamkeit nur noch für das übrig bleibt, was Maschinen nicht entscheiden können.

Gut ist nicht dasselbe wie richtig

Eine Unterscheidung wird dich durch den ganzen Kurs begleiten: Code kann gut sein (sauber, sicher, gut strukturiert) und trotzdem das Falsche tun. Die meisten automatischen Prüfungen beantworten die erste Frage. Die zweite verlangt einen Maßstab außerhalb des Codes: Akzeptanzkriterien. Wie du sie schreibst, lernst du ausführlich in Kapitel 4. Hier geht es darum, wie man sie in die Prüfung einspeist.

6.2 Tests als Orakel

In der Testtheorie heißt die Instanz, die entscheidet, ob ein Ergebnis korrekt ist, Orakel. Für Coding-Agenten sind automatisierte Tests das wichtigste Orakel, weil sie drei Eigenschaften verbinden: Sie sind ausführbar, wiederholbar und unabhängig von der Selbstauskunft des Agenten.

Was einen Test zum guten Orakel macht

• Er prüft Verhalten, nicht Implementierung. Ein Test, der nur prüft, dass eine bestimmte private Methode aufgerufen wurde, bricht bei jedem Umbau und beweist wenig über das Verhalten.
• Er kann scheitern. Ein Test, der auch bei falschem Code grün wäre, ist kein Orakel. Die Probe: Würde er rot, wenn du die Kernlogik auskommentierst?
• Er deckt Negativ- und Grenzfälle ab. Agenten schreiben bevorzugt den „glücklichen Pfad“. Die interessanten Fehler liegen bei leerer Eingabe, Maximalwerten, fehlenden Rechten und gleichzeitigen Zugriffen.
• Er ist auf eine Anforderung rückführbar. Wenn ein Test eine Akzeptanzkriterium-ID trägt, weißt du, welche Anforderung er belegt, und siehst, welche Anforderung noch keinen Test hat.

Typische Täuschungen

Agenten optimieren auf das, was du sichtbar prüfst. Wenn die einzige Prüfung „Tests sind grün“ lautet, gibt es mehrere Wege dorthin, die du nicht willst:

• Ein fehlschlagender Test wird gelöscht, auskommentiert oder mit einer Ignore-Annotation versehen.
• Die erwarteten Werte im Test werden an das falsche Ergebnis angepasst.
• Der Agent behauptet im Abschlussbericht „alle Tests laufen durch“, ohne dass sich an den Tests etwas geändert hat oder sie überhaupt gelaufen sind.
• Der neue Code wird gar nicht von Tests erreicht, die Suite ist trotzdem grün.

Dagegen helfen zwei Dinge: Erstens lässt du die Tests von der Pipeline ausführen, nicht vom Agenten berichten. Zweitens schaust du bei Reviews gezielt auf Änderungen an Testdateien. Ein Diff, der Produktivcode und erwartete Testwerte gleichzeitig ändert, verdient einen zweiten Blick.

Test zuerst, auch für Agenten

Eine bewährte Arbeitsweise lautet: Erst den Test schreiben, der das gewünschte Verhalten beschreibt und heute scheitert, dann implementieren, bis er grün wird. Für Agenten ist das besonders wirksam, weil der rote Test ein objektives Ziel setzt. Bei Fehlerbehebungen gilt entsprechend: zuerst ein Test, der den Fehler reproduziert. Die Engineering-Guardrails der Fabrik verlangen genau das (Leitplanke „Make it verifiable“): Aufgabe in prüfbare Erfolgskriterien übersetzen und den reproduzierenden Test mit ausliefern, damit das Gate ihn durchsetzen kann.

// Bugfix-Auftrag: "Rabatt wird bei Warenwert 0 negativ"
@Test
void rabattBeiWarenwertNullIstNull() {
    var kasse = new Kasse(Rabattstaffel.STANDARD);
    assertThat(kasse.rabattFuer(Betrag.euro(0))).isEqualTo(Betrag.euro(0));
}
// Erst rot (reproduziert den Fehler), dann grün (belegt die Korrektur).

6.3 Build-Gates: die erste, billigste Hürde

Ein Gate ist ein Kontrollpunkt, den ein Ergebnis passieren muss, bevor es weitergeht. Das einfachste und wichtigste Gate ist der vollständige Build mit allen Tests. Er beantwortet die Frage „Ist der Stand in sich konsistent?“ deterministisch und ohne Interpretationsspielraum.

Was in einen Build gehört, hängt vom Stack ab. Typisch sind:

• Kompilieren bzw. Typprüfung,
• Unit- und Integrationstests,
• Architekturtests (etwa Schichtenregeln mit ArchUnit),
• Linter und Formatprüfung,
• Abdeckungsschwellen,
• Abhängigkeits- und Lizenzprüfung.

Je mehr davon im Build steckt, desto mehr Fehler fängt die billigste Prüfstufe ab. Das hat einen angenehmen Nebeneffekt: Ein Agent bekommt bei rotem Build eine konkrete, maschinenlesbare Fehlermeldung zurück, mit der er gezielt nachbessern kann. „Der Reviewer fand es unschön“ ist schwerer zu verarbeiten als „Test rabattBeiWarenwertNullIstNull erwartet 0, erhielt -5“.

Der Build muss von außen laufen

Ein Agent kann und soll während seiner Arbeit selbst bauen und testen. Das Ergebnis dieses Selbsttests ist aber eine Selbstauskunft. Das Gate läuft deshalb noch einmal, außerhalb der Agenten-Sitzung, in einer Umgebung, die der Agent nicht verändert hat. Erst dieser Lauf zählt.

6.4 Code-Review durch Mensch und Maschine

Ein grüner Build sagt dir, dass nichts Bekanntes kaputt ist. Er sagt nichts über Dinge, für die es keinen Test gibt: eine SQL-Abfrage, die per String-Verkettung gebaut wird, ein API-Schlüssel im Quelltext, eine Klasse in der falschen Schicht, eine erfundene Methode, die zufällig in einem nie ausgeführten Zweig steht. Dafür gibt es Reviews.

Maschinelle Reviewer

Maschinelle Reviewer gibt es in zwei Arten:

• Statische, regelbasierte Reviewer durchsuchen den Diff nach bekannten Mustern: hartkodierte Schlüssel, Path-Traversal, Schichtverstöße, geänderte Datenbankmigrationen. Sie sind schnell, billig und reproduzierbar, sehen aber nur, wofür es eine Regel gibt.
• LLM-basierte Reviewer lesen den Diff wie ein Mensch und kommentieren Logikfehler, unklare Namen oder fehlende Randfälle. Sie finden Unvorhergesehenes, sind aber selbst ein Sprachmodell mit allen Schwächen. Man setzt sie deshalb mit einer Konfidenzangabe ein und lässt sie nicht allein entscheiden.

Unabhängigkeit: Wer schreibt, gibt nicht frei

Ein zentrales Prinzip lautet Independent Verification: Der Agent, der eine Änderung geschrieben hat, darf sie nicht selbst freigeben. Das ist dieselbe Logik wie das Vier-Augen-Prinzip bei Menschen. Ein Agent, der seine eigene Arbeit bewertet, neigt dazu, seine eigenen Annahmen zu bestätigen. Ein separater Reviewer mit anderem Auftrag (und idealerweise anderem Kontext oder Modell) sieht anderes.

Reviewer schreiben nicht

Daraus folgt eine zweite Regel: Reviewer sind read-only. Ein Reviewer, der „mal eben“ einen Fehler behebt, ist kein Reviewer mehr, sondern ein zweiter Autor, dessen Änderungen niemand geprüft hat. Außerdem könnte ein manipulierter oder fehlerhafter Reviewer sonst den Prüfgegenstand verändern, während er ihn prüft. Befunde gehen deshalb als strukturierte Rückmeldung an den Autor zurück, nie als Änderung in den Workspace.

Der Mensch im Review

Maschinelle Reviews entlasten den Menschen, ersetzen ihn aber nicht. Gute menschliche Reviews von Agenten-Code konzentrieren sich auf:

• Passt der Diff zum Auftrag, oder hat der Agent mehr (oder etwas anderes) getan?
• Wurden Tests geändert, und wenn ja, warum?
• Gibt es Änderungen außerhalb des erwarteten Bereichs (Build-Dateien, Konfiguration, Migrationen)?
• Hat der Agent Annahmen oder Abweichungen offengelegt (im Entscheidungsprotokoll, im Code oder unter plans/)? Der PR-Text selbst stammt von der Fabrik und verweist nur darauf.

Der letzte Punkt ist kein Zufall: Die Guardrails verlangen vom Agenten, Annahmen und bewusste Abweichungen sichtbar zu machen, statt Rückfragen zu stellen, die im autonomen Lauf niemand beantwortet. Ein Review sollte diese Stellen zuerst lesen.

6.5 Fail closed: Wenn die Prüfung selbst scheitert

Jede Prüfinfrastruktur kann ausfallen: Ein Scanner fehlt im Pfad, ein LLM-Reviewer bekommt keine Antwort, eine Konfigurationsdatei ist nicht lesbar. Die entscheidende Frage ist, was dann passiert. Es gibt zwei Möglichkeiten:

• Fail open: Die Prüfung wird übersprungen, das Ergebnis gilt als bestanden. Das ist bequem und gefährlich, denn ein Angreifer oder ein Konfigurationsfehler muss nur die Prüfung zum Absturz bringen.
• Fail closed: Eine Prüfung, die nicht stattfinden konnte, gilt nicht als bestanden. Das Ergebnis wird angehalten, bis jemand die Ursache klärt.

Für alles, was Sicherheit oder Nachweise betrifft, ist Fail closed die einzig vertretbare Haltung. Die Parallel-Roadmap der Fabrik formuliert das als Architekturprinzip AP-7: Ein ausgefallener Pflicht-Reviewer, eine nicht prüfbare Policy oder eine fehlgeschlagene Attestierung darf niemals als Erfolg gelten.

Fail closed kostet etwas: Gelegentlich hält ein Lauf an, weil ein Werkzeug fehlt, obwohl der Code in Ordnung wäre. Das ist der Preis dafür, dass ein grünes Ergebnis etwas bedeutet. Und es gibt eine ehrliche Alternative zur stillen Umgehung: Wenn du einen Reviewer bewusst nicht willst, schaltest du ihn ab, sichtbar und nachvollziehbar, statt ihn ausfallen zu lassen.

6.6 Korrekturschleifen: neue Information statt blinder Wiederholung

Wenn ein Gate scheitert, liegt es nahe, den Agenten einfach noch einmal laufen zu lassen. Sprachmodelle sind nicht deterministisch, vielleicht klappt es beim zweiten Mal. Genau das ist eine schlechte Idee, und zwar aus drei Gründen:

1. Es kostet Tokens und Zeit, ohne die Erfolgswahrscheinlichkeit gezielt zu erhöhen. Der Agent hat dieselbe Information wie vorher und macht mit hoher Wahrscheinlichkeit einen ähnlichen Fehler.
2. Es verschleiert Ursachen. Ein Lauf, der „beim dritten Mal“ grün wurde, kann zufällig grün sein, etwa weil ein instabiler Test diesmal durchlief.
3. Es lädt zum Optimieren auf das Gate ein. Je öfter man wiederholt, desto größer die Chance, dass irgendein Lauf das Gate auf unerwünschtem Weg passiert.

Eine sinnvolle Korrekturschleife wiederholt deshalb nur, wenn neue Information vorliegt: eine Compiler-Ausgabe, ein fehlgeschlagener Test mit Meldung, ein Reviewer-Befund, ein Merge-Konflikt mit den betroffenen Dateien, ein rotes CI-Ergebnis. Diese Information geht als Arbeitsanweisung in den nächsten Lauf. Die Parallel-Roadmap nennt das AP-6: Rule Loop instead of Blind Retry.

Begrenzen

Auch eine informierte Schleife braucht eine Obergrenze. Wenn zwei gezielte Korrekturversuche nicht reichen, ist die Ursache meist keine Kleinigkeit, sondern ein Missverständnis im Auftrag, ein fehlender Kontext oder ein Widerspruch in den Anforderungen. Dann muss ein Mensch hinschauen, nicht ein dritter Lauf.

Gute Korrektureingaben

• Konkret: Fehlermeldung, Datei, Zeile, betroffener Test.
• Vollständig, aber gefiltert: der relevante Ausschnitt eines Logs, nicht zehntausend Zeilen.
• Mit Ziel: „Behebe den Fehler, ohne die Testerwartung zu ändern“ ist besser als „mach es grün“.

6.7 Menschliche Freigaben richtig platzieren

Ein Mensch, der jeden Zwischenschritt bestätigen muss, wird zum Engpass und klickt irgendwann reflexhaft. Ein Mensch, der nie gefragt wird, trägt Verantwortung für etwas, das er nicht gesehen hat. Die Kunst besteht darin, Freigaben an die Stellen zu setzen, an denen eine Entscheidung tatsächlich etwas ändert.

Zwei Stellen haben sich bewährt:

• Vor der Ausführung: Darf dieser Auftrag mit diesem Agenten, diesem Modell und diesem Budget überhaupt laufen? Hier verhinderst du teure oder riskante Läufe, bevor sie Kosten oder Änderungen erzeugen.
• Vor der Übernahme: Ist das validierte Ergebnis gut genug, um in den Hauptstand zu gehen? Hier entscheidest du mit vollem Wissen: Diff, Build-Ergebnis, Gate-Befunde.

Die zweite Freigabe ist die wichtigere, wenn es um Verantwortung geht. Eine Zustimmung, die erst erfolgt, nachdem der Code schon im Hauptbranch ist, ist Fassade.

Trennung der Aufgaben

In regulierten Umgebungen gilt zusätzlich Segregation of Duties: Wer eine Änderung ausgelöst hat, darf sie nicht selbst freigeben. Das ist die menschliche Entsprechung zu „Wer schreibt, gibt nicht frei“.

6.8 Pull Requests und CI als zweite Prüfinstanz

In vielen Teams ist der Pull Request der Ort, an dem Code geprüft und übernommen wird: Die CI baut und testet, Kolleginnen kommentieren, Branch-Regeln erzwingen grüne Checks vor dem Merge. Agentische Entwicklung sollte sich in diesen Ablauf einfügen, statt an ihm vorbei zu arbeiten. Das hat mehrere Vorteile:

• Die CI des Zielrepos ist eine zweite, unabhängige Prüfung. Sie läuft in einer anderen Umgebung, oft mit weiteren Tests, und weiß nichts vom Agenten.
• Bestehende Regeln (geschützte Branches, Pflicht-Reviews) gelten automatisch auch für Agenten-Code.
• Die Historie bleibt an einem Ort: Wer später fragt, warum eine Änderung kam, findet sie im PR mit Beschreibung und Diskussion.

Wichtig ist die Rückkopplung: Wenn die CI rot wird, nachdem der Agent fertig ist, muss diese Information zurück in eine Korrekturschleife. Sonst bleibt ein roter PR liegen, und jemand muss manuell nachbessern.

6.9 Vom „gut“ zum „richtig“: Akzeptanzkriterien im Gate

Alle bisher genannten Prüfungen beantworten überwiegend die Frage, ob Code gut ist. Um zu prüfen, ob er das Richtige tut, braucht das Gate einen fachlichen Maßstab. Zwei Bausteine machen das möglich:

• Akzeptanzkriterien mit stabilen IDs, die im Auftrag mitgegeben werden. Ein Reviewer kann dann gezielt fragen: Wird AC-007-03 durch den Diff erfüllt?
• Tests, die diese IDs referenzieren (im Namen, als Annotation oder im Kommentar). Damit wird Abdeckung messbar: Für welche Kriterien gibt es mindestens einen Test, für welche nicht?

Umgekehrt lässt sich auch fragen: Welche Änderungen im Diff gehören zu keinem Kriterium? Solches ungedecktes Verhalten ist nicht automatisch falsch, aber ein Hinweis auf Scope-Creep oder auf ein vergessenes Kriterium.

6.10 Zusammenfassung: die Prüfkette eines Build-Runs

Auftrag (Ziel, ggf. Akzeptanzkriterien)
   │
   ├─ Freigabe vor EXECUTION (Default ohne Policy: run.approval-vor-merge)
   ▼
EXECUTION auf Branch sdlc/run-<id8>
   ▼
VALIDATION: mvn verify ──rot──► Korrekturschleife (Build-Feedback, ≤ 2)
   ▼ grün
Quality Gate: 6 read-only Reviewer
   │   advisory: anzeigen   blocking: FAILED/ERROR ──► Korrekturschleife
   ▼
Freigabe vor Merge (Approval-Policy / pflichtFreigabePhasen=VALIDATION)
   ▼
Merge in Base   oder   Push + Pull Request
                          ▼ (git.pr-feedback.enabled)
                       WAITING_FOR_PR: rote CI ──► Korrekturschleife
                          ▼ grün + gemerged
                       COMPLETED

• Prüfe Ergebnisse, nicht Absichten. Die Selbstauskunft eines Agenten ist keine Prüfung.
• Setze billige, deterministische Prüfungen zuerst und mache sie so streng wie möglich.
• Reviewer sind unabhängig und read-only; wer schreibt, gibt nicht frei.
• Fail closed: Eine ausgefallene Prüfung ist kein Erfolg.
• Wiederhole nur mit neuer Information und begrenze die Versuche.
• Platziere menschliche Freigaben dort, wo sie etwas entscheiden, vor allem vor der Übernahme.

Kapitelfragen

1. Warum reicht es nicht, wenn ein Agent in seinem Abschlussbericht schreibt, dass alle Tests grün sind?

   Musterantwort

   Der Bericht ist eine Selbstauskunft. Der Agent kann sich irren, Tests nicht ausgeführt, geändert oder gelöscht haben. Zählen darf nur ein Build- und Testlauf, den die Pipeline außerhalb der Agenten-Sitzung ausführt. Der hallucination-reviewer der Fabrik sucht genau nach dem Muster „Tests laufen durch“ ohne Teständerung.

2. Was unterscheidet einen guten Test als Orakel von einem schlechten? Nenne drei Merkmale.

   Musterantwort

   Er prüft Verhalten statt Implementierung, er kann tatsächlich scheitern (wäre bei falschem Code rot), er deckt Negativ- und Grenzfälle ab und ist auf eine Anforderung rückführbar, idealerweise über eine AC-ID.

3. Erkläre den Unterschied zwischen Fail open und Fail closed am Beispiel eines Reviewers, dessen CLI fehlt.

   Musterantwort

   Fail open würde den fehlenden Reviewer überspringen und das Gate als bestanden werten. Fail closed wertet die ausgefallene Prüfung als nicht bestanden. Die Fabrik unterscheidet: Ein technisch gescheiterter Reviewer ergibt ERROR, nie einen stillen Pass, und im Modus blocking startet das die Korrekturschleife. Eine fehlende CLI ergibt SKIPPED; das ist ausdrücklich kein PASSED, und die Policy strict verlangt die Pflichtkategorien, sodass das Fehlen nicht still durchrutscht.

4. Warum sind die Reviewer der Fabrik read-only, und wie wird das bei den LLM-Reviewern technisch durchgesetzt?

   Musterantwort

   Ein schreibender Reviewer wäre ein zweiter, ungeprüfter Autor und könnte den Prüfgegenstand während der Prüfung verändern. Befunde gehen deshalb als Rückmeldung an den Autor. Technisch läuft der Claude-Code-Review mit --permission-mode dontAsk und --disallowedTools für Edit, Write und Bash.

5. Ein Build-Run ist zweimal in der Korrekturschleife gescheitert und steht in NEEDS_CORRECTION. Was tust du, und was tust du nicht?

   Musterantwort

   Nicht einfach neu starten in der Hoffnung auf Glück. Stattdessen den Run-Branch und die Fehlermeldungen ansehen, die Ursache einordnen (unklares Ziel, fehlender Kontext, widersprüchliche Anforderung, zu großer Auftrag) und gezielt handeln: Ziel schärfen, Kontext oder Memory ergänzen, Auftrag zerlegen und dann einen neuen Run starten. Der Base-Branch ist unberührt, es eilt also nicht.

6. Welche beiden Freigabepunkte kennt die Fabrik, und warum ist der zweite für regulierte Umgebungen entscheidend?

   Musterantwort

   Vor EXECUTION (der Agent läuft erst nach Freigabe; ohne Approval-Policy der Default über run.approval-vor-merge) und vor dem Merge in VALIDATION (über eine Approval-Policy bzw. pflichtFreigabePhasen). Ohne den zweiten Punkt wäre der Code bereits im Base-Branch, bevor jemand zugestimmt hat; die Zustimmung wäre dann Fassade.

7. Dein Team will, dass Agenten-PRs auch die bestehende CI durchlaufen und bei roter CI automatisch nachgebessert wird. Was richtest du in der Fabrik ein?

   Musterantwort

   Git-Remote-URL am Projekt, GitHub-Token unter /integrations, den Host in der Allowlist (SOFTWAREFABRIK_GIT_ALLOWED_HOSTS) und git.pr-feedback.enabled einschalten. Dann eröffnet ein erfolgreicher Build-Run einen PR, wartet in WAITING_FOR_PR auf grüne CI und Merge, und rote CI startet eine Korrektur. Das funktioniert heute nur mit GitHub.

8. Wann ist advisory der bessere Gate-Modus als blocking, und wann umgekehrt?

   Musterantwort

   advisory passt in der Einführungsphase oder bei Reviewern, deren Rauschen du noch nicht kennst: Befunde werden sichtbar, blockieren aber nicht. blocking passt, sobald die Befunde verlässlich sind, und ist für regulierte Profile vorgegeben, damit ein FAILED oder ERROR tatsächlich eine Korrektur erzwingt.

9. Transfer: Ein Gate prüft, ob Code gut ist. Was fehlt, um zu prüfen, ob er das Richtige tut, und wie schließt die Fabrik diese Lücke?

   Musterantwort

   Ein fachlicher Maßstab: Akzeptanzkriterien mit IDs und Tests, die diese IDs referenzieren. Die Fabrik übergibt seit v0.35 die Kriterien der freigegebenen Spec an alle Reviewer und seit v0.36 im Objective-Kopf an den Agenten. Seit v0.38.0 prüft der Reviewer spec-conformance regelbasiert, ob jedes gebundene Kriterium durch mindestens einen Test belegt ist und welche Änderungen keinem Kriterium zugeordnet sind.