So geben Sie Ihrem KI-Coding-Agenten eine klare „Definition of Done"

Wenn ein menschlicher Kollege ein vages Ticket aufgreift, füllt er die Lücken mit Urteilsvermögen und stellt Fragen. Ein KI-Coding-Agent tut weder das eine noch das andere. Er liest Ihre Anfrage, schreibt den Code, führt die Prüfungen aus, die er kann, und erklärt das Feature für fertig – oft ohne eine einzige klärende Rückfrage. Wie es ein Leitfaden formuliert: Wenn Sie einem Agenten unscharfe Anforderungen übergeben, „wird der Spielraum nicht aufgefangen – er wird mitgebaut."

Damit wird Ihre Definition of Done zum wirkungsvollsten Text, den Sie schreiben können. Dieser Leitfaden zeigt, wie Sie eine formulieren, mit der ein Agent tatsächlich etwas anfangen kann.

Akzeptanzkriterien vs. Definition of Done

Zwei verwandte Konzepte, die man auseinanderhalten sollte:

• Akzeptanzkriterien sind feature-spezifisch: was genau dieses konkrete Stück Arbeit leisten muss, um als korrekt zu gelten.
• Definition of Done ist projektweit: die Qualitätsschwellen, die jede Änderung bestehen muss, bevor sie ausgeliefert wird – Tests, Review, Doku, keine committeten Secrets.

Stellen Sie sich Akzeptanzkriterien als „Haben wir das Richtige gebaut" vor und die Definition of Done als „Haben wir es nach unserem Standard gebaut". Ihr Agent braucht beides. (Atlassian bietet eine gute Einführung in die Unterscheidung.)

Machen Sie es überprüfbar, nicht wunschgetrieben

Der Test für ein gutes Kriterium: Könnte ein Skript – oder der Agent selbst – prüfen, ob es zutrifft? „Das Login-Formular sollte sich schnell anfühlen" ist nicht überprüfbar. Formulieren Sie es zu etwas mit Kante um:

• Das Absenden gültiger Anmeldedaten leitet innerhalb von 500 ms auf /dashboard weiter
• Das Absenden eines falschen Passworts zeigt einen Inline-Fehler und navigiert nicht weg
• Das Absenden eines leeren Felds wird clientseitig blockiert, bevor irgendeine Netzwerkanfrage erfolgt
• Fehlgeschlagene Logins sind auf 5 Versuche pro Minute und IP begrenzt

Jede Zeile ist etwas, worauf der Agent hinarbeiten und was er bestätigen kann. Addy Osmanis Rat zum Schreiben einer guten Spezifikation für KI-Agenten lautet, sich auf das Was und Warum zu konzentrieren, nicht auf das zeilenweise Wie – beschreiben Sie die Absicht und die Rahmenbedingungen und überlassen Sie dem Agenten die Wahl der Umsetzung.

Ein konkretes Beispiel

Vergleichen Sie diese beiden Prompts für dieselbe Aufgabe.

Vage:

Füge eine Möglichkeit hinzu, mit der Nutzer ihr Passwort zurücksetzen können.

Mit einer Definition of Done:

Füge einen Passwort-Reset-Flow hinzu. Fertig bedeutet:

• Ein Endpunkt POST /auth/reset-request nimmt eine E-Mail-Adresse entgegen und gibt immer 200 zurück (nie preisgeben, ob die E-Mail-Adresse existiert)
• Ein signiertes, einmalig nutzbares Token mit 1 Stunde Gültigkeit wird über den bestehenden Mailer in src/lib/mail.ts per E-Mail versendet
• POST /auth/reset-confirm validiert das Token, erzwingt die aktuelle Passwort-Richtlinie und macht das Token nach Verwendung ungültig
• Tests decken ab: gültiger Reset, abgelaufenes Token, wiederverwendetes Token, unbekannte E-Mail
• Keine neuen Abhängigkeiten, ohne sie vorher zu kennzeichnen

Die zweite Version ist nicht länger, weil sie bürokratisch wäre – sie ist länger, weil jede Mehrdeutigkeit, die der Agent sonst erraten würde, nun entschieden ist. Die sicherheitsrelevanten Entscheidungen (Kontoexistenz nicht preisgeben, Token ablaufen lassen, einmalige Verwendung) sind genau jene, bei denen Sie am wenigsten wollen, dass ein Agent improvisiert.

Verdrahten Sie „fertig" mit der Schleife des Agenten

Die eigentliche Stärke einer überprüfbaren Definition of Done liegt darin, dass sie die Rückkopplungsschleife des Agenten schließt. Ein agentischer Zyklus aus Code → Test → Fix → Wiederholen konvergiert nur, wenn es ein klares Ziel gibt, das getroffen werden soll. Wenn Ihre Kriterien auf tatsächliche Tests abbilden, kann der Agent sie ausführen, Fehlschläge sehen und seine eigene Arbeit korrigieren, bevor er sie an Sie zurückgibt.

Beschreiben Sie „fertig" also nicht nur – geben Sie dem Agenten eine Möglichkeit, es zu überprüfen:

• Verweisen Sie ihn auf den Test-Befehl (npm test, pytest) und sagen Sie ihm, dass das Feature erst fertig ist, wenn diese durchlaufen.
• Für Dinge, die sich im Code schwer prüfen lassen – Lesbarkeit, Einhaltung eines bestehenden Musters –, nutzen Sie einen LLM-as-a-Judge-Durchlauf: einen zweiten Prompt, der die Ausgabe an Ihrem Qualitätsmaßstab überprüft. Anthropic und andere haben festgestellt, dass dies bei subjektiven Prüfungen wirksam ist.
• Behalten Sie Sicherheit und „kein Platzhalter-/Mock-Code" in Ihrer projektweiten Definition of Done, damit sie für jede Änderung gilt, nicht nur für die, an die Sie zufällig denken.

Legen Sie sie dorthin, wo der Agent sie sehen wird

Schreiben Sie Ihre projektweite Definition of Done einmalig, in eine Datei, die der Agent automatisch liest – eine AGENTS.md oder CLAUDE.md im Wurzelverzeichnis des Repos. Feature-spezifische Akzeptanzkriterien gehören in den Task-Prompt selbst. So ist „unser Standard" stets im Kontext, und Sie buchstabieren nur das aus, was an der heutigen Arbeit einzigartig ist.

Die Verschiebung ist subtil, aber sie ist das ganze Spiel: Mit einem leistungsfähigen Agenten hören Ihre Akzeptanzkriterien auf, eine Notiz an einen Kollegen zu sein, und werden zur Spezifikation, gegen die der Code gebaut wird. Schreiben Sie sie entsprechend.