Vom vagen Ticket zum präzisen Prompt

Das Ticket heißt „Bewertungssystem implementieren“ und steht seit drei Tagen im Sprint. Ein Entwickler liest es und denkt sofort mit: Sterne-Rating, REST-Endpoint, Durchschnittsberechnung, wahrscheinlich eine neue Entity mit Beziehung zum Product. Er weiß, dass das Team FluentValidation nutzt, dass Reviews moderiert werden müssen und dass der letzte Kollege für ein ähnliches Feature den CreateOrder-Handler als Vorlage genommen hat. All das steht nicht im Ticket. Es steckt im Kopf.

Gibt man dasselbe Ticket wörtlich an einen Coding-Agenten weiter, passiert etwas Lehrreiches. Der Agent liefert Code. Technisch korrekt, kompilierbar, mit Unit-Tests. Aber die Entity heißt Rating statt Review, es gibt keinen Moderationsstatus, die Validierung steckt im Endpoint statt in einem FluentValidation-Validator, und der Agent hat einen eigenen Service-Layer erfunden, der nichts mit dem bestehenden CQRS-Pattern zu tun hat. Der Code funktioniert. Er passt nur nicht ins Projekt.

Diese Lücke zwischen Absicht und Ergebnis ist kein Fehler des Agenten. Sie ist ein Kommunikationsproblem. Der vorangegangene erste Teil dieser Serie zu „Projektanforderungen an Entwickler in Zeiten von KI“ hat gezeigt, wie eine CLAUDE.md dem Agenten Architekturwissen gibt. Dieser Beitrag zeigt, wie man einzelne Aufgaben so formuliert, dass der Agent nicht raten muss. Fünf Prompt-Patterns für fünf typische Entwickleraufgaben, jedes mit einem Gegenbeispiel, das zeigt, wie wenig ein vager Prompt bringt.

Pattern 1: Feature implementieren

Das häufigste Szenario: Ein neues Feature soll entstehen. Der typische Fehler ist, das Ticket eins zu eins weiterzugeben. Was ein Mensch implizit versteht, muss für den Agenten explizit werden. Der schlechte Prompt sieht so aus:

// Bad Prompt
Implementiere ein Bewertungssystem für Produkte.

Sechs Wörter, null Kontext. Der Agent entscheidet selbst über Entity-Namen, Architektur, Validierung und Teststruktur. Das Ergebnis ist technisch korrekt und architektonisch falsch. Der gute Prompt liefert drei Dinge: Kontext, Pattern-Referenz und Constraints.

// Good Prompt
Implementiere ein Review-Feature für Products. Orientiere dich an der Struktur von src/Features/Orders/ CreateOrder/ (Command, Handler, Validator). 
Die Entity "Review" hat: ProductId (FK), Rating (1-5), Comment (max 2000 Zeichen), Status (Pending/Approved/Rejected). 
Nutze IUnitOfWork, Result<T> und FluentValidation. Erstelle einen Integration-Test mit WebApplicationFactory analog zu tests/Integration/Orders/.

Der Prompt ist länger, aber jede Zeile eliminiert eine Entscheidung, die der Agent sonst falsch treffen würde. Die Referenz auf CreateOrder gibt dem Agenten ein konkretes Vorbild zum Lesen. Die Constraints definieren das Datenmodell. Die Testanweisung verhindert, dass Tests fehlen oder im falschen Format entstehen. Der Aufwand für diesen Prompt liegt bei drei Minuten. Die Ersparnis gegenüber dem Review und der Nacharbeit eines vagen Prompts bei 30 bis 60 Minuten.

Pattern 2: Refactoring beauftragen

Refactoring ist die Aufgabe, bei der Agenten am meisten Schaden anrichten können. Ohne klare Grenzen ändert ein Agent alles, was er für verbesserungswürdig hält. Der schlechte Prompt:

// Bad Prompt
Refactore die OrderService-Klasse, die ist zu groß geworden.

„Zu groß“ ist kein Kriterium, das ein Agent operationalisieren kann. Er könnte die Klasse aufspalten, das Interface ändern, abhängige Services umschreiben oder den gesamten Service-Layer umstrukturieren. Ein guter Refactoring-Prompt definiert Ist-Zustand, Ziel-Architektur und Grenzen:

// Good Prompt
Refactore OrderService.cs (aktuell 480 Zeilen, 12 Methoden). Ziel: Aufteilen in drei Handler nach CQRS (CreateOrderHandler, UpdateOrderStatusHandler, GetOrderQueryHandler). 
Behalte die bestehenden Interfaces IOrderService und IOrderRepository unverändert. Ändere NUR Dateien unter src/Features/Orders/. 
Stelle sicher, dass alle bestehenden Tests in tests/Unit/Orders/ weiterhin grün sind.

Drei Elemente machen den Unterschied. Der Ist-Zustand gibt dem Agenten eine Größenordnung, damit er die Komplexität einschätzen kann. Die Ziel-Architektur benennt die konkreten Klassen, nicht nur die Richtung. Und die Scope-Begrenzung verhindert, dass der Agent sich durch das halbe Projekt arbeitet. Der letzte Satz ist besonders wichtig: Bestehende Tests als Korrektheit-Kriterium zu definieren gibt dem Agenten ein objektives Maß, an dem er sein eigenes Refactoring validieren kann.

Pattern 3: Bug fixen

Bei Bugfixes ist die Versuchung besonders groß, das Ticket durchzureichen. „Login funktioniert nicht“ steht im Jira, also landet „Login funktioniert nicht“ beim Agenten. Das Ergebnis ist vorhersehbar:

// Bad Prompt
Der Login funktioniert nicht mehr seit dem letzten Deployment.

Der Agent hat keine Reproduktionsschritte, kein erwartetes Verhalten und kein Kriterium, wann der Bug gefixt ist. Er wird den gesamten Authentifizierungs-Stack durchsuchen, Vermutungen anstellen und möglicherweise Code ändern, der nicht betroffen ist. Ein guter Bugfix-Prompt folgt dem Pattern „Reproduktion, erwartetes Verhalten, Testkriterium“:

// Good Prompt
Bug: POST /api/auth/login gibt 500 zurück, wenn die E-Mail Umlaute enthält (z.B. "mueller@test.de"). 
Ohne Umlaute funktioniert der Login. Ursache vermutlich in AuthService.NormalizeEmail() in src/Features/Auth/AuthService.cs. 
Erwartetes Verhalten: Login mit Umlauten gibt 200 und ein JWT zurück. 
Schreibe einen Unit-Test LoginWithUmlaut_Returns200 in tests/Unit/Auth/LoginTests.cs, der vor dem Fix rot und danach grün ist.

Der Prompt enthält das, was ein erfahrener Entwickler bei der Fehleranalyse bereits herausgefunden hat. Die Reproduktion ist konkret genug, um sie automatisiert zu testen. Der Hinweis auf die vermutete Ursache spart dem Agenten Suchzeit, ohne ihn festzulegen. Und das Testkriterium, vorher rot und nachher grün, gibt dem Agenten einen Beweis, dass sein Fix korrekt ist.

Pattern 4: Migration durchführen

Migrationen sind Hochrisikoaufgaben mit Produktionsdaten. Ein vager Prompt kann hier nicht nur Code, sondern Daten beschädigen. Der schlechte Prompt zeigt das Problem:

// Bad Prompt
Migriere die Benutzertabelle auf das neue Schema.

Welches neue Schema? Welche Spalten ändern sich? Was passiert mit bestehenden Daten? Gibt es einen Rollback-Plan? Der Agent kennt die Antworten nicht und erfindet sie. Ein guter Migrations-Prompt definiert Quell- und Zielschema, Datenvolumen und Rollback:

// Good Prompt
Erstelle eine EF Core Migration, die die Tabelle Users ändert: Spalte "Name" (nvarchar 200) aufteilen in "FirstName" (nvarchar 100, NOT NULL) und "LastName" (nvarchar 100, NOT NULL). Bestehende Daten: Trenne am ersten Leerzeichen. Falls kein Leerzeichen, setze den gesamten Wert als LastName und FirstName auf "N/A". Tabelle hat ca. 50.000 Zeilen. Erstelle eine Down-Migration, die FirstName und LastName wieder zu Name zusammenführt. Teste beide
Richtungen in einem Integration-Test mit Testcontainers.

Jede Unklarheit ist eliminiert. Der Agent weiß, was mit Sonderfällen passiert, wie groß die Datenmenge ist und dass ein Rollback existieren muss. Der Hinweis auf 50.000 Zeilen ist nicht nur Information, sondern eine Leitplanke: Der Agent wird keine In-Memory-Lösung wählen, die bei dieser Größenordnung den Speicher sprengt. Und die Down-Migration stellt sicher, dass ein Deployment zurückgerollt werden kann, bevor es in Produktion Probleme verursacht.

Pattern 5: Test-Suite erweitern

Tests sind der Bereich, in dem vage Prompts die schönsten Ergebnisse mit dem geringsten Nutzen erzeugen. Der Agent schreibt gern Tests. Aber ohne Führung schreibt er die falschen:

// Bad Prompt
Schreibe mehr Tests für den OrderService.

Der Agent erzeugt Happy-Path-Tests für Methoden, die bereits getestet sind. Die Coverage-Zahl steigt, die Qualität nicht. Ein guter Prompt für Tests benennt Coverage-Lücken, Testkonventionen und Edge Cases:

// Good Prompt
Erweitere die Tests für OrderService in tests/Unit/Orders/OrderServiceTests.cs. Fehlende Coverage: Die Methoden CancelOrder and UpdateOrderStatus haben keine Tests für Fehlerfälle. Schreibe Tests für: Stornierung einer bereits versandten Bestellung (soll Result.Failure zurückgeben), Statuswechsel auf einen ungültigen Folgezustand (z.B. Shipped nach Cancelled) und Zugriff auf eine Order, die einem anderen User gehört (soll NotAuthorized zurückgeben). Nutze das Naming-Schema MethodName_Scenario_Expected und FluentAssertions.

Der Prompt verlagert die intellektuelle Arbeit dorthin, wo sie hingehört: Der Entwickler identifiziert, welche Fälle fehlen, und der Agent implementiert sie. Die drei Edge Cases sind nicht zufällig gewählt: Geschäftslogik-Verletzung, Zustandsmaschinenfehler und Autorisierung, drei Kategorien, die Agenten von sich aus selten abdecken. Das Naming-Schema und die Assertion-Library stellen sicher, dass die neuen Tests zu den bestehenden passen.

Das Muster hinter den Mustern

Alle fünf Patterns folgen demselben Prinzip: Was ein Mensch implizit mitdenkt, muss für den Agenten explizit werden. Jeder gute Prompt enthält drei Schichten. Die erste Schicht ist Kontext: Wo im Projekt befinden wir uns, welche Dateien sind betroffen, welches Pattern gilt? Die zweite Schicht ist das Ziel: Nicht was der Agent tun soll, sondern wie das Ergebnis aussieht. Die dritte Schicht umfasst die Grenzen: Was darf der Agent nicht verändern, welche Tests müssen bestehen bleiben, welche Konventionen gelten?

Die meisten Entwickler überspringen die dritte Schicht. Dabei ist sie die wichtigste. Ein Agent ohne Grenzen optimiert auf das, was er für richtig hält, und das deckt sich selten mit dem, was das Team entschieden hat. Die CLAUDE.md aus dem ersten Teil dieser Serie liefert einen Teil dieser Grenzen automatisch. Aber bei jeder Aufgabe gibt es aufgabenspezifische Constraints, die nur im Prompt stehen können.

Bemerkenswert ist auch, was sich verändert: Die Kompetenz verschiebt sich. Vor einem Jahr war die Frage, ob jemand ein Repository-Pattern korrekt implementieren kann. Heute ist die Frage, ob jemand die richtige Aufgabenbeschreibung formulieren kann, damit ein Agent das Repository-Pattern korrekt implementiert. Die handwerkliche Fähigkeit verschwindet nicht, aber sie wandert vom Code in den Prompt. Wer die Patterns versteht, kann sie auch beschreiben. Wer sie nicht versteht, schreibt vage Prompts und bekommt vagen Code.

Du programmierst in Kontext

Der Untertitel dieser Erkenntnis könnte lauten: Du programmierst nicht mehr in C#, du programmierst in Kontext. Die Sprache, in der du mit einem Coding-Agenten arbeitest, ist nicht C#, nicht TypeScript, nicht Python. Es ist die Sprache der präzisen Aufgabenbeschreibung, angereichert mit Verweisen auf Bestehendes, mit klaren Grenzen und mit messbaren Erfolgskriterien.

Das Jira-Ticket „Bewertungssystem implementieren“ ist immer noch der Ausgangspunkt. Aber zwischen Ticket und Agent steht jetzt ein neuer Arbeitsschritt: die Übersetzung von implizitem Wissen in expliziten Kontext. Dieser Arbeitsschritt dauert drei bis fünf Minuten und spart dreißig bis sechzig. Er ist die neue Kernkompetenz. Der Hauptartikel dieser Serie [1] beschreibt, wie sich die Rolle des Entwicklers insgesamt verändert. Dieser ergänzende Beitrag hat ein Werkzeug für den Alltag geliefert: fünf Muster, mit denen aus vagen Tickets präzise Prompts werden.

[1] Patrick Schnell, Der Stellenwert von Developern in Zeiten von KI, dotnetpro 4/2026, Seite 6 ff.