Eine gute Story ist keine lange

Wenn ein Agent mit etwas zurückkommt, das am Ziel vorbeigeht, ist die naheliegende Reaktion, beim nächsten Mal mehr zu schreiben: mehr Details, mehr Hintergrund, mehr Prosa. Aber Länge ist ein schlechter Indikator für Qualität. Eine Spec, die es mit einem RFC aufnimmt, macht einen Agenten nicht schärfer — ab einem gewissen Punkt arbeitet schiere Größe gegen ihn, weil „Context-Window-Limits und das 'Attention Budget' des Modells im Weg stehen". Der bessere Ansatz ist, große Aufgaben in kleinere zu zerlegen, statt alles in einen einzigen riesigen Prompt zu packen. [1]

Das Ziel war nie ein längeres Ticket. Es geht darum, die Mehrdeutigkeit zu entfernen, die sonst als schlechter Code und unruhige Prüfung auftaucht — wie es ein Anbieter von Agenten-Tools formuliert. [2] Eine Story wird an einer Sache gemessen: Kommt der Agent mit dem zurück, was du gemeint hast? Alles andere ist Dekoration.

Der Grund, warum das heute mehr zählt, ist, dass sich der Leser geändert hat. Eine User Story war immer ein Gesprächsanlass — ein Entwickler liest sie, geht zur Person, die sie geschrieben hat, stellt sechs Fragen und füllt den Rest mit dem, was er über die Codebase und das Team weiß. [3] Ein Agent kann zu niemandem hingehen. Er liest, was auf der Seite steht, füllt jede Lücke mit seiner besten Vermutung und baut genau das, was er geraten hat. [3]

Und wenn die Story Raum für Interpretation lässt, wird der Agent interpretieren — die Schuld liegt selten beim Modell, sondern beim Vertrag, den er bekommen hat. [4] Das Modell ist selten die Variable, die du kontrollierst. Die Story ist es. [5]

Die stärkste Story für einen Agenten beginnt nicht mit einer To-do-Liste, sondern mit einem klaren Auftrag. Nenne das Ziel und ein paar Kernanforderungen auf hoher Ebene und lass den Agenten die Details von dort aus ausarbeiten — Modelle sind gut darin, eine solide Vorgabe auszugestalten, aber sie brauchen einen klaren Auftrag, um nicht abzudriften. [1] Deine Aufgabe in der Story ist es, die Vision zu übermitteln; der Rest ist Sache des Agenten.

Deshalb hat sich das klassische User-Story-Format gehalten: Es packt drei Teile der Absicht in einen Satz — „Als [Art von Nutzer] möchte ich [ein Ziel], damit [ein Grund]." Der dritte Teil, der, den alle überspringen, ist der Visionsträger:

„Ohne ihn optimiert der Agent auf die wörtliche Funktionsanfrage. Mit ihm kann der Agent über Randfälle nachdenken." [6]

Sieh dir an, was ohne ihn passiert. „Login-Bug beheben“ ist eine vollständige Anweisung für einen Menschen, der im Raum war, als der Bug gemeldet wurde. Für einen Agenten ist es ein Vorschlag — er könnte mit einem 400-Zeilen-Pull-Request zurückkommen, der den Passwort-Reset-Flow, die Session-Middleware und ein Feature Flag berührt, obwohl der eigentliche Fix ein Tippfehler in einer Fehlermeldung war. [4] Die Vision in dieser Story — wer ausgesperrt ist, was stattdessen passieren soll, warum es wichtig ist — hätte beim ersten Versuch die richtige Umsetzung ausgewählt.

Ein menschlicher Leser füllt Lücken mit Urteilsvermögen, Erinnerung und einer günstigen Slack-Nachricht. Ein Agent füllt sie mit seinen Standardannahmen — und er wählt bereitwillig drei Versuche, wenn du fünf gemeint hast, oder sperrt Konten auf eine Weise, die es jedem erlaubt, alle deine Kunden auszusperren. [3] Das Handwerk besteht darin, die Entscheidungen zu benennen, bei denen ein falscher Standardwert dich etwas kosten würde. Ein einfacher Test für jede offene Entscheidung: „Würde es mich stören, wenn der Agent rät?" Wenn ja, gehört es in die Story. [7]

Was außerhalb des Scopes liegt, zählt genauso viel wie der Scope. Eine kurze „Nicht anfassen“-Liste — Verhaltensweisen, Dateien und Grenzen, die der Agent unberührt lassen muss — ist oft der nützlichste einzelne Satz der ganzen Story, denn ohne ihn behandelt der Agent hilfreiches Aufräumen als Erlaubnis. [8] Explizite Nicht-Ziele hindern ihn daran, Dinge zu reparieren, um die niemand gebeten hat. [9] Oder, in den Worten eines Entwicklers: „Fünf Zeilen im Ticket verhindern zwei Stunden Review." [4]

Eine Story, die das gut vermittelt, liest sich wie ein kleiner Vertrag: das Problem, das erwartete Ergebnis, die Abnahmekriterien, die Einschränkungen und was tabu ist. Nicht weil eine Vorlage magisch ist — sondern weil jedes Feld eine Lücke ist, die sonst durch eine Vermutung gefüllt würde.

Die wirkungsvollste Gewohnheit ist, zuerst die Abnahmekriterien zu schreiben und sie den Rest der Story in den Fokus ziehen zu lassen. [7] Abnahmekriterien sind beobachtbares Verhalten — was nach der Änderung wahr sein muss — nicht eine Umformulierung der Anfrage. „Das Formular wird abgeschickt“ ist ein Wunsch; „Das Absenden mit einem abgelaufenen Token zeigt den Sitzung-abgelaufen-Bildschirm und löscht die entworfene Nachricht nicht" ist eine Prüfung.

Die besten Prüfungen sind solche, die der Agent selbst ausführen kann: der Befehl zum Ausführen, der Test, der bestehen soll, die abzudeckenden Fehlerfälle. Einmal geschrieben, liefern sie „Abnahmekriterien, die 'fertig' sowohl für den Agenten als auch für die Person definieren" — „eine einzige Quelle der Wahrheit, aus der der Agent baut und gegen die der Reviewer prüft". [10]

Definiere auch die Übergabe. Bitte den Agenten in jeder Story, in seinem Pull Request „geänderte Dateien, ausgeführte Prüfungen, aufgetretene Fehler und verbleibendes Risiko zusammenzufassen". [9] Es kostet eine Zeile in der Story und macht jede Prüfung schneller.

Noch ein Trick, der die Vision ehrlich hält: Lass den Agenten deine Absicht in einen ersten Spec-Entwurf übersetzen und korrigiere dann den Entwurf. Wenn die Umformulierung der Story durch den Agenten nicht dem entspricht, was du gemeint hast, liegt die Lücke in deiner Story — und es ist deutlich günstiger, sie vor dem Pull Request zu finden. [1]

Agenten brauchen keine Prosa, die deine Architektur beschreibt — sie können den Code lesen. Was sie nicht ableiten können, ist, welche Teile davon diese Story betrifft. Zeige statt zu beschreiben: verweise auf die zu ändernden Dateien, die bestehenden Muster, die gespiegelt werden sollen, die Konventionen, die einzuhalten sind. [7] Ein fünfzeiliges Beispiel in der Story lehrt den Agenten mehr als ein Absatz, der die Regel erklärt.

Und halte die Arbeit auf die Größe einer Story zugeschnitten — etwas, das an einem einzigen Nachmittag gebaut und verifiziert werden kann — und teile alles Größere auf Story-Ebene auf, vor dem Versand, nicht mitten im Lauf. [7] Kleinere, schärfere Stories sind auch das, was es handhabbar macht, mehrere Agenten parallel laufen zu lassen — siehe unseren Guide zu parallelen Coding-Agenten.

Hier ist dasselbe Linear-Issue, zweimal geschrieben.

Diese letzte Prüfung ist der „Würde es mich stören, wenn der Agent rät?"-Test in Aktion: unausgesprochen könnte ein vernünftiger Agent leicht die Sperrmeldung nur für echte Konten anzeigen — und so verraten, welche E-Mails registriert sind.

Alles in diesem Guide — der Auftrag, die Nicht-Ziele, die Abnahmekriterien, die Dateien, die man sich ansehen sollte — entwirft Aerunits Story-Writer für dich. Du beschreibst die Arbeit; Aerunit liest deine Repositories und schlägt Linear-Issues mit Scope, Abnahmekriterien und Nicht-Zielen vor, die auf den relevanten Code verweisen. Du bearbeitest, genehmigst, und die Story ist bereit für einen Agenten.

Aerunit liest jedes Repository, das eine Story betrifft, bevor sie geschrieben wird, sodass repo-übergreifende Arbeit einen kohärenten Plan erhält: eine übergeordnete Story plus ein Sub-Issue pro betroffenem Repo. Und die Konventionen und wiederverwendbaren Anweisungen deines Teams werden einmal als gemeinsamer Kontext und Skills gespeichert und dann in jede Story und jeden Agentenlauf eingespeist — sodass du „das bestehende Muster spiegeln" nicht in jedem Ticket wiederholen musst und Agenten deine Muster nicht neu erfinden.