Das Prompt-Engineering-Playbook für Entwickler

Prompt-Engineering beim Programmieren ist die Fähigkeit, einem KI-Agenten so viel Kontext und so klare Anweisungen zu geben, dass er beim ersten Anlauf brauchbaren Code liefert. Es ist die wichtigste Einzelfähigkeit im Vibe Coding — wichtiger als die Wahl des Modells. Zwei Entwickler mit demselben Werkzeug bekommen völlig unterschiedliche Ergebnisse, und der Unterschied liegt fast immer im Prompt.

Diese Lektion ist ein Playbook: erst die sieben Prinzipien, die hinter jedem guten Prompt stehen, dann fertige Rezepte für den Alltag (Debugging, Refactoring, Tests, Reviews) und zum Schluss die Fehler, die du dir sparst.

Quelle & weiterführend: Diese Lektion orientiert sich thematisch an Addy Osmanis exzellentem Prompt Engineering Playbook for Programmers. Die Beispiele und Formulierungen hier sind eigenständig und auf Deutsch aufbereitet — für die englische Originalperspektive lies unbedingt auch Osmanis Artikel.

Das mentale Modell: ein brillanter Junior ohne Gedächtnis

Der nützlichste Denkrahmen: Behandle den Agenten wie einen extrem fähigen neuen Kollegen, der jede Sprache und jedes Framework beherrscht — aber deine Codebasis noch nie gesehen hat, eure Konventionen nicht kennt und sich nach jeder Aufgabe an nichts erinnert.

Einem echten Junior würdest du nie sagen „mach den Bug weg" und den Raum verlassen. Du würdest zeigen, wo der Bug auftritt, was passieren sollte, welche Datei relevant ist und wie ihr sonst so arbeitet. Genau das ist Prompt-Engineering. Jedes der folgenden Prinzipien ist eine Antwort auf eine Frage, die dieser Kollege sonst raten müsste.

Die 7 Prinzipien

Prinzip 1 — Kontext ist alles

Ein Modell kann nur mit dem arbeiten, was im Prompt steht. Es sieht deinen Bildschirm nicht, kennt die anderen Dateien nicht und ahnt nicht, welches Framework ihr nutzt. Der häufigste Grund für schlechten KI-Code ist nicht ein schwaches Modell, sondern fehlender Kontext.

Gib mit, was relevant ist:

• Den betroffenen Code — nicht beschreiben, sondern zeigen. Lieber die Funktion einfügen als „die Funktion, die die User lädt".
• Die vollständige Fehlermeldung — inklusive Stacktrace. Nicht „es gibt einen Fehler", sondern die exakten Zeilen.
• Das Umfeld — Sprache, Framework, Version, relevante Libraries. „React 19 mit TypeScript und Tailwind 4" grenzt den Lösungsraum sofort ein.
• Das Ziel — was soll am Ende funktionieren, nicht nur was gerade kaputt ist.

❌ „Warum funktioniert mein Fetch nicht?"

✅ „Dieser React-19-Hook wirft Cannot read properties of undefined (reading 'map'). Hier ist die Komponente [Code] und die volle Fehlermeldung [Stacktrace]. Die API gibt { users: [...] } zurück. Was ist die Ursache?"

In Claude Code übernimmt eine CLAUDE.md-Datei im Projekt-Root einen Teil dieser Arbeit dauerhaft: Konventionen, Architektur, Befehle. Damit wiederholst du den Grundkontext nicht in jedem Prompt.

Prinzip 2 — Sei spezifisch und definiere „fertig"

Vage Aufgaben erzeugen vage Ergebnisse. Je mehr Interpretationsspielraum du lässt, desto größer die Chance, dass der Agent etwas Plausibles baut, das nicht das ist, was du wolltest.

Ein guter Prompt enthält ein Akzeptanzkriterium — eine überprüfbare Definition von Erfolg:

❌ „Mach die Ladezeit besser."

✅ „Die Produktliste rendert bei 500 Einträgen sichtbar ruckelig. Ziel: flüssiges Scrollen. Nutze Virtualisierung, ändere aber die öffentliche Prop-Schnittstelle der Komponente nicht. Erklär mir vorher kurz deinen Ansatz."

Das Akzeptanzkriterium („flüssiges Scrollen"), die Randbedingung („Prop-Schnittstelle unverändert") und die Vorgabe zum Vorgehen („erst erklären") verwandeln eine Wunschäußerung in einen ausführbaren Auftrag.

Prinzip 3 — Gib dem Modell eine Rolle

Eine Rolle am Anfang des Prompts fokussiert Ton, Tiefe und Prioritäten der Antwort. „Du bist ein erfahrener Security-Engineer" führt zu einer anderen Analyse als „du bist ein Frontend-Entwickler mit Fokus auf Barrierefreiheit" — obwohl derselbe Code vorliegt.

Du bist ein erfahrener Backend-Entwickler mit Fokus auf sichere APIs.
Prüfe diesen Express-Endpoint auf Sicherheitslücken — besonders
Injection, fehlende Autorisierung und Datenlecks in Fehlermeldungen.

Die Rolle ist kein Zaubertrick, sondern ein Fokus-Werkzeug: Sie sagt dem Modell, aus welcher Perspektive es priorisieren soll.

Prinzip 4 — Zeig Beispiele (Few-Shot)

Modelle imitieren Muster hervorragend. Wenn du ein Beispiel für „so sieht guter Code bei uns aus" mitgibst, orientiert sich das Ergebnis daran — bei Namensgebung, Struktur, Test-Stil und Formatierung.

Das ist besonders stark bei projektspezifischen Konventionen, die kein allgemeines Modell kennen kann:

Schreib eine Funktion `formatCurrency(cents, currency)`.
Orientier dich an unserem Stil in dieser bestehenden Funktion:

[Beispielfunktion mit euren Konventionen: JSDoc, Fehlerbehandlung,
 Benennung, Test daneben]

Gleiche Struktur, gleicher Doku-Stil, gleiche Art der Fehlerbehandlung.

Ein einziges gutes Beispiel spart oft mehrere Iterationen. Das nennt man Few-Shot Prompting — im Gegensatz zum „Zero-Shot", bei dem du nur beschreibst, ohne zu zeigen.

Prinzip 5 — Lass das Modell erst denken

Bei nicht-trivialen Aufgaben liefert ein Modell bessere Ergebnisse, wenn es zuerst den Lösungsweg ausarbeiten darf, bevor es Code schreibt. Diese Technik heißt Chain-of-Thought (Gedankenkette). Sie funktioniert, weil das Modell seine eigene Zwischenüberlegung als Kontext für den nächsten Schritt nutzen kann — statt in einem Sprung von Frage zu Code zu springen.

Zwei bewährte Formulierungen:

• „Erklär mir zuerst deinen Plan in Stichpunkten. Fang erst mit dem Code an, wenn ich zustimme."
• „Denk das Schritt für Schritt durch, bevor du antwortest."

Der „erst planen, dann bauen"-Ansatz ist bei größeren Änderungen Gold wert: Du erkennst Missverständnisse im Plan, bevor 200 Zeilen Code in die falsche Richtung entstehen. In der Praxis:

Ich will die Auth von Session-Cookies auf JWT umstellen.
Bevor du Code schreibst: Skizzier den Migrationsplan — welche Dateien,
welche Reihenfolge, wo Risiken liegen. Dann warte auf mein OK.

Prinzip 6 — Lege Output-Format und Grenzen fest

Sag dem Modell, wie die Antwort aussehen soll und was es nicht tun darf. Ohne Vorgaben bekommst du oft mehr, als du wolltest — umgeschriebene Dateien, geänderte Namen, „hilfreiche" Extras.

Nützliche Constraints:

• Umfang: „Ändere nur die Funktion parseDate, lass den Rest der Datei unangetastet."
• Format: „Antworte nur mit dem geänderten Code-Block, ohne Erklärung." oder umgekehrt „Erklär jede Änderung in einem Satz."
• Verbote: „Füge keine neuen Dependencies hinzu." / „Ändere keine öffentlichen Schnittstellen."
• Struktur: „Gib die Antwort als Diff aus."

Gerade das Eingrenzen des Umfangs verhindert die klassische Situation, in der du einen kleinen Fix wolltest und eine komplett umgeschriebene Datei zurückbekommst.

Prinzip 7 — Iterieren statt neu würfeln

Der erste Output ist ein Entwurf, kein Endergebnis. Der Unterschied zwischen Frust und Fluss liegt darin, wie du nachsteuerst. Fang nicht bei null an — verweise auf das bestehende Ergebnis und ändere gezielt:

❌ [Neuen, kompletten Prompt schreiben und hoffen]

✅ „Fast richtig. Behalte die Struktur, aber: (1) any durch konkrete Typen ersetzen, (2) den Fehlerfall bei leerem Array abfangen, (3) den Kommentar oben entfernen."

Diese „behalte X, ändere Y"-Technik ist die produktivste Angewohnheit im Prompt-Engineering. Das Modell hat den Kontext des letzten Versuchs — nutze ihn, statt ihn wegzuwerfen. Wenn eine Session komplett in die falsche Richtung läuft, ist allerdings ein sauberer Neustart (in Claude Code /clear) besser als endloses Nachbessern auf verunreinigtem Kontext.

Prompt-Rezepte für den Entwickleralltag

Die Prinzipien werden konkret, wenn man sie in wiederkehrende Muster gießt. Hier sind fertige Vorlagen für die häufigsten Aufgaben — zum Kopieren und Anpassen.

Rezept: Feature bauen

Kontext: [Framework/Version, relevante Dateien einfügen]
Aufgabe: Baue [Feature] so, dass [Akzeptanzkriterium].
Randbedingungen: [was nicht geändert werden darf, welche Muster gelten]
Vorgehen: Skizzier zuerst den Plan (welche Dateien, welche Reihenfolge).
Warte auf mein OK, dann implementier.

Rezept: Debugging

Beim Debugging ist die entscheidende Anweisung, das Modell erst die Ursache erklären zu lassen, bevor es einen Fix vorschlägt. Sonst kuriert es oft nur das Symptom.

Dieser Code wirft [vollständige Fehlermeldung + Stacktrace].
Hier ist der relevante Code: [Code]
Erwartet: [was passieren sollte]. Tatsächlich: [was passiert].

Erklär mir zuerst die WURZEL-URSACHE des Fehlers.
Schlag erst danach einen Fix vor — und begründe, warum er die
Ursache behebt, nicht nur das Symptom.

Bleibt der Bug hartnäckig, hilft die Aufforderung zu Hypothesen: „Nenn mir drei mögliche Ursachen, sortiert nach Wahrscheinlichkeit, und wie ich jede überprüfe." Das lenkt den Agenten weg vom Raten hin zu systematischer Diagnose.

Rezept: Refactoring

Refaktoriere diese Funktion für bessere Lesbarkeit und Testbarkeit.
[Code]
Verhalten muss identisch bleiben — keine funktionalen Änderungen.
Behalte die öffentliche Signatur. Erklär jede Änderung in einem Satz.

Der Schlüssel ist die Garantie „Verhalten identisch": Sie hält das Refactoring von Feature-Änderungen getrennt. Kombiniere es mit „lass danach die bestehenden Tests laufen", wenn du in Claude Code arbeitest.

Rezept: Tests generieren

Schreib Unit-Tests für diese Funktion mit [Test-Framework].
[Code]
Deck ab: den Normalfall, Randfälle (leer, null, sehr groß) und
Fehlerfälle. Orientier dich am Stil dieses bestehenden Tests: [Beispiel]

Ein starker Zusatz: „Nenn mir zuerst die Fälle, die du testen willst, als Liste — dann schreib die Tests." So siehst du sofort, ob eine wichtige Kante fehlt.

Rezept: Code-Review

Review diesen Code wie ein strenger, aber fairer Senior-Entwickler.
[Code / Diff]
Achte auf: Korrektheit, Randfälle, Sicherheit, Lesbarkeit, Performance.
Sortier deine Funde nach Schweregrad. Bei jedem: warum es ein Problem
ist und ein konkreter Vorschlag. Lob, was gut gelöst ist.

Rezept: Fremden Code verstehen

Erklär mir diese Datei so, als würdest du mich ins Projekt einarbeiten.
[Code]
Was ist der Zweck? Wie fließen die Daten durch? Wo sind die kniffligen
Stellen, auf die ich achten muss, wenn ich hier etwas ändere?

Rezept: Dokumentation

Schreib eine JSDoc/Docstring für diese Funktion — knapp, aber vollständig:
Zweck, Parameter, Rückgabewert, geworfene Fehler, ein kurzes Beispiel.
Erfinde nichts dazu, was der Code nicht hergibt.

Fortgeschrittene Techniken

Lass das Modell Rückfragen stellen

Wenn eine Aufgabe unterspezifiziert ist, dreh den Spieß um:

Bevor du anfängst: Stell mir alle Fragen, die du brauchst, um das
richtig zu bauen. Rate nichts.

Das deckt Annahmen auf, bevor sie zu falschem Code werden — besonders wertvoll bei größeren Features.

Die Kritiker-Runde (Selbstkritik)

Modelle finden Schwächen im eigenen Output erstaunlich gut, wenn man sie explizit darum bittet:

Kritisier deine eigene Lösung von eben. Wo könnte sie fehlschlagen?
Welche Randfälle hast du übersehen? Dann verbessere sie.

Dieses Muster steckt auch hinter dem 4-Kritiker-Zyklus, mit dem wir KI-typische Schwächen im Content aufspüren — dasselbe Prinzip funktioniert für Code.

Kontext-Hygiene

Das Kontext-Fenster ist begrenzt und wird mit jeder Nachricht voller. Zwei Regeln:

• Fokussierte Sessions: Eine Aufgabe pro Session. Wenn du mitten in einem Feature plötzlich einen unabhängigen Bug fixt, verunreinigst du den Kontext beider Aufgaben.
• Neustart bei Abdriften: Läuft der Agent im Kreis, hilft /clear (oder ein neuer Chat) mehr als der zehnte Korrektur-Prompt. Verunreinigter Kontext lässt sich nicht wegprompten.

Wiederverwendbare Vorlagen

Gute Prompts sind Werkzeuge — sammle sie. Ein Ordner mit deinen bewährten Vorlagen (Debug, Review, Test) spart bei jedem Einsatz Zeit und macht deine Ergebnisse konsistent. In Claude Code lassen sich solche Muster als Slash-Commands oder Skills dauerhaft verankern.

Anti-Patterns: die häufigsten Fehler

Fehler	Warum er schadet	Besser
Vage Aufgabe ohne Akzeptanzkriterium	Modell rät, was „fertig" heißt	Überprüfbares Ziel mitgeben
Kontext beschreiben statt zeigen	Modell arbeitet mit deiner Zusammenfassung, nicht dem echten Code	Code + volle Fehlermeldung einfügen
Zu viel auf einmal	„Bau die ganze App" führt zu oberflächlichem Ergebnis	In Schritte zerlegen, iterieren
Bei jedem Fehler neu anfangen	Wirft nützlichen Kontext weg	„Behalte X, änder nur Y"
Symptom statt Ursache fixen	Bug kommt zurück	„Erklär erst die Wurzel-Ursache"
Blind übernehmen	KI-Code kann subtil falsch sein oder halluzinieren	Lesen, verstehen, testen — du bleibst verantwortlich
Endlos nachbessern auf schmutzigem Kontext	Session driftet immer weiter ab	Sauberer Neustart

Der letzte Punkt ist der wichtigste: Prompt-Engineering ersetzt nicht dein Urteilsvermögen. Der Agent schreibt den Code, aber du verantwortest ihn. Lesen, verstehen und testen ist kein optionaler Schritt.

Cheat-Sheet

Bevor du auf Enter drückst, prüf deinen Prompt gegen diese Liste:

1. Kontext — Ist der relevante Code / die Fehlermeldung drin, nicht nur beschrieben?
2. Ziel — Ist „fertig" überprüfbar definiert?
3. Grenzen — Ist klar, was nicht geändert werden soll?
4. Beispiel — Gibt es ein Muster, an dem sich das Ergebnis orientieren kann?
5. Denken — Bei komplexen Aufgaben: erst Plan, dann Code?
6. Format — Weiß das Modell, wie die Antwort aussehen soll?

Wenn vier dieser sechs Punkte stehen, ist dein Prompt besser als 90 % dessen, was Agenten üblicherweise vorgesetzt bekommen.

Zusammenfassung

• Prompt-Engineering ist die wichtigste Fähigkeit im Vibe Coding — wichtiger als die Modellwahl.
• Behandle den Agenten wie einen brillanten Junior ohne Gedächtnis: Er kann alles, weiß aber nur, was im Prompt steht.
• Die sieben Prinzipien: Kontext, Spezifität, Rolle, Beispiele, Denken-vor-Antworten, Format/Grenzen, Iteration.
• Nutz fertige Rezepte für Debugging, Refactoring, Tests und Reviews — und pass sie an dein Projekt an.
• Du bleibst verantwortlich. Lesen, verstehen, testen ist Pflicht, kein Extra.

Nächste Lektion: Telegram-Kanal erstellen — wir setzen die generierten Konzepte in die Praxis um.