Wo wir stehen
Teil 1 hat gezeigt, dass die Frage nach der besten Programmiersprache für KI-Coding die falsche Frage ist. Entscheidend ist, wie schnell und wie präzise ein Agent Widerspruch bekommt.
Teil 2 hat diesen Widerspruch in fünf Kriterien zerlegt und ist bei einer unbequemen Grenze gelandet: Typsysteme fangen Formfehler. Bedeutungsfehler fangen sie nicht. Und Bedeutungsfehler sind genau das, was ein kompetenter, aber ahnungsloser Mitarbeiter produziert. Das ist eine treffende Beschreibung jedes heutigen Coding Agents.
Bleibt die Frage, wie man die fehlende Hälfte baut.
Vier Bausteine. Keiner davon ist neu, und das ist Absicht. Es sind die Disziplinen, die erfahrene Entwicklungsteams ohnehin praktizieren, nur so aufgeschrieben, dass eine Maschine sie lesen kann.
Baustein 1: Die Absicht vor dem Code
Ein Compiler kennt Ihre Absicht nicht. Ein Test, den der Agent nach dem Code geschrieben hat, kennt sie auch nicht, er beschreibt lediglich, was der Code ohnehin tut.
Die einzige Instanz, die etwas über die Absicht weiß, ist eine Beschreibung, die vor dem Code existiert. Nicht als Dokumentation für Menschen. Als Vertrag für den Agenten.
Der Unterschied ist praktisch, nicht philosophisch. Ein klassisches Konzeptpapier beschreibt, was gebaut werden soll. Ein Vertrag für einen Agenten beschreibt zusätzlich, was nicht gebaut werden soll, welche Entscheidungen bereits gefallen sind, und woran man am Ende erkennt, dass es stimmt. Jeder dieser Abschnitte schließt eine Tür, die der Agent sonst geöffnet hätte.
Sechs Abschnitte reichen. Warum diese Änderung, jetzt. Was genau entsteht, so beschrieben, dass ein Fremder es überprüfen könnte. Welcher Kontext bereits existiert, also Dateien, Muster, getroffene Entscheidungen. Was verboten ist und was ausdrücklich außerhalb des Auftrags liegt. Die Aufgaben, geordnet und einzeln überprüfbar. Und ein Abschlusscheck über das Ganze.
Die nützlichste Faustregel dazu ist eine Abbruchregel: Wenn Ihre Beschreibung länger wird als der Diff, den sie erzeugt, brauchen Sie keine. Dann schreiben Sie den Code direkt.
Baustein 2: Verifikationsschritte, die tatsächlich verifizieren
Hier scheitern die meisten Teams, und zwar auf eine Weise, die im Alltag kaum auffällt.
Schauen Sie sich an, wie in Ihrem Team ein Abnahmekriterium formuliert wird. Vermutlich steht dort etwas wie „Tests laufen durch" oder „die Beschreibung erscheint auf der Karte" oder, mein Favorit, „passt".
Keine dieser Aussagen ist falsifizierbar. Sie können sie nicht widerlegen, also können sie auch nichts beweisen. Ein Agent, der so ein Kriterium bekommt, wird es immer als erfüllt melden.
Ein brauchbares Kriterium sieht anders aus. Statt „Tests laufen durch" steht dort der konkrete Befehl mit der konkreten Datei. Statt „die Beschreibung erscheint auf der Karte" steht dort, welche Seite man öffnet, welches Element man ansieht und welchen genauen Zustand man erwartet, inklusive der Zeichenzahl, ab der gekürzt wird.
Es gibt eine sehr zuverlässige Warnleuchte dafür. Wenn Ihr Verifikationsschritt das Wort „kurz" oder „einfach" enthält, ist er keiner. „Kurz manuell prüfen" ist die höfliche Formulierung für „wir schauen nicht nach".
Baustein 3: Das Kontextfenster ist ein Budget, kein Tresor
Der dritte Baustein hat mit Verifikation auf den ersten Blick nichts zu tun und ist trotzdem die Voraussetzung dafür, dass die ersten beiden wirken.
Coding Agents werden über lange Sitzungen messbar schlechter. Das ist kein Bauchgefühl. Eine Untersuchung von Microsoft und Salesforce hat gemessen, dass die Leistung um durchschnittlich rund 39 Prozent einbricht, wenn Kontext schrittweise nachgefüttert wird, statt einmal vollständig vorzuliegen. Der bekannte Effekt, dass Information in der Mitte eines langen Kontexts schlechter verarbeitet wird als am Anfang und am Ende, kostet je nach Messung weitere 15 bis 30 Prozent. Und größere Kontextfenster lösen das nicht, sie verschieben nur die Kurve.
Praktisch heißt das: Eine Aufgabe, die in einer frischen Sitzung sauber gelaufen wäre, läuft in Sitzung Nummer sieben derselben Session schief, mit demselben Modell und demselben Prompt.
Die Konsequenz ist unbequem und einfach. Eine Aufgabe, eine frische Sitzung, ein überprüfbarer Stand, dann zurücksetzen. Der Reflex, den Kontext zu behalten, weil ja alles Wichtige schon drinsteht, ist genau der Fehler. Was wichtig ist, gehört in den Vertrag aus Baustein 1, nicht in den Gesprächsverlauf.
Baustein 4: Erzwingen statt bitten
Der Baustein, der über Erfolg und Misserfolg entscheidet, und der am häufigsten übersprungen wird.
Alle bisherigen Regeln lassen sich einem Agenten als Anweisung mitgeben. Das funktioniert, für eine Weile. Ein Entwickler, der ein Jahr lang systematisch mit einem Coding Agent gearbeitet und darüber Buch geführt hat, beschreibt den Verlauf so: Der Agent hält sich anfangs an die Vorgaben, und irgendwann fängt er an, sie zu vergessen, zu ignorieren und einfach sein eigenes Ding zu machen.
Das ist kein Fehlverhalten. Es ist derselbe Effekt aus Baustein 3, angewendet auf Ihre eigenen Regeln.
Daraus folgt: Eine Regel, die nur im Prompt steht, ist eine Bitte. Eine Regel, die in einem Hook oder in der Pipeline steht, ist eine Grenze. Der Unterschied zeigt sich genau dann, wenn es darauf ankommt, nämlich in Stunde drei.
Was in die Grenze gehört, ist kurz: die Prüfbefehle, die vor jedem Commit laufen. Die Formatierung. Die Dinge, die der Agent niemals anfassen darf. Alles andere darf eine Bitte bleiben.
Der Rahmen dahinter
Andrej Karpathy hat für die Arbeit mit Coding Agents eine Einteilung in drei Schichten vorgeschlagen, die diese vier Bausteine ordnet.
Schicht eins ist die Spezifikation. Sie geben dem Modell den Kontext, für den es aus sich heraus kein Signal hat. Baustein 1.
Schicht zwei ist der Verifizierer, und Karpathy nennt sie den einzigen Hebel, der wirklich funktioniert. Prüfen statt überreden. Baustein 2.
Schicht drei ist die Umgebung, also das Repository als Werkstatt, in der sich Standards und Regeln über die Zeit ansammeln, statt bei jedem Projekt neu erklärt zu werden. Baustein 3 und 4.
Der Satz, den ich aus dieser Systematik am häufigsten zitiere, stammt ebenfalls von Karpathy und trifft den Kern:
„Du kannst dein Denken auslagern. Dein Verständnis kannst du nicht auslagern."
Der Test, der alles zusammenfasst
Wenn Sie sich nur eine Regel aus dieser Serie mitnehmen, dann diese. Sie ist die goldene Regel, die sich durch meinen gesamten Kurs zieht, und sie ersetzt die „Tests sind grün, also fertig"-Haltung durch einen deutlich härteren Maßstab:
Wenn Sie es in einem Postmortem nicht erklären können, hätten Sie es nicht ausliefern dürfen.
Stellen Sie sich vor, das Feature fällt in vier Wochen in der Produktion aus, und Sie sitzen in der Runde, in der erklärt werden muss, warum. Können Sie erklären, was der Code tut und warum er so gebaut ist? Falls nicht, hilft es Ihnen nicht, dass die Tests grün waren.
Genau das ist der Unterschied zwischen einem Team, das mit Coding Agents schneller wird, und einem Team, das drei euphorische Monate erlebt und danach sechs Monate Archäologie betreibt.
Und wann Sie das alles nicht brauchen
Eine ehrliche Einschränkung zum Schluss, weil jede Methode auch eine Grenze hat.
Für einen Bugfix brauchen Sie keinen Vertrag, Sie brauchen einen fehlschlagenden Test, der vor dem Fix eingecheckt wird. Für eine zweizeilige Änderung brauchen Sie gar nichts, außer einem direkten Auftrag. Für eine Erkundung, aus der ohnehin nichts eingecheckt wird, wäre der ganze Apparat reine Zeremonie.
Der Aufwand rechnet sich ab dem Punkt, an dem mehrere Menschen denselben Code verantworten und niemand mehr alles gelesen hat. Genau dort entsteht sonst die Sorte technischer Schuld, die in keinem Ticket steht: Code, der funktioniert, den aber niemand mehr erklären kann.
Zusammengefasst über alle drei Teile: Die Sprache bestimmt, wie gut Ihr Agent bei Formfehlern widersprochen bekommt. Über Bedeutungsfehler entscheidet, was Sie selbst aufgebaut haben. Ein Agent ohne Verifikation wird schnell falsch. Ein Agent mit Verifikation wird schnell.
Diese vier Bausteine sind der Kern von Spec-Driven Development. Den vollständigen Workflow mit sechs Modulen, Übungen und Vorlagen gibt es als Online-Kurs zum Selbstlernen. Für Teams, die das an einem Arbeitstag gemeinsam am eigenen Code einführen wollen, halte ich einen Workshop für drei bis sechs Personen. Beides finden Sie hier, einen Überblick über alles Weitere bei meinen Angeboten.