Akzeptanzkriterien, die Agents wirklich ausführen können

Die meisten Ratschläge zu Akzeptanzkriterien richten sich immer noch an Menschen. Genau da liegt der Bug.

Wenn du Arbeit an Cursor, Claude Code, Codex oder Gemini übergibst, reicht menschenlesbar nicht. Der Agent braucht Kriterien, die er ausführen kann. Das heißt: maschinell prüfbar. In der Praxis ist der nützliche Test einfach. Ein Kriterium sollte beobachtbar, atomar und begrenzt sein. Ist es das nicht, schreibst du keine Akzeptanzkriterien. Du schreibst eine Wunschliste und bittest ein Modell, zu raten.

Deshalb liegt der Gegenwind gegen Spec-driven Development nicht falsch. „Wasserfall mit Markdown“, „Produktivitätsfalle“, „Spec Drift“, „Token verbrennende Zeremonie“. Berechtigt. Wenn deine Spec lang, vage und voller unscharfer Absichten ist, verschwendet sie garantiert Zeit. Simon Willison hat deutlich auf die Fehlerbilder schlampiger KI-gestützter Workflows hingewiesen, und Birgitta Böckelers Einteilung in spec-first, spec-anchored und spec-as-source ist hier wichtig, weil nicht jeder „Spec-Workflow“ dasselbe Etikett verdient. Auch Addy Osmanis Leitfaden zum Schreiben von Specs für AI Agents trifft denselben wunden Punkt: Mehr Text repariert keine schlechten Anweisungen.

Die Lösung ist nicht „schreib größere Specs“. Sondern: Schreib Kriterien, die der Agent prüfen kann, ohne dich zu fragen, was du gemeint hast. Wenn aus einem Kriterium kein Test werden kann, improvisiert der Agent. Genau dort beginnt Drift. Wenn du diesen Schmerz schon kennst, kommt dir die Kritik in diesem Text über das Vibe-Coding-Problem wahrscheinlich bekannt vor.

Inhalt

• Der Gegenwind hat recht: Vage Specs sind eine Falle
• Warum deine aktuellen Akzeptanzkriterien bei AI Agents scheitern
  • Menschenfreundlich ist nicht ausführbar
  • Brownfield-Repos bestrafen Raterei
  • Drift beginnt in der Liste der Kriterien
• Die Anatomie eines ausführbaren Akzeptanzkriteriums
  • Fang mit Given-When-Then an
  • Beobachtbar, atomar, begrenzt
  • Wie eng du den Agent führen solltest
• Praxisbeispiele für typische Szenarien
  • Beispiel: Frontend-Komponente
  • Beispiel: Backend-API
  • Beispiel: Datenpipeline
  • Beispiel: Performance-Kriterien
• Kriterien auf verschiedene AI Agents zuschneiden
  • Was sich je nach Agent ändert
  • Anpassen, ohne alles neu zu schreiben
• Alles zusammen in deinem Workflow
  • Ein einfacher Workflow, der hält

Der Gegenwind hat recht: Vage Specs sind eine Falle

Der Gegenwind gegen Specs ist meist Gegenwind gegen vorgetäuschte Präzision.

Teams schreiben ein poliertes Feature-Briefing, setzen vier Stichpunkte unter „Akzeptanzkriterien“ und tun so, als wäre die Arbeit jetzt unter Kontrolle. Dann liest ein Agent das hier:

• Profil lässt sich aktualisieren
• Fehlerbehandlung sollte elegant sein
• Seite sollte schnell laden
• UI sollte sich modern anfühlen

Diese Liste schränkt die Implementierung nicht ein. Sie definiert keinen Erfolg. Sie lässt dem Agent Raum zum Raten, und Raten ist im Code teuer.

Ich habe das bei Greenfield-Prompts und in chaotischen Brownfield-Repos genau gleich ablaufen sehen. Das Dokument wirkt aufgeräumt. Das Ergebnis wirkt plausibel. Dann ändert der Agent die falsche Schicht, übersieht eine Geschäftsregel oder besteht den Happy Path, während er genau den Zustand kaputt macht, auf den es ankam. Dieses Muster ist ein wichtiger Grund, warum die Prompting Wall, die die SDD-Welle ausgelöst hat, überhaupt erst entstanden ist. Mehr Prosa brachte nicht mehr Kontrolle.

Das eigentliche Problem ist nicht, dass es Specs gibt. Sondern Kriterien, die für zustimmendes Nicken von Menschen geschrieben sind statt für die Ausführung durch eine Maschine.

Faustregel: Wenn zwei kompetente Leute dasselbe Kriterium lesen und unterschiedliches Verhalten ausliefern könnten, ist das Kriterium nicht bereit für einen Agent.

Dieser Maßstab ist strenger als „klar schreiben“. Er stellt eine andere Frage: Kann jemand im Review, ein Test-Runner oder der Agent selbst anhand beobachtbarer Belege über Bestanden oder Nicht bestanden entscheiden? Wenn nicht, ist das Kriterium immer noch eine Notiz und keine ausführbare Anforderung.

Bei autonomen Agents ist das noch wichtiger, weil sie auf Fertigstellung optimieren. Sag einem Menschen „mach die Fehlerbehandlung elegant“, und er stellt vielleicht Rückfragen. Gib das einem Agent, und er greift oft zu einem Muster aus dem Training, baut generische Toast-Meldungen ein und macht weiter. Der AI-Agent-Leitfaden von Zephony ist hier nützlich, weil er den Agent als System beschreibt, das explizite Betriebsgrenzen braucht, keine inspirierende Produktsprache.

Dahinter steckt eine ältere Lektion. Akzeptanzkriterien gibt es, um Grenzen zu definieren, die sich prüfen lassen. In Branchen mit viel Validierung sind Akzeptanzgrenzen an explizite Parameter und beobachtete Ergebnisse gebunden, nicht an allgemeine Absichtserklärungen (Fachartikel zu statistischen Werkzeugen für prozessbegleitende Akzeptanzkriterien). Software-Teams brauchen diese Terminologie nicht, aber sie brauchen die Disziplin. Wenn niemand sagen kann, welcher Beleg zeigt, dass das Feature bestanden hat, ist die Spec nicht fertig.

Kürzer hilft meistens.

Agents arbeiten besser mit Kriterien, die beobachtbar, atomar und begrenzt sind. Ein Verhalten. Eine Grenze. Ein klarer Weg, es zu prüfen. Lange Specs haben weiterhin ihren Platz für Kontext, Constraints und geschäftlichen Hintergrund. Akzeptanzkriterien erfüllen eine andere Aufgabe. Sie sagen dem Agent, was wahr sein muss, wenn die Arbeit erledigt ist.

Warum deine aktuellen Akzeptanzkriterien bei AI Agents scheitern

Detaillierte User Stories schützen dich nicht vor schlechtem Output. Vage Akzeptanzkriterien laden ihn ein.

Die übliche Spec geht immer noch davon aus, dass ein Mensch die Lücken füllt. Ein AI Agent tut das nicht so, wie es dein Senior Engineer tun würde. Er muss Text in Aktionen, Dateiänderungen und Prüfungen übersetzen. Wenn in den Kriterien „Profilbearbeitung unterstützen“ steht, hat der Agent zu viele gültige Deutungen. Er könnte das Schema ändern, ein Formular hinzufügen, die Validierung anpassen, API-Verträge anfassen oder alles vier. Das ist kein Versagen der Intelligenz. Das ist ein Versagen der Übergabe.

Menschenfreundlich ist nicht ausführbar

Ein Kriterium kann für ein Produktteam vernünftig klingen und für einen Agent trotzdem unbrauchbar sein. Die Lücke ist einfach: Menschen tolerieren Absichten. Agents brauchen Bedingungen für Bestanden oder Nicht bestanden.

Typische Beispiele für Kriterien, die sich im Grooming gut lesen und bei der Ausführung scheitern:

• „Das Dashboard sollte schnell laden.“ Kein Schwellenwert, kein Seitenzustand, kein Messpunkt.
• „Zeig eine hilfreiche Fehlermeldung.“ Kein Auslöser, keine Platzierung, keine Textregel, kein erwarteter Statuscode.
• „CSV-Import unterstützen.“ Kein Spaltenvertrag, kein Zeilenlimit, kein Verhalten bei fehlerhaften Zeilen.
• „Die aktuelle Architektur beibehalten.“ Keine Grenze dafür, was sich ändern darf und was unangetastet bleiben muss.

Deshalb reicht der allgemeine Rat „schreib klar“ nicht. Der entscheidende Schritt führt von menschenlesbaren zu maschinell ausführbaren Akzeptanzkriterien. Agents brauchen Kriterien mit drei Eigenschaften: beobachtbar, atomar und begrenzt. Wenn im Review niemand erkennen kann, welcher Beleg den Erfolg zeigt, kann der Agent die Aufgabe nicht zuverlässig abschließen.

Viele Ratschläge zu Agent-Tools kommen aus einer anderen Richtung zum selben Schluss. Der AI-Agent-Leitfaden von Zephony ist nützlich, weil er den Agent als System behandelt, das innerhalb expliziter Zustände und Constraints arbeitet, nicht als Teammitglied, das fehlende Regeln selbst erschließt.

Vage Kriterien scheitern meist, bevor das Testen beginnt. Sie scheitern in dem Moment, in dem der Agent raten muss.

Brownfield-Repos bestrafen Raterei

In einer bestehenden Codebase verschärft sich das Problem.

Greenfield-Demos lassen schwache Kriterien brauchbar aussehen, weil es weniger Geschichte gibt, die kaputtgehen kann. Bei Brownfield-Arbeit wird lockere Sprache teuer. Bestehende Repos haben versteckte Kopplungen, Namenskonventionen, Seiteneffekte, halbfertige Abstraktionen und Altlasten aus Migrationen. Ein Kriterium wie „Filter für die Bestellseite hinzufügen“ kann einen Agent schnell in die falsche Schicht schicken.

Typische Fehlerbilder sehen so aus:

• Gemeinsame Abfragelogik wandert in eine Seitenkomponente, weil das Kriterium nie die richtige Grenze genannt hat.
• Eine neue Abhängigkeit kommt dazu, obwohl das Repo für dieselbe Aufgabe schon ein abgestimmtes Muster hat.
• Verhalten wird dupliziert, weil das Kriterium nie auf das bestehende Modul verwiesen hat, das der Agent erweitern sollte.
• Der Happy Path besteht, während Erstattungen, Exporte oder Audit-Logs unbemerkt kaputtgehen.

Deshalb ist „sei konkret“ immer noch zu weich. Bei Brownfield-Arbeit sollten Akzeptanzkriterien auch den Schadensradius eingrenzen. Nenn die Route. Nenn die Datei oder das Modul. Nenn, was sich nicht ändern darf. Wenn die Aufgabe einen riskanten Bereich berührt, sag das direkt.

Ratgeber zu echten Codebases bringen diesen Punkt gut auf den Punkt: Akzeptanzkriterien sind in Legacy-Systemen schwieriger, weil das Risiko oft in der Architektur liegt, nicht nur in der Funktion (Mambo über Akzeptanzkriterien in echten Codebases).

Drift beginnt in der Liste der Kriterien

Teams geben nach einem schlechten Lauf oft dem Modell die Schuld. Ich gebe sie meist zuerst den Kriterien.

Wenn ein Stichpunkt „Admins dürfen Konten bearbeiten“ sagt und ein anderer „aktuelles Berechtigungsverhalten beibehalten“, muss der Agent zwei unvollständige Anweisungen ohne testbare Grenze in Einklang bringen. Er wählt die wahrscheinlichste Deutung aus Trainingsmustern und dem lokalen Code-Kontext. Manchmal klappt das. Manchmal bekommst du einen sauberen PR, der die Autorisierungslogik subtil verändert.

Der praktische Maßstab ist strenger als das, was viele Teams heute nutzen. Jedes Kriterium sollte ein Verhalten unter einer Bedingung mit einem beobachtbaren Ergebnis beschreiben. Wenn ein einzelner Stichpunkt auf drei verschiedene Arten scheitern kann, macht er zu viel. Wenn niemand auf den genauen Output, die DOM-Änderung, den Response-Code, den Log-Eintrag oder den Datei-Diff zeigen kann, der den Erfolg belegt, ist das Kriterium immer noch eine Notiz.

Behandle jedes Akzeptanzkriterium wie ein winziges Eval. Der Agent sollte es erfüllen, daran scheitern oder nach einem fehlenden Constraint fragen können. Alles Unschärfere verbrennt Tokens und erhöht die Wahrscheinlichkeit eines Builds, der technisch fertig wird, aber nie hätte ausgeliefert werden dürfen.

Die Anatomie eines ausführbaren Akzeptanzkriteriums

Menschenlesbare Akzeptanzkriterien reichen für einen Agent nicht. Die Latte liegt höher. Ein Agent braucht Kriterien, die er gegen das Repo, die Laufzeit oder den Output prüfen kann, ohne zu raten, was „fertig“ bedeutet.

Given-When-Then ist immer noch der sauberste Ausgangspunkt, weil es ein Kriterium in eine Form zwingt, die sich auf einen Test abbilden lässt. Das Muster stammt nicht ohne Grund aus BDD und Gherkin. Es macht aus vager Absicht eine Bedingung, eine Aktion und ein Ergebnis.

Fang mit Given-When-Then an

Jeder Teil hat eine bestimmte Aufgabe:

• Given definiert den Ausgangszustand
• When definiert den Auslöser
• Then definiert das beobachtbare Ergebnis

Für KI-Arbeit braucht diese Grundform meist zwei zusätzliche Anker:

• Repository-Anker. Dateipfad, Route, Tabelle, Befehl, Fixture oder Komponentenname
• Assertion-Anker. Genauer Output, Statuscode, DOM-Änderung, Job in der Queue, Log-Zeile oder Diff

Diese Anker verkleinern den Suchraum des Agents. Und sie machen Fehlschläge offensichtlich.

Eine Browser-Aufgabe ist ein gutes Beispiel. „Teste den Checkout-Flow“ lässt zu viel Interpretationsspielraum. „Durchlaufe den Gast-Checkout auf /checkout, klick auf den Gutschein-Schalter, wende SAVE10 an und bestätige, dass sich die Summe vor dem Absenden der Zahlung aktualisiert“ ist etwas, das ein Agent ausführen kann. Wenn du wiederholbare UI-Interaktionen brauchst, ist Browser Actions eine praktische Referenz, um diese Schritte explizit zu machen.

Hier ein schwaches Kriterium:

Das Passwort lässt sich auf der Login-Seite zurücksetzen.

Und hier eines, mit dem ein Agent arbeiten kann:

Given ein bestehendes Konto bei tests/fixtures/users/password-reset-user.json
When dessen E-Mail-Adresse in src/routes/login.tsx über das Formular „Passwort vergessen“ abgesendet wird
Then gibt die API 202 zurück, die UI verrät nicht, ob das Konto existiert, und ein Job mit dem Template password_reset wird für diese Adresse in die Queue gestellt

Diese Version leistet drei nützliche Dinge. Sie nennt das Fixture. Sie nennt die betroffene Oberfläche. Sie definiert Erfolg über Outputs, die der Agent prüfen kann.

Eine kurze visuelle Erklärung hilft, wenn du dieses Muster anderen im Team vorstellst.

Beobachtbar, atomar, begrenzt

Diese drei Eigenschaften zählen mehr als die Frage, ob der Satz geschliffen klingt. Fehlt einem Kriterium eine davon, fängt der Agent an zu improvisieren.

Beobachtbar

Das Ergebnis muss maschinell prüfbar sein.

Gut:

• Fehlerbanner ist sichtbar
• API gibt 404 zurück
• exportierte CSV enthält die Kopfzeile email
• Retry-Button wird nach Wiederherstellung des Netzwerks aktiv

Schlecht:

• Ablauf fühlt sich flüssig an
• Seite ist intuitiv
• Code ist sauber
• Ergebnis sieht richtig aus

„Beobachtbar“ ist die Linie zwischen einer Spec und einem Wunsch. Wenn Erfolg vom Geschmack abhängt, hat der Agent kein stabiles Ziel.

Atomar

Ein Kriterium sollte genau eine Aussage treffen.

Teams erzeugen hier oft vermeidbares Chaos. Ein einzelner Stichpunkt wie „Avatar lässt sich hochladen, zuschneiden, in der Vorschau ansehen und ohne Neuladen speichern“ kann an vier verschiedenen Stellen scheitern. Der Agent erfüllt vielleicht zwei davon, verpasst eine und liefert trotzdem einen PR, der auf den ersten Blick vollständig aussieht.

Teil es stattdessen auf:

Gut:

• ein JPG-Avatar lässt sich hochladen
• Zuschnitt bleibt bis zum Speichern erhalten
• Vorschau aktualisiert sich nach Bestätigung des Zuschnitts
• gespeicherter Avatar ist nach dem Neuladen sichtbar

Meine Regel ist einfach: Wenn jemand im Review fragen müsste „Welcher Teil ist gescheitert?“, ist das Kriterium überladen.

Begrenzt

Ein Kriterium braucht Ränder. Inputs, Scope, Umgebung und erwartete Outputs zählen alle dazu.

Ohne Grenzen füllen Agents Lücken mit gängigen Mustern aus Trainingsdaten oder benachbartem Code. So entsteht eine „vernünftige“ Implementierung, die versehentlich die falsche Route anfasst, die falsche Komponente aktualisiert oder den falschen Statuscode behandelt.

Nützliche Grenzen sind zum Beispiel:

Art der Grenze	Nützliches Beispiel
Input-Beispiel	Request-Body für /api/invoices/import
Dateiverweis	src/components/ProfileCard.tsx
Umgebungsbedingung	nicht angemeldet, Datenbank mit Seed-Daten
Erwarteter Output	gibt 422 mit Feldfehler bei email zurück
Negativfall	fehlerhafte CSV-Zeile wird übersprungen und geloggt

Wie eng du den Agent führen solltest

Der Zielkonflikt ist echt. Zu wenig Detail, und der Agent macht, was er will. Zu viel Detail, und deine Akzeptanzkriterien werden zu Implementierungsanweisungen, die bessere Lösungen blockieren.

Die praktische Linie lautet: Ergebnis plus Grenzen.

Zu eng:

• erstelle einen React-Hook namens useInvoiceFilter, ruf ihn aus InvoicePage.tsx auf, verwende useMemo und speichere den Zustand im lokalen Komponentenzustand

Besser:

• Filtern in src/pages/InvoicePage.tsx muss das aktuelle Verhalten der URL-Query-Parameter beibehalten, Status- und Datumsbereichsfilter unterstützen und die bestehenden Tests auf Routenebene grün halten

Das lässt dem Agent weiterhin Raum, die Implementierung zu wählen. Es lässt ihm keinen Raum, Verhalten kaputt zu machen, das dir wichtig ist.

Ausführbare Akzeptanzkriterien sind strenger als übliche Notizen im Backlog. Genau darum geht es. Menschenlesbare Kriterien helfen einem Team, über die Arbeit zu sprechen. Maschinell ausführbare Kriterien helfen einem Agent, die Arbeit abzuschließen, klar zu scheitern oder nach dem fehlenden Constraint zu fragen, bevor er Tokens verbrennt und das Falsche ausliefert.

Praxisbeispiele für typische Szenarien

Theorie ist billig. Entscheidend ist, ob das Kriterium den Kontakt mit dem Repo übersteht.

Beispiel: Frontend-Komponente

Du überarbeitest eine Komponente für den Profil-Avatar.

Vages Akzeptanzkriterium

„Man sollte ein Profilbild hochladen können, und es sollte auf der Profilseite gut aussehen.“

Damit soll der Agent Dateitypen, Abmessungen, Validierung, Anzeigeverhalten und Fehlerzustände selbst erschließen.

Ausführbares Akzeptanzkriterium

Given eine angemeldete Person auf /settings/profile
When sie eine PNG-Datei über src/components/settings/AvatarUpload.tsx hochlädt
Then akzeptiert der Client die Datei, zeigt vor dem Speichern eine Vorschau und speichert nach dem Speichern die Bildreferenz, sodass der Avatar nach dem Neuladen der Seite sichtbar bleibt

Ergänze separate atomare Kriterien, wenn dir Edge Cases wichtig sind:

Given dasselbe Formular
When sie eine Datei hochlädt, die kein Bild ist
Then wird das Absenden des Formulars blockiert und eine Validierungsmeldung direkt am Feld angezeigt

Viel Drift im Frontend entsteht, weil mehrere Erwartungen in einer Zeile stecken. Trenn Anzeige, Validierung, Persistenz und Fehlerverhalten.

Hier die Umwandlung als Tabelle.

Vages Kriterium (für Menschen)	Ausführbares Kriterium (für Agents)
Profilbild sollte gut aussehen	Given eine Person auf /settings/profile, when über src/components/settings/AvatarUpload.tsx ein PNG hochgeladen wird, then wird vor dem Speichern eine Vorschau angezeigt und der gespeicherte Avatar bleibt nach dem Neuladen sichtbar
Validierung sollte hilfreich sein	Given das Avatar-Formular, when eine Datei ausgewählt wird, die kein Bild ist, then wird das Absenden blockiert und eine Validierungsmeldung direkt am Feld angezeigt

Beispiel: Backend-API

Du brauchst einen neuen Endpoint, um Einladungen zu Projekten zu erstellen.

Vages Akzeptanzkriterium

„Einen Endpoint hinzufügen, um Leute zu einem Projekt einzuladen. Duplikate und Berechtigungen behandeln.“

Das sind drei Kriterien, die so tun, als wären sie eines.

Ausführbare Akzeptanzkriterien

Given ein authentifizierter Projekt-Admin
When POST /api/projects/:id/invitations eine gültige E-Mail-Payload erhält
Then gibt die API 201 zurück und legt eine ausstehende Einladung an, die mit diesem Projekt verknüpft ist

Given ein Projektmitglied ohne Admin-Berechtigung
When derselbe Endpoint aufgerufen wird
Then gibt die API 403 zurück

Given eine E-Mail-Adresse mit einer bereits ausstehenden Einladung für dasselbe Projekt
When der Endpoint erneut aufgerufen wird
Then legt die API keine zweite Einladung an und gibt den bestehenden ausstehenden Zustand zurück

Sieh dir an, was sich geändert hat. Jedes Kriterium ist bestanden oder nicht bestanden. Keine versteckten Annahmen. Kein vages „Duplikate behandeln“.

Beispiel: Datenpipeline

Hier tappen viele in die Falle, weil Datenaufgaben Edge Cases oft hinter „verarbeite einfach die Datei“ verstecken.

Angenommen, du hast ein Skript, das Video-Metadaten von Creators importiert. Wenn du konkrete Fixtures brauchst, hilft ein praktischer Leitfaden zum Scrapen von YouTube-Videos, um über Quellfelder und wiederholbare Extraktions-Inputs nachzudenken.

Vages Akzeptanzkriterium

„Das Import-Skript sollte Videodaten von Kanälen verarbeiten und fehlerhafte Zeilen überspringen.“

Immer noch zu locker.

Ausführbare Akzeptanzkriterien

Given eine CSV-Datei in data/input/channel_videos.csv mit den Kopfzeilen video_id,title,published_at
When scripts/import_channel_videos.py läuft
Then werden Zeilen mit allen Pflichtfeldern in die Zieltabelle eingefügt

Given dieselbe Datei enthält eine Zeile mit leerem video_id
When das Skript läuft
Then wird diese Zeile übersprungen und das Skript loggt den Grund dafür

Given ein doppeltes video_id existiert bereits im Speicher
When das Skript läuft
Then wird der bestehende Datensatz nicht dupliziert

Das ist der Unterschied zwischen „verarbeite die Datei“ und „liefere ein Skript aus, dem ich vertrauen kann“.

Beispiel: Performance-Kriterien

Bei Performance-Kriterien fällt vage Sprache wirklich auseinander.

Die Empfehlung von Meegle ist die praktischste Version der Regel. Für Performance gibst du Antwortzeit, Durchsatz und Last unter benannten Testbedingungen an statt qualitativer Sprache und definierst die Bestehensbedingung in einem Satz (Meegle über Akzeptanzkriterien für Performance).

Schlecht:

• die API sollte schnell sein
• die Suche sollte skalieren
• die Seite sollte Traffic-Spitzen verkraften

Besser:

• Given der Such-Endpoint im benannten Lasttest-Szenario search-standard-load, when Requests mit 50 gleichzeitigen Usern ausgeführt werden, then bleibt die p95-Latenz unter 200 ms

Das funktioniert, weil es dem Agent etwas zum Implementieren und etwas zum Prüfen gibt. Und es zieht für dich eine klare Linie zwischen Anspruch und Abnahmekriterium.

Kriterien auf verschiedene AI Agents zuschneiden

Nicht alle Coding-Agents scheitern auf dieselbe Weise. Das Format sollte stabil bleiben. Die Gewichtung ändert sich.

Wenn du mit mehreren Tools gearbeitet hast, kennst du das schon. Ein Agent kommt gut mit breitem Repo-Kontext zurecht, wird aber bei lokalen Constraints schlampig. Ein anderer folgt dem exakten Schritt, übersieht aber die Folgen für die Architektur. Wieder ein anderer ist stark in der Implementierung, aber schwächer darin, sich selbst zu prüfen.

Was sich je nach Agent ändert

Hier die praktische Aufschlüsselung.

Agent	Hilft meist bei	Braucht meist Hilfe bei
Cursor	Änderungen über mehrere Dateien, Code-Navigation in der IDE, dateibezogene Anweisungen	Expliziten Grenzen, wenn Aufgaben architektonische Fragen berühren
Claude Code	Reasoning mit großem Kontext, Planung, Lesen langer Specs	Kurzen, wiederholten Constraints nah an der Aufgabe, damit es innerhalb eines langen Plans nicht abdriftet
Codex	Klaren Implementierungsaufgaben mit direkten Akzeptanzprüfungen	Expliziteren Repository-Ankern und Beispielen
Gemini	Breiter Synthese und Planung über Docs und Code hinweg	Engeren Formulierungen für Bestanden/Nicht bestanden bei Ausführungsdetails

Das ist kein Ranking. Es ist eine Erinnerung daran, dass das Befolgen von Anweisungen nicht eine einzige Fähigkeit ist.

Wenn deine Spec auf viele Dateien, gemeinsame Abstraktionen oder ältere Module verweist, zählt Repo-Bewusstsein mehr als clevere Prompts. Genau dort wird KI-Planung, die deine Codebase kennt, zur nützlichen Ebene, weil Kriterien, die an echte Dateien, Routen und bestehende Muster gebunden sind, die Übergabe besser überstehen als generische Prompts.

Anpassen, ohne alles neu zu schreiben

Du brauchst keine eigene Methodik pro Tool. Halt die Form der Kriterien stabil und pass die Verpackung an.

Zum Beispiel:

• Bei Cursor schreibst du Dateipfade direkt ins Kriterium oder in die Aufgabennotiz daneben.
• Bei Claude Code wiederholst du strikte Constraints am Ende des Prompts, vor allem wenn die umgebende Spec lang ist.
• Bei Codex nennst du konkrete Inputs und erwartete Outputs früh.
• Bei Gemini kombinierst du die übergeordnete Absicht mit einem durchgerechneten Beispiel, damit es nicht zu breit verallgemeinert.

Wenn ein Agent dazu neigt, zu viel zu erschließen, reduzier die Mehrdeutigkeit. Wenn er dazu neigt, Kontext zu übersehen, setz Anker.

Und hier steckt eine harte Wahrheit. Bessere Agents machen ausführbare Kriterien nicht überflüssig. Sie verstecken die Kosten nur länger. Ein starkes Modell kann korrekt wirken und trotzdem einen unausgesprochenen Edge Case in einem Brownfield-Repo verletzen.

Deshalb sollten Akzeptanzkriterien, die Agents ausführen können, im Kern Tool-unabhängig bleiben:

• beobachtbares Ergebnis
• atomare Assertion
• begrenzter Input und Output

Alles andere ist Anpassung.

Alles zusammen in deinem Workflow

Teams verlieren keine Zeit, weil sie Given-When-Then ausgelassen haben. Sie verlieren Zeit, weil ihre Akzeptanzkriterien nie zu etwas wurden, das eine Maschine prüfen kann.

Sobald du Akzeptanzkriterien als ausführbare Constraints behandelst, ändert sich der Workflow. Der Agent liest keine höfliche Beschreibung von Erfolg mehr. Er arbeitet gegen eine Reihe beobachtbarer, atomarer und begrenzter Prüfungen. Wenn diese Prüfungen nach dem ersten Prompt abdriften, driftet der Build mit.

Der Kurs AI Evals for Engineers & PMs von Hamel Husain und Shreya Shankar ist aus demselben Grund nützlich. Er versteht Qualität als etwas, das du testen kannst, nicht als etwas, von dem du hoffst, dass das Modell es aus dem Kontext erschlossen hat.

Eine brauchbare Übergabe für einen Solo Builder umfasst meist sechs Teile:

• Problembeschreibung mit expliziten Scope-Grenzen
• Repository-Kontext mit den wahrscheinlich betroffenen Dateien, Modulen, Routen oder Tabellen
• Teilaufgaben, klein genug, um sie einzeln zu validieren
• Akzeptanzkriterien, so geschrieben, dass ein Agent oder ein Skript Bestanden oder Nicht bestanden prüfen kann
• Validierungsszenarien für den Happy Path, den Fehlerpfad und einen hässlichen Edge Case
• Annahmen, nach Risiko markiert, damit Vermutungen sichtbar sind, bevor sie in Produktion landen

Diese Struktur ist wichtig, weil menschenlesbare Specs trotzdem scheitern, wenn die Prüfungen unscharf sind. „Das Einloggen klappt reibungslos“ liest sich in einem Ticket gut. Ein Agent kann es nicht ausführen. „Bei gültiger E-Mail und gültigem Passwort gibt POST /api/login 200 zurück und setzt ein httpOnly-Session-Cookie“ gibt dem Modell etwas Konkretes zum Bauen und dir etwas Konkretes zum Testen.

Aus demselben Grund habe ich gelernt, das Finden der Arbeit vom Bauen zu trennen. In Tekk.coach ist die Spec die Arbeitseinheit. Seine Loops lesen, was sich in deinem Code geändert hat, und bringen dir ein Proposal; gibst du es mit Greenlight frei, wird daraus eine Spec auf deinem Board, mit Akzeptanzkriterien und einer Checkliste für die Build-Reihenfolge. Du kannst auch selbst eine schreiben, auf dasselbe Board. Dein Coding-Agent (Cursor, Claude Code, Codex) baut sie über den Tekk-MCP-Server, und der PR, in dem Closes TEK-123 steht, schließt die Spec beim Merge ab – aber nur, wenn die Checkliste erledigt ist. Tekk schreibt nie den Code und öffnet nie den PR. Diese Trennung hält die Spec stabil genug, um sie zu prüfen.

Ein einfacher Workflow, der hält

Arbeite in einem Loop, der Kriterien vom ersten Entwurf bis zur letzten Prüfung ausführbar hält.

1. Fang mit der kleinsten auslieferbaren Änderung an
   Lass breite Ziele wie „Onboarding bauen“ weg. Schreib die erste Werteinheit auf, etwa „Firmennamen in Schritt eins abfragen und leere Eingaben ablehnen“.

2. Formuliere Kriterien gegen beobachtbare Outputs
   Nenn die Route, den UI-Zustand, die Datei, den Befehl, die Payload, die Log-Zeile oder das Testergebnis, das die Fertigstellung belegt.

3. Teil jeden zusammengesetzten Satz auf
   Wenn eine Zeile Verhalten, Validierung und Performance abdeckt, zerleg sie. Agents übersehen versteckte Konjunktionen. Im Review übersieht man sie auch.

4. Häng begrenzte Beispiele an
   Gib einen gültigen und einen ungültigen Input an. Definiere für beide den erwarteten Output. Begrenzte Beispiele verhindern, dass das Modell über die Aufgabe hinaus verallgemeinert.

5. Lass einen Agent gegen eine Spec laufen
   Multi-Agent-Setups erzeugen schnell Overhead. Bring zuerst den Weg mit einem einzelnen Agent zum Laufen. Wenn du abwägst, ob sich Orchestrierung die Komplexität wert ist, ist dieser Leitfaden zu Mustern für AI Agent Orchestration ein guter Realitätscheck.

6. Akzeptier nur, was geprüft wurde
   Prüf gegen die Kriterien, nicht gegen dein Gedächtnis, deine Absicht oder einen kurzen Blick auf die UI. Wenn niemand es geprüft hat, ist es immer noch eine Vermutung.

7. Überarbeite die Spec, wenn sich die Implementierung ändert
   Lebende Specs schlagen eingefrorene Docs. Wenn sich ein Constraint ändert, aktualisier die maßgebliche Quelle vor dem nächsten Prompt.

Viel gescheiterte „spec-driven“ Arbeit ist einfach polierte Mehrdeutigkeit. Das Dokument wirkt aufgeräumt, die Prompts wirken durchdacht, und der Agent liefert trotzdem das Falsche aus, weil die Akzeptanzkriterien von Anfang an nie maschinell ausführbar waren.

Der Workflow, der überlebt, ist straffer, als die meisten erwarten. Kleiner Scope. Kriterien, die sich beobachten lassen. Assertions, die jeweils eine Sache testen. Inputs und Outputs mit harten Kanten.

---

Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich, aus dem, was sich in deinem Code geändert hat: dasselbe Board, dieselben Akzeptanzkriterien, geschlossen, sobald der PR gemergt wird.