Tickets wurden für Menschen geschrieben, die wussten, was Sie meinten
Warum die User Story bricht, wenn ein Agent sie liest, und was ein Ticket stattdessen sagen muss.
15. Oktober 2026 · Das Team von NEWWORK Projects
„Als Nutzer möchte ich meine Zeiterfassung exportieren, damit ich sie in Excel verwenden kann.“
Für ein Team aus Menschen ist das ein gutes Ticket. Die Entwicklerin, die es übernimmt, weiß, welche Zeiterfassung gemeint ist, hat eine Meinung zu CSV oder XLSX und fragt im Stand-up, ob Manager die Stunden ihres Teams exportieren sollen. Die Story war nie die ganze Spezifikation. Sie war eine Erinnerung an ein Gespräch, das ohnehin stattfinden würde.
Geben Sie dasselbe Ticket einem Coding-Agenten, und das Gespräch findet nicht statt. Der Agent liest, was dasteht, und das Ticket sagt sehr wenig. Also füllt er die Lücken mit den plausibelsten Antworten: jeder Bericht, als XLSX, für alle. Er schreibt Tests für seine eigenen Vermutungen und öffnet einen sauberen Pull Request. Nichts daran sieht falsch aus, bis die Buchhaltung die Datei öffnet.
Der Fehler ist nicht der Code
Agenten schreiben guten Code. Schlecht sind sie darin, zu wissen, was Sie gemeint haben, als Sie es nicht gesagt haben. Ein Mensch bemerkt eine Lücke und fragt; ein Agent bemerkt eine Lücke und entscheidet. Je fähiger der Agent, desto überzeugender die Entscheidung.
Das ändert, wofür ein Ticket da ist. Es ist keine Erinnerung mehr für jemanden, der Ihren Kontext teilt. Es ist der Kontext.
Was ein Ticket jetzt sagen muss
Ein Ticket, nach dem ein Agent bauen kann, sagt vier Dinge, die eine Erinnerung für eine Kollegin weglassen darf:
- Einen Intent. Wer das will, und warum. Wenn das Ticket eine Entscheidung nicht abdeckt, entscheidet der Intent.
- Context. Das Repository, die Datei, die Ansicht, was es schon gibt. „Kontext ist ein Link, keine Erinnerung.“
- Acceptance checks. Beobachtbare Aussagen, nicht „soll schnell sein“. Jeder wird später mit dem Nachweis abgehakt, der ihn belegt.
- Keine offenen Fragen. Jede Unbekannte ist entweder beantwortet oder als Frage aufgeschrieben, und das Ticket wird nicht übergeben, solange eine offen ist.
Wir haben das als Brief-Standard aufgeschrieben, ein offenes Markdown-Format, das jeder nutzen kann, und NEWWORK Projects darum herum gebaut.
Fragen statt raten
Der wichtigste Teil ist der vierte. KI kann aus drei Wörtern Notizen einen überzeugenden Brief schreiben, und genau das ist das Problem: Ein überzeugender Brief voller erfundener Zahlen ist schlimmer als ein vager, weil ihn niemand hinterfragt.
Wenn Write with AI etwas ergänzt, das Ihre Notizen nicht sagen, führt es das deshalb als Annahme auf, die Sie behalten oder streichen. Wenn es etwas nicht wissen kann (einen Namen, eine Grenze, die genaue Beschriftung eines Knopfes), fragt es. Das Ticket zeigt seine Readiness, und es ist nicht Ready for agent, bis jemand antwortet.
Wir raten nicht. Wir fragen. Wie sich zeigt, ist das das ganze Produkt.
Probieren Sie es mit einem Ihrer Tickets
Fügen Sie ein echtes Ticket in den Brief Checker ein. Der Score wird in Ihrem Browser nach denselben Regeln wie in der App berechnet, und die Überarbeitung zeigt den Brief, der es hätte sein können, mit den Fragen, die sie Ihnen gestellt hätte.