Prompt Engineering beginnt vor dem Prompt

Bei Prompt Engineering denken viele noch immer zuerst an Formulierungen, Rollenbeschreibungen, XML-Tags, Prompt-Templates oder besonders ausführliche Systemanweisungen. Typisch ist etwa ein Einstieg wie:

„You are a world-class senior software architect …“

Über die letzten Jahre ist rund um Prompts eine eigene kleine Disziplin entstanden, in der mitunter der Eindruck vermittelt wurde, zwischen einer mittelmäßigen und einer hervorragenden AI-Antwort liege vor allem die richtige sprachliche Formel.

Daran ist nicht alles falsch. Struktur kann helfen. Beispiele können helfen. Klare Sprache hilft. Auch aktuelle Model-Guidance beschreibt weiterhin konkrete Prompting-Techniken.

Für meine praktische Arbeit mit Coding Agents ist das inzwischen allerdings nur noch ein relativ kleiner Teil des Problems.

Nehmen wir einen vollkommen verständlichen Satz:

Baue mir eine Benutzerverwaltung.

Sprachlich gibt es daran wenig auszusetzen. Der Auftrag ist kurz, eindeutig formuliert und verwendet keine unnötigen Fremdwörter.

Trotzdem fehlen fast alle Informationen, die für eine reale Umsetzung relevant wären.

Welche Benutzer gibt es? Welche Rollen besitzen sie? Wer darf Benutzer anlegen? Können Benutzer ihre eigenen Daten ändern? Gibt es Einladungen? Wie funktioniert die Authentifizierung? Welche Daten müssen gespeichert werden? Was passiert bei doppelten E-Mail-Adressen? Gibt es bereits einen Identity Provider? Welche Teile des bestehenden Systems dürfen verändert werden? Welche Architektur gilt? Welche Fehlerfälle gehören zum Scope? Was ist ausdrücklich kein Bestandteil dieses Auftrags? Und woran erkennen wir am Ende überhaupt, dass das Feature korrekt umgesetzt wurde?

Keines dieser Probleme lässt sich dadurch beheben, dass wir vor den ursprünglichen Satz noch schreiben:

You are a world-class senior software architect.

Ein gut formulierter unklarer Auftrag bleibt ein unklarer Auftrag. Das eigentliche Engineering beginnt deshalb nicht bei der Frage, wie wir denselben Auftrag sprachlich raffinierter formulieren, sondern bei den Entscheidungen und Informationen, die ihm noch fehlen.

Warum dieser Artikel aus den vorherigen folgt

Die letzten drei Artikel dieser Serie haben dafür Stück für Stück die Grundlage gelegt.

In Artikel 4 ging es um Context, Memory, Agent Files, Skills und Tools. Dort haben wir Context als das beschrieben, was für die aktuelle Modellverarbeitung tatsächlich auf dem „Schreibtisch“ liegt. Memory, Agent Files, Skills und Projektdokumentation können dafür Informationen bereitstellen, erfüllen aber unterschiedliche Rollen. Vor allem haben wir zwischen dauerhaftem Projektwissen und dem aktuellen Arbeitsauftrag unterschieden.

Daraus folgt bereits eine wichtige Konsequenz für Prompts: Ein Umsetzungsprompt muss nicht jedes Mal erklären, wie das gesamte Repository funktioniert.

Wenn in einem Projekt dauerhaft gilt, dass Presentation nicht direkt auf Infrastructure zugreifen darf, ist das keine Information, die ich bei jedem Ticket neu erfinden möchte. Wenn eine bestimmte Teststrategie gilt, wenn Naming-Regeln existieren oder ein bestimmtes Layering verbindlich ist, brauchen solche Entscheidungen eine dauerhafte Heimat.

Vereinfacht:

Agent Files / Skills / Memory / Dokumentation
=
dauerhaftes Arbeitswissen

Umsetzungsprompt
=
konkreter Auftrag für diesen Task

Aktuelle Praxisberichte stützen genau diese Trennung. Anthropic beschreibt Context Engineering als die fortlaufende Auswahl eines möglichst relevanten statt möglichst großen Contexts und empfiehlt bei Agents unter anderem Just-in-Time-Retrieval. OpenAI berichtet aus einem eigenen agent-first Softwareprojekt, dass ein großes monolithisches AGENTS.md den Task, Code und relevante Dokumentation aus dem Context verdrängen kann, Regeln schnell veralten und zu viel Guidance ihre Priorität verliert. Dort dient eine kurze Agent-Datei deshalb eher als Wegweiser zu tieferer, versionierter Repository-Dokumentation.

Artikel 5 hat anschließend eine andere Eigenschaft betrachtet: Ein Agent konstruiert einen Lösungsweg. Er liest Dateien, verwendet Tools, bewertet Beobachtungen und entscheidet auf Grundlage des dadurch veränderten Contexts weiter. Derselbe Auftrag muss deshalb nicht zwangsläufig in denselben Implementierungspfad führen.

Wenn wir diesen Lösungsweg nicht vollständig deterministisch vorschreiben wollen – und bei einem Agenten wäre das häufig widersinnig –, müssen wir wenigstens den Raum definieren, innerhalb dessen Entscheidungen akzeptabel sind.

Artikel 6 hat die nächste Schwierigkeit ergänzt. Ein plausibler Weg kann auf einer falschen Annahme beruhen. Eine solche Annahme kann zur Codeänderung werden, committed werden und später selbst als lokale Evidenz im Repository auftauchen. Aus einzelnen falschen Entscheidungen kann damit Drift entstehen. Gleichzeitig haben wir gesehen, dass Generation und Verifikation unterschiedliche Aufgaben sind.

Damit landen wir fast zwangsläufig bei Requirements.

Wir schreiben ausführliche Umsetzungsprompts nicht, weil Agents möglichst viel Text brauchen. Wir tun es, weil Context begrenzt ist, Agents Entscheidungsspielraum besitzen und plausible Lösungen trotzdem falsch sein können.

Die Frage lautet also nicht einfach: Wie schreibe ich einen besseren Prompt?

Sie lautet zuerst: Was muss eigentlich gelten?

Der eigentliche Prompt entsteht am Ende

Meine aktuelle Arbeitsweise beginnt deshalb normalerweise nicht damit, einen Umsetzungsprompt zu schreiben.

Am Anfang steht häufig nur eine Idee, ein Ticket oder eine Beobachtung. Danach beginnt Discovery.

Ein vereinfachtes mentales Modell sieht so aus:

Idee / Ticket
↓
Discovery
↓
Rückfragen
↓
Alternativen
↓
fachliche Entscheidungen
↓
technische Entscheidungen
↓
Constraints
↓
Akzeptanzkriterien
↓
Umsetzungsprompt
↓
Agent
↓
Verifikation

Das ist ausdrücklich kein Prozessmodell, das ich Punkt für Punkt abhake. In meinem Alltag gibt es keinen Statuswechsel mit dem Namen „Discovery abgeschlossen“.

Manche Aufgaben sind nach fünf Minuten ausreichend klar, andere brauchen mehrere Gesprächsschleifen. Bei Legacy-Systemen muss zunächst Code untersucht werden; manchmal wird dabei erst sichtbar, dass eine fachliche Entscheidung fehlt. In anderen Fällen reicht eine vorhandene Referenzimplementierung bereits aus, um fast alle technischen Fragen zu beantworten.

Ich arbeite dabei eher nach einer 80/20-Regel: Ich möchte genug verstanden und entschieden haben, damit der nächste Schritt kontrolliert möglich wird. Ich versuche nicht, jede denkbare zukünftige Frage im Voraus zu beantworten.

Discovery ist fertig genug, wenn der nächste kontrollierbare Schritt sinnvoll möglich ist.

Das bedeutet auch, dass Requirements nicht plötzlich vollständig werden. Während der Umsetzung können neue Informationen auftauchen, Annahmen sich als falsch erweisen, ein bestehender Contract anders reagieren als erwartet oder ein fachlicher Sonderfall erst beim konkreten Durchspielen eines Datenflusses sichtbar werden. Nachschärfen ist deshalb kein Versagen der Discovery, sondern Teil davon.

Das LLM als Requirements-Sparringspartner

An dieser Stelle bekommt ein starkes LLM für mich eine andere Rolle als später der Coding Agent: Es soll nicht nur meine Fragen beantworten, sondern mir selbst Fragen stellen.

Wenn ich eine Feature-Idee beschreibe, möchte ich wissen, welche Entscheidung darin noch versteckt ist. Welche Annahme wurde nicht ausgesprochen? Welcher Fehlerfall fehlt? Welche Rollen sind betroffen? Was bedeutet „löschen“ fachlich wirklich? Welche Information müsste ein Entwickler kennen, um nicht selbst eine Produktentscheidung treffen zu müssen? Welches Verhalten ist nur meine spontane Vorstellung und welches tatsächlich Requirement?

Typische Fragen können beispielsweise sein:

Was ist in dieser Anforderung noch unklar?

Welche Annahmen treffen wir gerade implizit?

Welche Edge Cases fehlen?

Welche fachliche Entscheidung ist noch offen?

Was gehört explizit nicht zum Scope?

Welche bestehenden Systemgrenzen könnten betroffen sein?

Woran erkennen wir später, dass die Umsetzung korrekt ist?

Ein gutes Planungsmodell beantwortet nicht nur Fragen. Es macht fehlende Fragen sichtbar.

Das ist keine rein theoretische Verwendung von LLMs. Forschung zu LLM-gestützter Requirements Elicitation untersucht inzwischen ausdrücklich die Generierung von Rückfragen an Stakeholder. Eine 2025 veröffentlichte Arbeit zu Software Requirement Patterns kam beispielsweise zu dem Ergebnis, dass LLM-generierte Elicitation-Fragen grundsätzlich praktikabel sind, gleichzeitig aber unter anderem Wiederholungen und Out-of-Scope-Fragen erzeugen können und weiterhin erhebliches Expert Assessment benötigen. Eine systematische Mapping Study vom August 2026 kommt bei 74 untersuchten Arbeiten ebenfalls zu einem interessanten Bild: Automatisierung ist bei der Identifikation möglicher Requirements vergleichsweise weit verbreitet, wird aber deutlich dünner, sobald Konsolidierung und insbesondere Stakeholder-Validierung ins Spiel kommen.

Das passt ziemlich gut zu meiner praktischen Rolle für ein Planungsmodell: Es ist ein Sparringspartner, nicht der Requirements Owner.

Wer darf diese Entscheidung überhaupt treffen?

Gerade Softwareentwickler sind daran gewöhnt, Probleme zu lösen. Das kann während einer Discovery erstaunlich schnell dazu führen, dass wir Entscheidungen treffen, für die wir eigentlich gar kein Mandat besitzen.

Technisch betrachtet lässt sich vielleicht elegant ein zusätzlicher Status einführen. Vielleicht wäre ein anderer Datenfluss konsistenter. Ein neuer Prozessschritt könnte einen Sonderfall beseitigen. Oder eine geänderte Berechtigungslogik würde die Implementierung deutlich vereinfachen.

Damit ist noch nicht gesagt, dass wir diese Änderung vornehmen dürfen. In realen Projekten existieren Product Owner, Fachbereiche, Auftraggeber, Domänenexperten oder andere Personen, die bestimmte fachliche Entscheidungen verantworten. Wenn ein Ticket nicht eindeutig festlegt, ob ein Benutzer einen Vorgang erneut öffnen darf, ist „die technisch schönste Variante“ nicht automatisch die richtige Antwort.

Requirements Engineering bedeutet auch, Entscheidungen nicht dort zu treffen, wo man gar nicht entscheidungsberechtigt ist.

Das gilt für Menschen genauso wie für Agents.

Ein Planungsmodell kann Optionen herausarbeiten, Konsequenzen erklären, Widersprüche sichtbar machen und Alternativen vergleichen. Die Entscheidung bleibt trotzdem dort, wo die fachliche Verantwortung liegt, denn technisch korrekt bedeutet nicht automatisch fachlich richtig.

In Legacy-Systemen wird Discovery technisch

Bei einem Greenfield-Projekt können viele technische Entscheidungen direkt beschrieben werden. In einem Legacy-System weiß ich zu Beginn häufig selbst nicht genug über den tatsächlichen Zustand.

Dann entsteht bei mir ein Ping-Pong zwischen Planungsmodell, Coding Agent und Repository.

Planungs-LLM
↓
Explorationsauftrag
↓
Coding Agent untersucht Repository
↓
Befund
↓
zurück ins Planning
↓
neue Entscheidung

Der entscheidende Unterschied zum normalen Coding-Auftrag ist das Ziel: Der Explorationsprompt soll noch nichts implementieren, sondern beispielsweise herausfinden, ob bereits ein ähnlicher Flow existiert, welche Patterns tatsächlich verwendet werden, welche Komponenten betroffen sind, wie ein Datenfluss momentan funktioniert oder welche Abhängigkeiten eine geplante Änderung berühren würde.

Ein solcher Auftrag kann sehr eng sein:

Untersuche, wie vergleichbare Create-Flows
in diesem Feature aktuell umgesetzt sind.

Implementiere nichts.

Berichte:
- relevante Dateien,
- wiederkehrende Patterns,
- Abweichungen,
- verwendete Abhängigkeiten,
- offene Fragen.

Wenn mehrere konkurrierende Patterns existieren,
bewerte nicht selbst, welches zukünftig gelten soll.

Das Repository wird damit Teil der Discovery. Gerade in gewachsenen Systemen ist das wichtig, weil Dokumentation und tatsächlicher Code nicht zwingend dasselbe erzählen. OpenAI beschreibt bei seinem internen Data Agent einen verwandten Mechanismus: Metadaten allein reichen dort nicht aus, weshalb Code gezielt untersucht wird, um die tatsächliche Bedeutung und Entstehung von Daten zu verstehen. Das Team fasst eine seiner Erfahrungen sinngemäß so zusammen: Die Bedeutung steckt häufig im ausführenden Code, nicht nur in seiner Beschreibung.

Für Legacy-Software würde ich den Gedanken noch breiter formulieren:

In Legacy-Systemen entstehen Requirements nicht nur im Gespräch. Ein Teil davon muss aus dem bestehenden System herausgearbeitet werden.

Der Coding Agent ist in dieser Phase zunächst Explorationswerkzeug statt Implementierer.

Discovery darf divergieren, Implementation deutlich weniger

Während dieser Discovery möchte ich von einem Planungsmodell durchaus Kreativität.

Es darf Alternativen entwickeln, eine Idee infrage stellen, einen anderen Datenfluss vorschlagen oder erklären, warum meine erste Lösung unnötig kompliziert erscheint. In dieser Phase ist ein größerer Lösungsraum hilfreich, weil ich noch verstehen möchte, welche Möglichkeiten überhaupt existieren.

Sobald dagegen fachliches Verhalten, Architektur und Coding Style feststehen, verändert sich die Aufgabe.

Discovery
=
Lösungsraum öffnen

Decision
=
Optionen bewerten

Implementation
=
Lösungsraum schließen

Darauf wird ein späterer Artikel dieser Serie noch ausführlicher eingehen. Für den Moment reicht eine Beobachtung aus meiner eigenen Arbeit: Kreativität ist nicht in jeder Phase gleich wertvoll.

Wenn ein Projekt entschieden hat, wie Slices aufgebaut sind, wie Dependencies verlaufen, wie State modelliert wird und wie Naming funktioniert, möchte ich nicht, dass ein Agent bei jedem neuen Feature eine weitere plausible Variante erfindet.

Mein persönlicher Anspruch lautet inzwischen:

Das Projekt soll sich lesen, als hätte ein Entwickler es geschrieben.

Damit meine ich nicht, dass jeder Entwickler identischen Code produzieren würde, sondern Konsistenz. Ein Repository sollte nicht anhand seiner Architektur erkennen lassen, welcher Agent oder welches Modell gerade an welchem Feature gearbeitet hat.

Bei Coding Style, Layering, Naming und Dependency Rules ist zusätzliche Kreativität häufig kein Vorteil.

Sie ist neue Varianz.

Was ist dann ein Umsetzungsprompt?

Vor diesem Hintergrund ist

Baue Feature X.

für mich normalerweise kein Umsetzungsprompt.

Für einen kleinen POC kann das vollkommen legitim sein. Eine minimale Korrektur braucht ebenfalls keine fünf Seiten Spezifikation. Und wenn ich bewusst herausfinden möchte, welche Lösung ein Agent selbst entwickelt, darf der Auftrag absichtlich offen bleiben.

Bei einer fachlich relevanten Änderung in einem bestehenden System sieht mein Arbeitsauftrag jedoch deutlich anders aus.

Ein umfangreicher Umsetzungsprompt kann enthalten:

• Ziel und fachlichen Zweck,
• Scope und Nicht-Ziele,
• relevante Erkenntnisse aus der Discovery,
• betroffene Slices oder Module,
• bereits getroffene fachliche Entscheidungen,
• relevante Architekturgrenzen,
• vorhandene Referenz-Patterns,
• Daten- und State-Flows,
• Fehler- und Edge-Cases,
• Akzeptanzkriterien,
• notwendige Tests,
• Verifikationsschritte,
• Stop Conditions,
• gegebenenfalls eine sinnvolle Umsetzungsreihenfolge.

Ein solcher Prompt kann sich tatsächlich eher wie eine mehrseitige technische Spezifikation lesen als wie ein Chat-Satz.

Ein Umsetzungsprompt ist kein Zuruf an einen Agenten. Er ist eine verdichtete Spezifikation des Problems und seiner Grenzen.

Auch aktuelle OpenAI-Guidance für agentische Modelle weist inzwischen explizit in eine ähnliche Richtung: Statt jeden Arbeitsschritt vorzuschreiben, sollen Prompts Outcome, Success Criteria, Constraints, verfügbare Evidenz und Stop-Regeln definieren. Für Coding Workflows werden zusätzlich Akzeptanzkriterien, Tests sowie Regeln dafür empfohlen, wann ein Agent weiterarbeiten und wann er Hilfe anfordern soll.

Das ist ein wichtiger Unterschied zu der simplen Vorstellung, Prompt Engineering bedeute, denselben Auftrag nur ausführlicher zu formulieren: Die zusätzliche Länge hat eine Funktion.

Jeder Abschnitt sollte ein Risiko reduzieren

Warum brauche ich all diese Informationen? Nicht weil ein Agent lange Texte bevorzugt, sondern weil unterschiedliche Teile des Arbeitsauftrags unterschiedliche Fehlerklassen begrenzen.

Bestandteil	Welches Risiko reduziert er?
Ziel	Der Agent optimiert nicht auf ein technisch interessantes, aber falsches Problem.
Relevanter Context	Task-spezifisches Wissen ist nicht automatisch verfügbar.
Scope	Plausible Zusatzfeatures werden nicht unbemerkt Teil des Auftrags.
Constraints	Der akzeptable Lösungsraum wird begrenzt.
Bestehende Patterns	Relevante lokale Evidenz wird gegenüber zufällig gefundenen Beispielen sichtbar.
Nicht-Ziele	Die Änderung expandiert nicht unnötig.
Akzeptanzkriterien	„Sieht plausibel aus“ wird von „erfüllt den Auftrag“ getrennt.
Verifikation	Generierter Output wird nicht zu seinem eigenen Qualitätsnachweis.
Stop Conditions	Der Agent trifft bei gebrochenen Grundannahmen nicht stillschweigend neue Grundsatzentscheidungen.

Damit laufen die letzten Artikel wieder zusammen: Context ist begrenzt, der Lösungsweg besitzt Varianz und Plausibilität reicht nicht als Qualitätsmaßstab.

Jeder zusätzliche Abschnitt im Prompt sollte deshalb ein konkretes Risiko reduzieren – nicht einfach den Prompt länger machen.

Lange Prompts sind nicht automatisch bessere Prompts

Aus dem bisherigen Argument ließe sich leicht die falsche Schlussfolgerung ziehen: Wenn ein detaillierter Prompt besser ist als ein unklarer Prompt, müsste ein noch längerer Prompt doch noch besser sein. So funktioniert es nicht.

Ein gigantischer Arbeitsauftrag kann schwer reviewbar werden. Er kann sich selbst widersprechen. Alte Entscheidungen können neben neuen stehen. Relevante Regeln gehen zwischen unwichtigen Details unter. Vor allem entsteht schnell ein sehr großes Arbeitspaket, bei dem der Agent lange arbeitet, bevor ein Mensch oder ein anderer Verifikationsschritt das Ergebnis sieht.

Damit wächst die mögliche Drift-Strecke. Meine Praxis ist deshalb, größere Vorhaben bewusst in kleinere Arbeitspakete zu zerlegen:

Discovery
↓
Arbeitspaket 1
↓
Review / Verifikation
↓
Arbeitspaket 2
↓
Review / Verifikation
↓
Arbeitspaket 3

Kleine Arbeitspakete verkürzen den Abstand zwischen Generation und Verifikation.

Das lässt sich inzwischen auch in aktuellen Agent-Harnesses beobachten. Anthropic beschreibt für länger laufende Softwareentwicklung sowohl die Zerlegung in handhabbare Einheiten als auch explizite Contracts dafür, was innerhalb eines Arbeitspakets als „done“ gilt und wie dieser Zustand überprüft wird. Interessant ist allerdings die spätere Erkenntnis desselben Experiments: Mit leistungsfähigeren Modellen konnte ein Teil dieser Sprint-Struktur wieder entfernt werden. Die Struktur war also kein Dogma, sondern eine Antwort auf die Unsicherheit und Leistungsgrenzen der jeweiligen Aufgabe und des jeweiligen Modells.

Genau so betrachte ich auch meine Arbeitspakete: Es gibt keine ideale Anzahl Dateien, keine ideale Prompt-Länge und keine universelle Zahl von Akzeptanzkriterien. Die Paketgröße sollte sich an der Unsicherheit orientieren.

Bugs sind ein Sonderfall

Noch deutlicher wird das bei Bugs. Bei einer Feature-Umsetzung können zusätzliche Details Unsicherheit reduzieren, weil viele Entscheidungen bereits getroffen wurden; bei einem unbekannten Fehler kann derselbe Detailgrad die Untersuchung dagegen verschlechtern.

Nehmen wir an, eine Liste aktualisiert sich erst, nachdem die Seite verlassen und erneut geöffnet wurde. Wenn ich dem Agenten schreibe:

Das Problem liegt daran, dass Store X
nach dem Update nicht invalidiert wird.

Füge dort einen Reload ein.

habe ich möglicherweise bereits die wichtigste Entscheidung getroffen: die Ursache.

Wenn meine Hypothese falsch ist, kann der Agent nun eine hervorragende Umsetzung einer falschen Diagnose produzieren.

Für Bugs beschreibe ich deshalb häufig zunächst:

Beobachtetes Verhalten
Erwartetes Verhalten
Reproduktionsbedingungen
bekannte Beobachtungen
relevante Constraints

Untersuche zuerst die Ursache.
Implementiere noch keine Lösung,
bevor der tatsächliche Flow nachvollzogen wurde.

Details sollen Unsicherheit dort reduzieren, wo Entscheidungen bereits getroffen wurden – nicht dort, wo der Agent erst noch untersuchen soll.

Das klingt zunächst widersprüchlich zu ausführlichen Prompts. Tatsächlich ist es dieselbe Regel.

Wir versuchen also nicht, möglichst viel festzulegen, sondern den richtigen Entscheidungsspielraum festzulegen.

Rückfragen sind kein Fehler im Prompt

Trotz ausführlicher Discovery wird ein Coding Agent während einer Umsetzung auf Dinge stoßen, die vorher niemand gesehen hat.

Das ist normal. Vielleicht existiert die erwartete API nicht, ein benachbartes Feature arbeitet anders als die Dokumentation behauptet, zwei Patterns widersprechen sich oder die geplante Lösung wäre nur möglich, wenn eine bisher unbekannte Architekturgrenze verletzt wird.

Ein Agent sollte in solchen Situationen nicht deshalb raten müssen, weil wir uns vorgenommen haben, dass ein guter Prompt angeblich jede Rückfrage verhindert. Rückfragen sind Teil des Arbeitsmodells.

Interessanterweise beschreibt OpenAI seinen internen Data Agent ähnlich: Bei unklaren oder unvollständigen Anweisungen stellt das System aktiv Rückfragen und kann für unkritische Lücken sinnvolle Defaults verwenden. Das dahinterliegende Prinzip ist wichtiger als die konkrete Implementierung: Nicht jede Unklarheit besitzt dasselbe Risiko.

Für triviale Entscheidungen kann ein Agent Autonomie besitzen; bei fachlich oder architektonisch relevanten Entscheidungen kann dagegen ein Breakpoint sinnvoll sein.

Stop Conditions definieren das Ende der Autonomie

Eine meiner nützlichsten Prompt-Komponenten sind deshalb explizite Stop Conditions.

Zum Beispiel:

Wenn kein bestehendes Architektur-Pattern
für diesen Fall gefunden wird:

STOP.

Berichte den Befund.

Treffe keine neue globale
Architekturentscheidung eigenständig.

Oder:

Wenn die erwartete API nicht existiert
oder ihr Contract wesentlich vom beschriebenen
Verhalten abweicht:

STOP.

Dokumentiere die Abweichung und
schlage mögliche nächste Schritte vor.

Andere Breakpoints können sein:

• ein notwendiger Contract fehlt,
• das Ticket widerspricht dem tatsächlich vorhandenen Verhalten,
• die geforderte Umsetzung würde eine definierte Dependency Rule verletzen,
• ein fachlicher Zustand ist nicht spezifiziert,
• die Umsetzung benötigt deutlich größere Änderungen als im Scope vorgesehen.

Nicht jede Unsicherheit muss vorher gelöst sein. Aber wir können definieren, wo der erlaubte Entscheidungsspielraum endet.

Damit bekommen Stop Conditions dieselbe Funktion wie andere Constraints: Sie beschreiben nicht den vollständigen Weg, sondern begrenzen den Lösungsraum.

Aktuelle OpenAI-Guidance nennt solche Stopping Conditions inzwischen ebenfalls explizit und verbindet sie mit Success Criteria und Regeln für fehlende Evidenz. Das ist bemerkenswert weit entfernt vom alten Bild einer geheimen Prompt-Formulierung.

Dauerhafte Entscheidungen gehören nicht in einen einzelnen Task

Während einer Umsetzung kann trotzdem eine neue Grundsatzentscheidung entstehen.

Vielleicht stellen wir fest, dass für eine bestimmte Klasse von Features künftig ein einheitlicher Mapper verwendet werden soll. Vielleicht entsteht eine neue Dependency Rule. Vielleicht wird ein neues Naming festgelegt oder ein bisher implizites Architektur-Pattern erstmals bewusst entschieden.

Dann gehört die Entscheidung zunächst in den aktuellen Arbeitskontext. Danach folgt jedoch eine zweite Frage: Wo soll sie beim nächsten Feature stehen?

Wenn die Antwort lautet „im Prompt von letzter Dienstag“, haben wir ein Problem.

Dauerhafte Regeln brauchen eine dauerhafte Heimat. Je nach Art der Information kann das ein Agent File, ein Skill, Projektdokumentation, ein ADR, ein Architekturtest oder eine andere automatisierte Regel sein.

Task-spezifisch
→ Umsetzungsprompt

wiederverwendbarer Workflow
→ Skill

dauerhafte Projektregel
→ Agent File / Dokumentation / ADR

mechanisch prüfbare Regel
→ Test / Linter / Architekturregel

Die Grenzen sind nicht in jedem Agent-System identisch; entscheidend ist die Absicht. Task-spezifische Entscheidungen gehören in den Umsetzungsprompt. Dauerhafte Projektentscheidungen brauchen eine dauerhafte Heimat. Damit schließen wir direkt an Artikel 4 an und vermeiden zugleich ein Problem aus Artikel 6: Eine wichtige Entscheidung soll nicht nur dadurch zum Pattern werden, dass sie irgendwann zufällig als Code committed wurde, sondern sichtbar entschieden werden.

Ich schreibe kaum noch Umsetzungsprompts

Damit kommen wir zu einem vielleicht etwas ungewöhnlichen Teil meiner persönlichen Arbeitsweise.

Kurze Korrekturprompts schreibe ich weiterhin direkt. Wenn eine Aufgabe klein und eindeutig ist, brauche ich keinen zusätzlichen Prozess.

Bei größeren Features arbeite ich dagegen intensiv an Requirements, Scope, Entscheidungen, Architekturfragen und Akzeptanzkriterien – den endgültigen umfangreichen Umsetzungsprompt formuliere ich jedoch häufig nicht mehr selbst, sondern lasse ihn von einem LLM erstellen.

Ich schreibe kaum noch Umsetzungsprompts. Ich erarbeite ihren Inhalt.

Das ist für mich ein wesentlicher Unterschied. Meine Aufmerksamkeit soll nicht darauf liegen, ob Abschnitt drei besser „Constraints“ oder „Technical Boundaries“ heißt, sondern darauf, welche Grenze tatsächlich gilt.

Ein starkes Modell ist ausgesprochen gut darin, bereits geklärte Informationen in einen strukturierten Arbeitsauftrag zu übersetzen. Es kann Redundanzen entfernen, Entscheidungen gruppieren, Akzeptanzkriterien explizit machen und aus mehreren Gesprächsschleifen ein konsistentes Execution Briefing erzeugen.

Die kritische Grenze liegt woanders: Die AI darf den Prompt schreiben. Aber sie sollte nicht unbemerkt die Requirements erfinden.

Wenn das Planungsmodell eine fehlende Produktentscheidung einfach mit einer plausiblen Variante auffüllt und anschließend selbstbewusst in den Umsetzungsprompt schreibt, haben wir nichts gewonnen. Dann wurde nur verschleiert, wo eine Entscheidung entstanden ist.

Eine aktuelle Anthropic-Auswertung von ungefähr 400.000 Claude-Code-Sessions zwischen Oktober 2025 und April 2026 liefert dazu ein interessantes Praxisbild. In der dort verwendeten classifier-basierten Auswertung trafen Menschen durchschnittlich etwa 70 Prozent der Planning-Entscheidungen, während Claude ungefähr 80 Prozent der Execution-Entscheidungen traf. Anthropic interpretiert das als erkennbare Arbeitsteilung: Menschen bestimmen stärker, was gebaut wird und wann etwas als fertig gilt; der Agent übernimmt stärker die konkrete Ausführung. Die Studie ist keine universelle Regel für Agentic Work, aber sie beschreibt erstaunlich genau das Muster, das sich auch in meiner Arbeit entwickelt hat.

OpenAI beschreibt aus einem eigenen agent-first Softwareprojekt eine ähnliche Verschiebung: Die menschliche Arbeit konzentrierte sich dort zunehmend darauf, Umgebungen zu gestalten, Intent zu spezifizieren und Feedbackschleifen aufzubauen, während Codex den Code erzeugte.

Meine Kurzform dafür lautet: Der Mensch authored nicht zwingend den Prompt. Er authored die Requirements.

Der Prompt als kompiliertes Arbeitsartefakt

Man kann sich das – ausdrücklich nur als Metapher – wie einen kleinen Compiler vorstellen.

Intent
↓
Requirements
↓
Entscheidungen
↓
Constraints
↓
LLM
↓
Execution Prompt
↓
Agent
↓
Artifact

Der Begriff „Prompt-Compiler“ ist technisch natürlich unpräzise: Ein LLM kompiliert Requirements nicht deterministisch wie ein TypeScript-Compiler Quelltext. Als mentales Modell gefällt mir die Metapher trotzdem, weil sie den Ort verschiebt, an dem wir den eigentlichen Wert erzeugen.

Der Prompt ist nicht der magische Quelltext, aus dem plötzlich ein Feature entsteht, sondern die verdichtete, für einen Agenten nutzbare Darstellung bereits erarbeiteter Informationen und Entscheidungen.

Das erklärt gleichzeitig, warum der finale Prompt sehr umfangreich sein kann, obwohl ich kaum Zeit mit seiner konkreten Formulierung verbracht habe: Die eigentliche Arbeit steckte vorher darin.

Dasselbe Muster funktioniert beim Schreiben

Diese Arbeitsweise ist nicht auf Softwareentwicklung beschränkt.

Diese Artikelserie entsteht beispielsweise nicht dadurch, dass ich am Anfang schreibe:

Schreib einen Artikel über Halluzinationen.

Am Anfang steht eher eine These oder eine Beobachtung. Danach folgen Gespräche: Begriffe werden auseinandergezogen, zu starke Aussagen korrigiert, Forschung gesucht, nicht vergleichbare Zahlen verworfen und persönliche Erfahrungen eingeordnet. Erst dabei wird klarer, welche Behauptung tatsächlich tragfähig ist und welche nur gut klingt.

Erst danach entsteht ein ausführlicher Generierungsauftrag.

erste These
↓
Gespräch
↓
Recherche
↓
Gegenfragen
↓
Entscheidungen
↓
roter Faden
↓
Generierungsprompt
↓
Draft
↓
redaktionelles Review

Der Generierungsprompt enthält dann vielleicht bereits Titel, zentrale Aussagen, Quellenrahmen, Beispiele, Dinge, die ausdrücklich nicht behauptet werden sollen, gewünschte Übergänge und die Verbindung zu anderen Artikeln.

Von außen sieht das aus wie ein sehr guter Prompt. Tatsächlich ist er nur die letzte sichtbare Stufe einer längeren Discovery.

Der Generierungsprompt ist nicht der kreative Anfang. Er ist das Ergebnis eines vorherigen Denkprozesses.

Und selbstverständlich ist der erste Draft danach noch kein veröffentlichter Artikel; Generation und Redaktion bleiben unterschiedliche Schritte.

Dasselbe gilt für Bildgenerierung

Bei Bildern passiert etwas Ähnliches. Ich könnte ein Image Model bitten:

Erstelle eine Infografik über Architecture Drift.

Vielleicht entsteht sogar ein hübsches Bild. Die wichtigere Arbeit beginnt aber wieder vorher: Was soll die Grafik erklären? Welche Beziehung soll auf einen Blick sichtbar werden? Brauche ich einen Prozess, einen Vergleich oder eine räumliche Metapher? Welche Aussage darf das Bild gerade nicht suggerieren? Welche Texte müssen exakt sichtbar sein? Welche Elemente sind semantisch relevant und welche nur dekorativ?

Erst wenn diese Fragen geklärt sind, brauche ich eine Übersetzung in die Sprache des jeweiligen Image Models.

Auch hier muss der Mensch nicht zwangsläufig der beste Prompt-Autor sein; er muss vor allem wissen, was das Bild vermitteln soll.

Das spezialisierte Modell oder ein anderes LLM kann anschließend dabei helfen, diese Absicht in einen geeigneten Prompt zu übersetzen.

Prompt Engineering wird zu Engineering vor dem Prompt

Damit verändert sich für mich die Bedeutung des Begriffs.

Prompt Engineering ist nicht verschwunden. Natürlich spielen konkrete Formulierungen weiterhin eine Rolle; Struktur, Beispiele, Prioritäten und klare Instructions beeinflussen Modellverhalten. Bei realer agentischer Arbeit ist dieser Teil jedoch in ein größeres Problem eingebettet.

Anthropic bezeichnet diese Entwicklung auf technischer Ebene inzwischen als Übergang von Prompt Engineering zu Context Engineering: Statt nur einzelne Formulierungen zu optimieren, müssen Agent-Systeme den gesamten verfügbaren Informationszustand kuratieren. OpenAI berichtet aus eigener Praxis parallel davon, dass zu starre, hochgradig präskriptive Prompts schlechter funktionieren können und die robustere Variante darin bestand, Ziel und relevante Grenzen vorzugeben, während das Modell den konkreten Pfad bestimmt.

Für meine Arbeit würde ich den Gedanken noch einen Schritt weiterziehen:

Prompt Engineering verschiebt sich vom Schreiben von Prompts zum Engineering der Informationen und Entscheidungen, aus denen Prompts entstehen.

Dazu gehören Discovery und Requirements genauso wie Context-Auswahl, Architekturregeln, Akzeptanzkriterien, Verifikation und die bewusste Entscheidung darüber, wo ein Agent selbst entscheiden darf. Der Prompt steht deshalb nicht am Anfang dieses Prozesses, sondern ziemlich weit hinten.

Requirements sind die erste Grenze

Damit kommen wir wieder zur eigentlichen Funktion dieses Artikels innerhalb der Serie.

Artikel 5 hat gezeigt, dass mehrere plausible Lösungswege existieren können. Wir wollen diese Eigenschaft nicht vollständig beseitigen. Ein Agent soll selbst entscheiden dürfen, welche Datei er zuerst liest oder wie er innerhalb der bestehenden Architektur eine lokale Implementierungsfrage löst.

Artikel 6 hat allerdings gezeigt, dass plausibel nicht automatisch richtig bedeutet. Deshalb brauchen wir Grenzen, und Requirements definieren zunächst, was am Ende gelten muss.

Sie beantworten beispielsweise:

Welche fachlichen Zustände sind erlaubt? Was bedeutet Erfolg? Was ist ein Fehler? Welche Benutzer dürfen welche Aktion durchführen? Was gehört zum Scope? Welche Eigenschaften sind unverhandelbar? Welche Bedingungen müssen nach der Umsetzung beobachtbar erfüllt sein?

Requirements definieren, welche Ergebnisse überhaupt als akzeptabel gelten dürfen.

Sie determinieren damit nicht automatisch den vollständigen Lösungsweg, sondern beschreiben den akzeptablen Ergebnisraum. Das ist ein wichtiger Unterschied.

Requirements sind noch keine Architektur

Und trotzdem fehlt uns danach noch etwas. Nehmen wir ein Requirement:

Ein Benutzer darf nur seine eigenen Daten ändern.

Das beschreibt gewünschtes fachliches beziehungsweise sicherheitsrelevantes Verhalten.

Eine Architekturregel wäre dagegen beispielsweise:

Presentation darf nicht direkt
auf Infrastructure zugreifen.

Beide Aussagen begrenzen Lösungen, aber auf unterschiedlichen Ebenen.

Requirements beschreiben primär, was gelten muss.

Architekturconstraints beschreiben stärker, welche strukturellen Grenzen bei der Lösung nicht verletzt werden dürfen.

Diese Unterscheidung wird wichtig, wenn Agents beginnen, größere Teile eines Systems selbstständig zu verändern. Denn ein fachlich korrektes Ergebnis kann strukturell trotzdem eine schlechte Lösung sein.

Der Prompt beginnt vorher

Wenn ich heute einen mehrseitigen Umsetzungsprompt an einen Coding Agent übergebe, liegt der wichtigste Teil der Arbeit deshalb bereits hinter mir. Wir haben Fragen gestellt und das Repository untersucht, fachliche von technischen Entscheidungen getrennt, Scope und Nicht-Ziele definiert, Zuständigkeiten geklärt, den erlaubten Entscheidungsspielraum des Agents festgelegt und entschieden, woran das Ergebnis später überprüft wird. Erst danach wird daraus ein Prompt.

Prompt Engineering beginnt vor dem Prompt. Artikel 4 hat gezeigt, dass der Agent relevanten Context braucht; Artikel 5, dass er darin unterschiedliche Lösungswege wählen kann; und Artikel 6, dass ein plausibler Weg trotzdem auf einer falschen Annahme beruhen kann. Artikel 7 ergänzt deshalb die nächste Konsequenz: Wir müssen genauer definieren, welches Ergebnis wir akzeptieren und wo der Entscheidungsspielraum endet.

Requirements sind die erste Grenze, aber sie reichen noch nicht. Selbst wenn fachlich vollkommen klar ist, was gelten muss, bleibt die Frage, wie wir sicherstellen, dass die Lösung strukturell zu dem System passt, das bereits existiert. Genau darum geht es im nächsten Artikel.

Requirements begrenzen das fachlich akzeptable Ergebnis. Im nächsten Schritt müssen wir dasselbe mit der Struktur des Systems tun.

Quellen und Einordnung

• OpenAI – Model Guidance / Prompting Best Practices, Stand September 2026. Die aktuelle GPT-5.5-Guidance empfiehlt für agentische Aufgaben Outcome, Success Criteria, Constraints, verfügbare Evidenz und explizite Stopping Conditions und rät zugleich von unnötigem Prozess-Mikromanagement ab. Das ist produktspezifische Guidance, keine universelle Prompt-Theorie. Model guidance
• OpenAI – Inside OpenAI’s in-house data agent, Januar 2026. Der Praxisbericht beschreibt mehrschichtigen Context, aktive Rückfragen bei unklaren oder unvollständigen Anweisungen, sinnvolle Defaults sowie die Erfahrung „Guide the Goal, Not the Path“. Außerdem wird Code gezielt als Quelle semantischer Evidenz genutzt. Inside OpenAI’s in-house data agent
• OpenAI – Harness engineering: leveraging Codex in an agent-first world, Februar 2026. Der Bericht beschreibt ein internes agent-first Softwareprojekt, in dem menschliche Arbeit stark in Richtung Intent, Umgebungsdesign und Feedbackschleifen verschoben wurde. Ein großes monolithisches AGENTS.md erwies sich dort als problematisch; eine kurze Agent-Datei dient stattdessen als Wegweiser in eine versionierte Wissensbasis. Harness engineering
• Anthropic – Effective context engineering for AI agents, September 2025. Anthropic beschreibt Context als endliche Ressource und verschiebt den Fokus von einzelnen Prompt-Formulierungen hin zur Frage, welche Informationen dem Modell zu welchem Zeitpunkt verfügbar sein sollten. Effective context engineering for AI agents
• Anthropic – Agentic coding and persistent returns to expertise, Juni 2026. Privacy-preserving, classifier-basierte Analyse von ungefähr 400.000 Claude-Code-Sessions zwischen Oktober 2025 und April 2026. In einer typischen Session trafen Menschen ungefähr 70 Prozent der Planning-Entscheidungen, Claude ungefähr 80 Prozent der Execution-Entscheidungen. Das beschreibt Nutzungsmuster eines konkreten Produkts, kein universelles Gesetz agentischer Arbeit. Agentic coding and persistent returns to expertise
• Anthropic – Harness design for long-running application development, März 2026. Der Praxisbericht untersucht Planner/Generator/Evaluator-Strukturen, Sprint-Contracts und testbare Kriterien. Besonders interessant ist die spätere Vereinfachung: Mit Opus 4.6 konnte die Sprint-Zerlegung entfernt werden, während der Evaluator an den Grenzen der Modellfähigkeit weiterhin Nutzen brachte. Harness design for long-running application development
• Franch et al. – Leveraging Requirements Elicitation through Software Requirement Patterns and LLMs, REFSQ 2025. Die Arbeit zeigt, dass LLM-generierte Stakeholder-Fragen grundsätzlich praktikabel sind, aber unter anderem Wiederholungen und Out-of-Scope-Fragen erzeugen können und erhebliches Expert Assessment benötigen. Publikationseintrag
• Eltahier et al. – Automated Software Requirements Elicitation: A Systematic Mapping Study, August 2026. Die Studie ordnet 74 peer-reviewte Arbeiten von 2021 bis 2025 ein. Alle 74 automatisieren Identifikation; 51 Prozent erreichen Strukturierung, 23 Prozent Konsolidierung und nur 8 Prozent eine technisch integrierte Stakeholder-Validation. Information 17(8), 777
• Pasquale et al. – Exploring the Use of LLMs for Requirements Specification in an IT Consulting Company, IEEE RE 2025. Der industrielle Fall zeigt, dass LLMs Requirements-Spezifikationen standardisieren und die Erstellung unterstützen können, die Qualität jedoch stark vom Input abhängt und menschliche fachliche sowie technische Revision weiterhin notwendig bleibt. IEEE DOI