Es beginnt unspektakulär: eine kleine HTML-Seite, ein Suchfeld, das eine Tabelle filtert. Nichts, was man nicht schon dutzendfach gebaut hätte. Dann kommen noch ein paar zusätzliche Filter dazu, klassisch per Select umgesetzt, funktional, aber nicht besonders aufregend. Also mache ich das, was ich immer mache: Ich schreibe ein Ticket, halte die Anforderungen fest, schaue mir den bestehenden Code an und notiere mir die Schritte zur Umsetzung. Nebenbei fallen mir noch ein paar Verbesserungen ein, die ich direkt mit aufnehme.

Während ich das alles zusammentrage, passiert etwas Interessantes. Ich merke, dass ich gedanklich längst nicht mehr nur dokumentiere. Ich formuliere bereits eine Lösung. Eigentlich schreibe ich keinen klassischen Ticket-Text mehr, sondern etwas, das sich verdächtig wie ein Prompt anfühlt. Eine strukturierte Beschreibung dessen, was gebaut werden soll, inklusive Kontext, Details und Erwartungen.

Also drehe ich den Spieß einfach um und kippe alles in ein Tool wie Jira nicht nur als Ticket, sondern parallel als Prompt gedacht. Zwei Minuten später steht der Code. Funktionierend, nachvollziehbar, mit allem, was ich vorher noch mühselig selbst umgesetzt hätte. Eine kleine Anpassung fällt mir noch ein, also formuliere ich auch das direkt als Prompt und dokumentiere ihn gleich im Ticket.

Am Ende bleibt eine Frage hängen: Lohnt es sich überhaupt noch, erst ein Ticket zu schreiben und anschließend daraus einen Prompt zu machen? Oder ist der Prompt längst das eigentliche Artefakt geworden?

Ein guter Prompt enthält in der Regel alles, was auch in einem sauberen Ticket stehen würde. Kontext, Ziel, Anforderungen, vielleicht sogar schon Hinweise zur Umsetzung. Der Unterschied liegt weniger im Inhalt als in der Intention. Das Ticket war früher der Startpunkt der Entwicklung. Heute fühlt es sich oft schon wie ein halber Abschluss an. Sobald die Beschreibung gut genug ist, kann die Umsetzung fast unmittelbar folgen.

Das wirft zwangsläufig die nächste Frage auf: Ist ein Ticket einfach nur ein Prompt in anderer Form, oder ersetzt der Prompt das Ticket komplett? Für größere Vorhaben mag die Trennung weiterhin sinnvoll sein, allein schon wegen Abstimmung, Planung und Dokumentation. Aber bei kleinen Aufgaben kippt das Gleichgewicht spürbar. Hier wirkt es effizienter, direkt in Prompts zu denken und zu formulieren.

Interessant wird es, wenn man diesen Gedanken weiterführt. Wenn ein Prompt die Umsetzung in Minuten liefern kann, warum dann nicht den gesamten Ablauf darauf aufbauen? Ein Ticket wird als Entwurf geschrieben, im Refinement besprochen und freigegeben. Direkt danach übernimmt ein Agent die Umsetzung, ergänzt vielleicht sogar Unit Tests, committed den Code und erstellt einen Pull Request. Während das Meeting noch läuft, kann das Team im Grunde schon mit Review und Testing beginnen.

Plötzlich verschiebt sich die Dynamik im Team. Entwicklung wird kollaborativer, ohne zusätzlichen Zeitaufwand. Mehr Augen schauen auf das Ergebnis, ohne dass mehr Stunden investiert werden müssen. Die klassische Grenze zwischen Planung und Umsetzung verschwimmt, weil beides enger zusammenrückt.

Und genau hier liegt vielleicht der spannendste Effekt: Qualität entsteht nicht mehr nur durch sorgfältige Implementierung, sondern schon durch die Qualität der Beschreibung. Wenn das, was früher ein Ticket war, heute bereits ausführbar ist, dann entscheidet die Präzision im Denken und Formulieren über einen Großteil des Ergebnisses.

Vielleicht ist die eigentliche Veränderung also gar nicht, dass Prompts Tickets ersetzen. Sondern dass Tickets anfangen, sich wie Prompts zu verhalten.