Prompt Engineering für Coding: 7 Muster, die wir täglich in Claude Code und Cursor nutzen (2026)

Prompt Engineering für Coding entscheidet darüber, ob ein Agent einen funktionierenden Pull Request liefert oder still etwas in der Produktion kaputt macht. Wir haben das auf die teure Art gelernt: Eine vage Anweisung in unserer eigenen Pipeline hat einmal 54 doppelte Live-Seiten erzeugt, bevor es jemand bemerkte. Heute schreibt, übersetzt und veröffentlicht ein 16-Agenten-Claude-Code-Setup unsere Inhalte, und die Prompts dahinter sehen den 50-Vorlagen-Listen auf der ersten Google-Seite überhaupt nicht ähnlich. Hier sind die 7 Muster, die wir jeden Tag eintippen, jedes mit einem echten Vorher-Nachher-Beispiel.

Kurzantwort: Gute Coding-Prompts teilen eine Form. Sie nennen das Ziel und die Definition von "fertig", benennen exakt die betroffenen Dateien, erzwingen einen Plan vor jeder Änderung, übergeben die Tests und verlangen Belege statt eines "sieht gut aus". Tun Sie das, schreibt ein moderner Agent (Claude Code, Cursor, GitHub Copilot) deutlich häufiger Code, der die Prüfung beim ersten Mal besteht. Lassen Sie es weg, bekommen Sie selbstsicheren, plausiblen Unsinn.

Die 7 Muster, in der Reihenfolge, in der wir sie einsetzen:

1. Task-Framing: Ziel, Einschränkungen und "fertig" von Anfang an
2. Kontextauswahl: Dateien benennen, den Rest ausklammern
3. Plan zuerst: Vorschlag verlangen, bevor editiert wird
4. Tests zuerst: die Abnahmetests in den Prompt legen
5. Debugging: Fehler plus Reproduktion plus Erwartung, Ursache vor Fix
6. Refactoring: Struktur ändern, Verhalten beibehalten, Diff zeigen
7. Review: eine Checkliste zum Abgleichen, plus Belege

Prompt Engineering für Coding vs. Konfigurationsdateien: Was gehört wohin

Konfigurationsdateien und Task-Prompts erfüllen unterschiedliche Aufgaben, und sie zu vermischen ist der häufigste Fehler in diesem Bereich. Eine CLAUDE.md oder eine .cursor/rules-Datei ist eine feste Richtlinie, die der Agent bei jeder Sitzung liest: Ihr Stack, Ihre Namenskonventionen, Ihr Testbefehl. Ein Prompt ist die konkrete Aufgabe, die Sie ihm gerade jetzt übergeben. Dauerhafte Regeln gehören in die Konfiguration, die Aufgabe in den Prompt.

Die meisten Zusammenstellungen von "Coding-Prompts" verwischen das und raten dazu, einen riesigen Persona-Prompt in .cursorrules einzufügen. Das bläht die Konfiguration auf, die der Agent bei jeder einzelnen Aufgabe lädt, und verfehlt trotzdem, die konkrete Aufgabe vor ihm zu rahmen. Halten Sie beides getrennt:

Wenn Sie die Konfigurationsseite gut umsetzen wollen: Wir behandeln sie ausführlich in unserem CLAUDE.md Best-Practices-Leitfaden und im Cursor-Regeln-Leitfaden. Dieser Artikel ist die andere Hälfte: die Prompts, die Sie jedes Mal neu eintippen. Beide gehören zu unserem umfassenderen Prompt-Engineering-Leitfaden, falls Sie zuerst die Grundlagen wollen.

Prompt Engineering für Coding: Die 7 Muster, die wir täglich nutzen

Jedes Muster unten hat die schwache Version, die Leute tatsächlich eintippen, und die starke Version, die funktionierenden Code liefert. Der Sprung von schwach zu stark ist fast immer derselbe: einen Wunsch durch eine Spezifikation ersetzen.

1. Task-Framing: Ziel, Einschränkungen und "Fertig" nennen

Task-Framing bedeutet, das Ziel, die Einschränkungen und wie "fertig" aussieht zu formulieren, bevor der Agent auch nur eine Zeile anfasst. Ein Agent optimiert auf das, was Sie wörtlich gefragt haben, also verdient eine unscharfe Anfrage einen unscharfen Patch. Nennen Sie die Datei, das gewünschte Verhalten, die Abnahmeprüfung und die Dinge, die er nicht ändern darf.

Das ist das Muster, das uns 54 Seiten gekostet hat. Unsere alte Übersetzungsanweisung war im Grunde ein Wunsch:

Schwach: Übersetze diesen Beitrag ins Deutsche und behalte die Markennamen bei.

Nichts darin sagt, was ein Slug tun darf. Also hat der Agent beim erneuten Lauf den URL-Slug "verbessert", und weil ein neuer Slug ein neues Dokument bedeutet, hatten wir am Ende zwei Live-Seiten auf Deutsch für denselben Beitrag. Multipliziert über Sprachen und alte Beiträge ergibt das 54 Duplikate und einen Berg an Duplicate-Content-Ausschlüssen. Der Fix war eine Spezifikation, kein netterer Wunsch:

Stark: Übersetze diesen Beitrag ins Deutsche.
- Falls bereits eine deutsche Datei existiert, übernimm ihren bestehenden
  Slug wörtlich. Niemals neu ableiten oder "verbessern".
- Suche vor dem Anlegen eines Dokuments das vorhandene über seine
  kanonische Referenz und verwende diesen Datensatz weiter.
- Falls der Slug, den du erzeugen würdest, vom Live-Slug abweicht, STOPPE
  und melde es mir. Ein geänderter Slug erzeugt eine zweite Live-URL für
  dieselbe Seite.

Der starke Prompt benennt den Fehlerfall laut. Diese eine Angewohnheit, auszusprechen, was nicht passieren darf und warum, ist die wertvollste einzelne Änderung, die die meisten Teams vornehmen können. Wir beenden außerdem jeden Task-Prompt mit einem expliziten Output-Vertrag ("deine abschließende Nachricht muss die Wortzahl, den Validierungswert und alle bearbeiteten Dateien melden"), damit der Agent weiß, was "fertig" liefern soll, nicht nur was zu tun ist.

2. Kontextauswahl: Dateien benennen, den Rest ausklammern

Kontextauswahl bedeutet, dem Agenten genau zu sagen, welche Dateien er lesen soll und welche er in Ruhe lassen soll, statt ihn herumgreppen und sein Fenster mit Rauschen füllen zu lassen. Anthropics eigene Anleitung ist unverblümt bei der Begründung: Das Kontextfenster füllt sich schnell, und die Qualität sinkt, je voller es wird, weshalb die meisten Best Practices genau das schützen sollen (Claude Code Best Practices).

Schwach: Behebe den Bug im Checkout-Flow.

Stark: Lies nur src/checkout/cart.ts und src/checkout/tax.ts. Die
Steuerrundung ist falsch bei Bestellungen über 1.000 $ (sie rundet jede
Position statt der Bestellsumme). Behebe die Rundung. Fasse nichts
außerhalb von src/checkout/ an.

Wir grenzen hart ab. Ein echter Satz aus unseren Agenten-Prompts lautet: "Schreibe nicht in url-mapping.json, pipeline.md oder config.json, und fasse niemals eine Datei außerhalb deines Scratchpad-Verzeichnisses an." Dieser eine Satz hat mehr versehentlichen Schaden verhindert als jede nachträgliche Aufräumaktion. Wenn eine Aufgabe wirklich Live-Dokumente oder zusätzliche Tools braucht, fügen wir sie gezielt über MCP-Server hinzu, statt zu hoffen, dass der Agent zufällig auf die richtige Datei stößt. Und wenn dieser Kontext von außerhalb Ihres Repos kommt, behandeln Sie ihn als nicht vertrauenswürdig: Siehe unseren Hinweis zur Prevention von Prompt Injection, bevor Sie eine gescrapte Seite in einen Coding-Agenten einfügen.

3. Plan zuerst: Vorschlag verlangen, bevor editiert wird

Plan-First-Prompting lässt den Agenten Ihnen erst einen Ansatz vorlegen, bevor er irgendetwas editiert. In Claude Code ist der Plan Mode ein harter, erzwungener Nur-Lese-Zustand, kein höfliches "erst denken", an dem das Modell vorbeischlendern könnte, es kann also buchstäblich nicht schreiben, bis Sie den Plan freigeben. Forschung und Planung von der Ausführung zu trennen ist die einzelne Praxis, auf die sich Anthropic am meisten stützt, um zu verhindern, dass das falsche Problem gelöst wird.

Schwach: Füge Rate Limiting zur API hinzu.

Stark: Gib mir vor dem Schreiben von Code einen nummerierten Plan: welche
Middleware, wo die Zähler leben, wie du die 429-Antwort und die Header
behandelst, und welche Tests du hinzufügst. Warte auf meine Freigabe,
bevor du editierst.

Warum das funktioniert: Der Plan ist billig zu lesen und billig zu korrigieren. Einen falschen Plan zu reparieren kostet einen Satz, falschen Code zu reparieren kostet einen Review-Zyklus. Das passt natürlich zu der Bitte, das Modell zuerst Schritt für Schritt denken zu lassen (siehe Chain-of-Thought-Prompting), und es ist das Rückgrat der mehrstufigen Claude Code Workflows, die wir für alles Nicht-Triviale einsetzen.

4. Tests zuerst: Die Abnahmetests in den Prompt legen

Test-First-Prompting legt die Abnahmekriterien als konkrete Eingaben und Ausgaben in den Prompt, damit der Agent Code gegen ein von Ihnen definiertes Ziel schreibt statt gegen eines, das er erraten hat. Fügen Sie den fehlschlagenden Test ein, oder eine kleine Tabelle mit erwarteten Ergebnissen, und sagen Sie: "Bring das zum Bestehen, ohne den Test zu ändern."

Schwach: Schreibe eine Funktion zum Parsen von ISO-8601-Daten.

Stark: Bring diesen fehlschlagenden Test zum Bestehen, ohne den Test zu
ändern:

  parseIso("2026-07-20T15:00:00Z")   -> Date genau zu diesem UTC-Zeitpunkt
  parseIso("2026-07-20")             -> Date zu 2026-07-20T00:00:00Z
  parseIso("not-a-date")             -> wirft RangeError
  parseIso("")                       -> wirft RangeError

Gib nur die Funktion und ihre Imports zurück.

Konkrete Beispiele schlagen Adjektive jedes Mal. "Randfälle behandeln" ist eine Hoffnung; vier Zeilen von Eingabe zu Ausgabe sind eine Spezifikation, die das Modell tatsächlich erfüllen kann, und Sie können sie ausführen, sobald der Code landet.

5. Debugging: Fehler, Reproduktion, Erwartung, Ursache vor Fix

Ein Debugging-Prompt gibt dem Agenten den Fehlertext, die Eingabe, die ihn auslöst, und was Sie erwartet haben, und verlangt dann die Ursache, bevor irgendein Fix kommt. Lassen Sie das weg, flickt der Agent das Symptom, und der Bug zieht einfach an einen ruhigeren Ort um.

Schwach: Das wirft einen Fehler, behebe ihn.

Stark: Das wirft beim Checkout. Hier der Stack Trace: [einfügen]. Es
passiert nur, wenn der Warenkorb einen Rabattcode UND eine Geschenkkarte
hat (Reproduktion: beides hinzufügen, dann bezahlen). Erwartet: beides
wird angewendet, Geschenkkarte zuletzt. Finde die Ursache und erkläre sie
in einem Satz, bevor du etwas änderst. Verpacke es nicht in einem
try/catch, das den Fehler versteckt.

Der Satz "erkläre die Ursache zuerst in einem Satz" leistet echte Arbeit. Er zwingt das Modell, sich auf eine Diagnose festzulegen, die Sie plausibilitätsprüfen können, statt einen Fix zu liefern, dessen Logik Sie nie sehen. Der Satz "verstecke es nicht in einem try/catch" schließt das gängigste Schlupfloch.

6. Refactoring: Struktur ändern, Verhalten beibehalten, Diff zeigen

Ein Refactoring-Prompt schränkt den Umfang hart ein: Struktur ändern, Verhalten identisch lassen, Diff zeigen. Ohne diese Abgrenzung "räumen" Agenten Dinge auf, nach denen Sie nie gefragt haben, und Sie verlieren die Fähigkeit, die Änderung zu prüfen, die tatsächlich zählte.

Schwach: Räume diese Datei auf.

Stark: Extrahiere die Validierungslogik aus submitOrder() in eine reine
Funktion validateOrder(). Behalte jede öffentliche Signatur und jedes
Verhalten identisch bei. Ändere nichts anderes in dieser Datei. Zeig mir
einen Vorher/Nachher-Diff und eine Zeile dazu, warum jede Änderung
verhaltenserhaltend ist.

Das ist die Kehrseite der Trennung von Konfiguration und Prompt von weiter oben: Ihre festen Stilregeln leben in den Cursor-Regeln, aber der Umfang dieses Refactorings gehört in den Prompt. "Ändere nichts anderes" ist der Satz, der Refactorings prüfbar hält.

7. Review: Eine Checkliste zum Abgleichen, plus Belege

Ein Review-Prompt gibt dem Agenten eine Checkliste zum Abgleichen und verlangt Belege, kein Urteil. "Sieht gut aus" ist wertlos; der ausgeführte Befehl und die erhaltene Ausgabe sind es nicht. Anthropic sagt das unverblümt: Lassen Sie den Agenten Belege zeigen (die Testausgabe, den Befehl und sein Ergebnis), statt Erfolg zu behaupten, weil das Lesen von Belegen schneller ist als eigenes erneutes Prüfen.

Schwach: Prüfe meinen PR.

Stark: Prüfe diesen Diff gegen genau diese fünf Punkte:
1. Keine Secrets oder API-Keys hinzugefügt
2. Jede neue Funktion hat einen Test
3. Keine Verhaltensänderung außerhalb von src/checkout/
4. Fehlerpfade geben typisierte Fehler zurück, keine Strings
5. Kein console.log zurückgelassen
Zitiere für jeden Punkt die Zeile, die ihn erfüllt oder verletzt. Führe
dann die Testsuite aus und füge die Ausgabe ein. Sag nicht "fertig";
zeig es mir.

Unser eigenes Review-Gate ist genau so aufgebaut. Bevor ein Agent einen Beitrag als veröffentlicht melden darf, greppt er den Entwurf gegen eine Liste verbotener Wörter (ein harter Blocker, null Toleranz) und führt eine Abfrage aus, um zu bestätigen, dass der Dokumentkörper nicht leer ist. Der Agent darf Erfolg nicht behaupten; er muss die Prüfungsausgabe produzieren. Für Reviewer-Rollen, die Sie oft wiederverwenden, befördern Sie die Checkliste zu einer gespeicherten Persona, und genau dafür gibt es System-Prompt-Beispiele.

Claude Code vs. Cursor vs. Copilot: Wo jedes Muster lebt

Alle drei großen Agenten von 2026 unterstützen jedes Muster oben, aber die Oberfläche unterscheidet sich. Claude Code setzt auf Plan Mode und Subagents, Cursor auf den Agent Mode und sein Agents-Fenster, GitHub Copilot auf den Agent Mode plus Instruction-Dateien. Wählen Sie das Tool, in dem Ihr Team lebt; die Muster übertragen sich sauber.

Ein paar aktuelle Details, die es wert sind, bekannt zu sein. Der Plan Mode von Claude Code ist eine echte Nur-Lese-Sperre, und seine Subagents laufen jeweils in einem isolierten Kontext mit eigenen Tools (Subagents-Dokumentation). Cursors 2026er-Linie hat ein Agents-Fenster hinzugefügt, das parallele Agenten startet, jeder in seinem eigenen Git-Worktree (Cursor 2.0). Der Agent Mode von GitHub Copilot liest benutzerdefinierte Anweisungen aus .github/copilot-instructions.md, plus pfadbezogene .instructions.md-Dateien mit einem applyTo-Feld (Copilot Custom Instructions). Wenn Cursor Ihr täglicher Begleiter ist, lesen Sie unseren Beitrag darüber, Cursor effizienter zu nutzen.

Wie wir unsere Coding-Agenten bei Techsy promoten

Wir betreiben eine Content-Pipeline als Team aus 16 Claude-Code-Agenten: ein Researcher, ein Brief-Autor, ein Content-Autor, neun Übersetzer, ein Validator und ein Publisher, koordiniert über Task-Nachrichten. Zwei Konventionen aus diesem System übertragen sich auf jedes Coding-Team.

Erstens endet jeder Task-Prompt mit einem Output-Vertrag. Die letzte Zeile ist immer irgendeine Version von "deine abschließende Nachricht muss X, Y und Z melden." Ein Agent, der die genaue Form von "fertig" kennt, verläuft sich deutlich seltener als einer, dem nur gesagt wurde, womit er anfangen soll.

Zweitens lassen wir einen Agenten niemals seine eigenen Hausaufgaben in Prosa bewerten. Erzeugung und Verifikation sind getrennte Schritte, und die Verifikation ist ein Befehl mit Ausgabe, keine Meinung. Diese Trennung von Bauen und Prüfen ist zentral dafür, wie Anthropic den Bau zuverlässiger Agenten rahmt, und deshalb greppt und fragt unser Review-Gate ab, statt einem "sieht gut aus" zu vertrauen.

Das ist auch unser Tagesgeschäft. Bei Techsy bauen wir KI-Agenten und Automatisierung für B2B-Teams, und Prompt-Disziplin wie diese macht den größten Unterschied zwischen einer Demo und etwas, das man einem Kunden vorlegen kann. Wenn Sie einen Coding- oder Agenten-Workflow richtig aufsetzen wollen, ist unser KI-Integrationsservice genau dafür da, und Sie können eine kostenlose Beratung buchen, um Ihren Stack durchzugehen.

Eine Copy-Paste-Prompt-Vorlage zum Anpassen

Hier das Skelett, mit dem wir bei jeder nicht-trivialen Coding-Aufgabe starten. Löschen Sie die Abschnitte, die Sie nicht brauchen, aber behalten Sie die Reihenfolge, denn sie spiegelt die sieben Muster.

ZIEL
Ein Satz: Was soll wahr sein, wenn du fertig bist.

KONTEXT
Nur lesen: <exakte Dateien>. Alles andere ignorieren.
Relevante Fakten: <Einschränkungen, Versionen, der Auslöser des Bugs>.

PLAN ZUERST
Gib mir vor dem Editieren einen nummerierten Plan und warte auf Freigabe.

TESTS / FERTIG
Fertig bedeutet: <fehlschlagenden Test oder Eingabe->Ausgabe-Zeilen einfügen>.
Ändere die Tests nicht.

EINSCHRÄNKUNGEN
Behalte alle öffentlichen Signaturen und das Verhalten identisch, sofern
nicht anders angegeben.
Fasse <Dateien/Bereiche> nicht an. Nenne jede Annahme, die du triffst.

OUTPUT
Zeig einen Vorher/Nachher-Diff, führe die Tests aus und füge die Ausgabe ein.
Sag nicht "fertig"; zeig die Belege.

Speichern Sie es als Snippet, oder besser, teilen Sie es auf: Die festen Einschränkungen gehören in Ihre Konfigurationsdatei, Ziel, Kontext und Tests gehören in den Prompt. Diese Aufteilung ist der ganze Sinn der Sache.

Häufig gestellte Fragen

Was ist Prompt Engineering für Coding?

Prompt Engineering für Coding ist die Praxis, Anweisungen zu schreiben, die einen KI-Agenten dazu bringen, korrekten, prüfbaren Code zu produzieren. In der Praxis bedeutet das, das Ziel und die Definition von "fertig" zu nennen, die betroffenen Dateien zu benennen, einen Plan vor der Bearbeitung zu erzwingen, Tests mitzuliefern und Belege zu verlangen. Es ähnelt eher dem Schreiben einer Spezifikation als dem Formulieren eines cleveren Satzes.

Wie unterscheidet sich das vom Schreiben einer CLAUDE.md- oder .cursor/rules-Datei?

Konfigurationsdateien enthalten feste Richtlinien, die der Agent bei jeder Sitzung liest: Ihren Stack, Konventionen und Testbefehl. Ein Task-Prompt ist die konkrete Aufgabe, die Sie ihm gerade jetzt übergeben. Dauerhafte Regeln gehören in die Konfiguration, die Aufgabe in den Prompt. Ganze Task-Prompts in eine Konfigurationsdatei einzufügen bläht jede Sitzung auf und verfehlt trotzdem, die einzelne Aufgabe zu rahmen.

Was ist die beste Prompt-Struktur für KI-Coding-Agenten?

Verwenden Sie beschriftete Abschnitte statt eines einzelnen Absatzes: ZIEL, KONTEXT, PLAN, TESTS, EINSCHRÄNKUNGEN und OUTPUT. Agenten parsen strukturierte Prompts zuverlässiger als Textwände. Nennen Sie Erfolgskriterien am Anfang, geben Sie ein bis drei konkrete Beispiele statt Adjektive, und legen Sie genau das Ausgabeformat fest, das Sie zurückerwarten.

Wie schreibe ich einen guten Debugging-Prompt?

Geben Sie dem Agenten vier Dinge: den exakten Fehler oder Stack Trace, die Eingabe, die ihn reproduziert, was Sie erwartet haben, und die Bitte um die Ursache vor jedem Fix. Fügen Sie "erkläre die Ursache in einem Satz, bevor du etwas änderst" hinzu, damit Sie die Diagnose prüfen können, und "verstecke es nicht in einem try/catch", damit er den Bug behebt statt ihn zu maskieren.

Sollte ich Tests in meine Coding-Prompts aufnehmen?

Ja, wann immer möglich. Den fehlschlagenden Test oder eine kleine Tabelle mit Eingabe-zu-Ausgabe-Zeilen einzufügen, verwandelt eine vage Anfrage in ein Ziel, das das Modell tatsächlich treffen kann, und Sie können das Ergebnis sofort ausführen. Sagen Sie dem Agenten, er soll die Tests bestehen lassen, ohne sie zu ändern, damit er die Torpfosten nicht verschieben kann, um seinen eigenen Code korrekt aussehen zu lassen.

Funktionieren diese Prompts auch in Cursor und GitHub Copilot?

Ja. Die Muster sind toolunabhängig. Claude Code zeigt sie über Plan Mode und Subagents, Cursor über den Agent Mode und sein Agents-Fenster mit einem Worktree pro Agent, und GitHub Copilot über den Agent Mode plus .github/copilot-instructions.md. Die Oberfläche ändert sich; Task-Framing, Kontextauswahl, Plan zuerst und beleggestützte Reviews nicht.

Wie lang sollte ein Coding-Prompt sein?

Lang genug, um eine Spezifikation zu sein, kurz genug, um fokussiert zu bleiben. Die Denkqualität sinkt, je voller der Kontext wird, also bevorzugen Sie Struktur vor Umfang: Ein beschrifteter Prompt mit 150 bis 300 Wörtern, den richtigen Dateien und Tests schlägt einen ausschweifenden. Verschieben Sie alles, was für jede Aufgabe gilt, in Ihre Konfigurationsdatei, statt es zu wiederholen.

Wie halte ich einen KI-Agenten davon ab, Code zu ändern, nach dem ich nicht gefragt habe?

Grenzen Sie den Umfang im Prompt ab. Sagen Sie genau, welche Dateien er bearbeiten darf, fügen Sie "ändere nichts anderes" hinzu, und verlangen Sie "behalte alle öffentlichen Signaturen und das Verhalten identisch, sofern ich nichts anderes sage". Bitten Sie bei Refactorings um einen Vorher/Nachher-Diff mit einer Zeile dazu, warum jede Änderung verhaltenserhaltend ist, damit jede ungefragte Änderung im Review sofort auffällt.

Lohnen sich Copy-Paste-Prompt-Bibliotheken?

Als Ausgangspunkt manchmal. Als fertiges Werkzeug selten. Eine Bibliothek mit 50 Prompts gibt Ihnen Formulierungen, kann aber Ihre Dateien, Ihre Tests oder Ihre Einschränkungen nicht kennen, und genau dort entscheidet sich Korrektheit. Lernen Sie die Muster, behalten Sie eine anpassbare Vorlage, und füllen Sie die Details der konkreten Aufgabe vor Ihnen selbst aus.