--- title: "Prompt Patterns fuer Coding Agents" description: "Wiederverwendbare Prompt Patterns fuer Coding Agents: Rolle und Spec, Beispiele, Decomposition, Verification Loops und die Anti-Patterns, die du vermeidest." type: "guide" locale: "de-CH" category: "Prompting" canonical: "https://agenticschool.dev/de/ratgeber/prompt-patterns-for-coding-agents" datePublished: "2026-06-13" dateModified: "2026-06-13" --- # Prompt Patterns fuer Coding Agents - Kategorie: Prompting - Keywords: prompt engineering for coding agents, prompt patterns, system prompt examples, agent prompting techniques, how to prompt claude code - Kanonische URL: https://agenticschool.dev/de/ratgeber/prompt-patterns-for-coding-agents - Sprache: de-CH > Wiederverwendbare Prompt Patterns fuer Coding Agents: Rolle und Spec, Beispiele, Decomposition, Verification Loops und die Anti-Patterns, die du vermeidest. Ein Coding Agent ist nur so gut wie der Auftrag, den du ihm gibst, und der Unterschied zwischen einer frustrierenden und einer zuverlässigen Session ist selten das Modell, sondern der Prompt. Einen Coding Agent zu prompten ist nicht dasselbe wie mit einem Chatbot zu plaudern: Der Agent liest deine Dateien, führt Befehle aus und handelt in einem Loop, also setzt ein guter Prompt die Rolle, definiert, wie "fertig" aussieht, zeigt die Form einer guten Antwort, zerlegt grosse Arbeit in prüfbare Schritte und sagt dem Agenten, wie er seinen eigenen Output verifiziert. Dieser Guide sammelt die Prompt Patterns, die mit Coding Agents wie Claude Code und Codex CLI verlässlich funktionieren, mit konkreten Beispielen zum Anpassen, und die Anti-Patterns, die still deine Zeit und Tokens verschwenden. Alles hier ist Stand Juni 2026 und passt zur Foundations-Lektion zum Prompt Engineering. ## Warum das Prompten eines Coding Agents anders ist Ein Chatbot antwortet einmal; ein Coding Agent arbeitet in einem Loop, liest dein Repository, editiert Dateien, führt deine Tests aus und reagiert auf die Ergebnisse. Das ändert, was ein guter Prompt leisten muss. Du fragst nicht nach einem Snippet, du briefst einen Teamkollegen, der echte Aktionen in deiner Codebasis ausführt, also muss der Prompt die Absicht tragen (was du willst und warum), die Constraints (deinen Stack, deine Konventionen und was er nicht anfassen soll) und eine Definition von "fertig", gegen die der Agent sich selbst prüfen kann. Der grösste Hebel ist, die stehenden Regeln ganz aus dem Prompt zu nehmen: Schreib deinen Stack, deine Konventionen und dein Quality Gate in eine CLAUDE.md oder AGENTS.md, damit jeder Prompt von deinen Regeln startet und der Prompt selbst nur die Aufgabe tragen muss. Die Patterns unten setzen dieses Fundament voraus und konzentrieren sich auf den Auftrag pro Aufgabe. - Der Agent handelt: Er editiert Dateien und führt Befehle aus, also wird vage Absicht zu falschen Änderungen, nicht nur zu einem falschen Satz. - Stehende Regeln gehören in CLAUDE.md oder AGENTS.md, nicht in jeden Prompt; siehe How to Use Claude Code. - Ein guter Prompt pro Aufgabe trägt Absicht, Constraints und eine prüfbare Definition von "fertig". - Kontext ist endlich: Ein fokussierter Prompt lässt dem Agenten Platz, Code zu lesen und zu denken. Siehe das Glossar zum Context Window. ## Pattern 1: Rolle und Spec Der verlässlichste Einstieg ist, die Rolle zu nennen, die der Agent annehmen soll, und dann die Aufgabe als enge, testbare Spec statt als Wunsch zu spezifizieren. Eine Spec nennt das Ziel, die Constraints, die Dateien oder den Bereich im Scope und die Akzeptanzkriterien, die entscheiden, wann es fertig ist. "Mach den Login besser" ist ein Wunsch; die Version unten ist eine Spec. Die Rollen-Zeile fokussiert das Modell (ein Senior Engineer reviewt anders als ein Tutor), und die Akzeptanzkriterien geben dem Agenten etwas Konkretes zum Verifizieren, was ihn davon abhält, zu früh den Sieg zu erklären. Halte die Spec auf das Wesentliche: Jede Zeile überzuspezifizieren nimmt dem Agenten die Fähigkeit, gute lokale Entscheidungen zu treffen. ```markdown Role: act as a senior backend engineer on this codebase. Goal: add rate limiting to the public /api/contact endpoint. Constraints: - Use the existing Convex rate-limit helper; do not add a new dependency. - Limit to 5 requests per minute per IP. Return 429 with a clear JSON body. - Touch only the contact route and its test; leave other endpoints alone. Done when: - A new test proves the 6th request in a minute gets a 429. - `bun run lint && bun run typecheck && bun run test` all pass. Plan first (do not edit yet), show me the plan, and wait for my go-ahead. ``` Das Rolle-und-Spec-Pattern: eine Rolle, ein Ziel, explizite Constraints und Akzeptanzkriterien, gegen die der Agent prüfen kann. ## Pattern 2: zeig ein Beispiel (Few-Shot) Modelle matchen Muster, also ist der schnellste Weg zu Output in der gewünschten Form, eines zu zeigen. Wenn du eine neue Datei, Komponente, einen Test oder eine Migration brauchst, die wie die schon vorhandenen aussehen soll, zeig dem Agenten ein bestehendes Beispiel und bitte ihn, derselben Struktur zu folgen: "Schreib den neuen Endpoint genauso wie src/api/users.ts, inklusive Test-Datei." Dieses Few-Shot-Pattern funktioniert, weil deine Codebasis der beste Style Guide ist, den du hast, und es schlägt das Beschreiben deiner Konventionen in Prosa. Für Output, auf den du nicht zeigen kannst, gib ein winziges Inline-Beispiel des erwarteten Formats (eine Beispiel-Logzeile, eine JSON-Form, einen Commit-Message-Stil), damit der Agent ein Ziel zum Matchen hat. - Zeig auf eine bestehende Datei: "Folge der Struktur von src/api/users.ts und ihrem Test." - Deine Codebasis ist dein Style Guide; ein Beispiel schlägt einen Absatz Konventionen. - Für neue Formate inline ein winziges Sample des exakten Outputs (eine Logzeile, eine JSON-Form). - Ein scharfes Beispiel übertrifft meist mehrere vage Anweisungen. ## Pattern 3: grosse Arbeit in Schritte zerlegen Grosse, vage Anfragen sind, wo Agenten abdriften: Aufgefordert, "das Dashboard zu bauen", treffen sie hundert Entscheidungen, die du anders getroffen hättest, und vergraben die Fehler in einem riesigen Diff. Die Lösung ist Decomposition. Entweder zerlegst du die Arbeit selbst in eine Sequenz kleiner, separat reviewbarer Aufgaben, oder du bittest den Agenten, zuerst einen Plan vorzuschlagen, und gibst ihn frei, bevor Code geschrieben wird. Plan-First ist die wirkungsvollste Gewohnheit mit Coding Agents: Eine falsche Richtung, im Plan abgefangen, kostet nichts, während derselbe Fehler nach einem tausendzeiligen Diff echte Zeit kostet. In Claude Code ist das der Plan-Modus (Shift+Tab); in jedem Agenten kannst du einfach anweisen "plan first, do not edit, show me the steps". Dann implementiere einen Schritt, reviewe, und geh zum nächsten. - Teile eine grosse Aufgabe in kleine, separat reviewbare Schritte statt einen Mega-Prompt. - Bitte um einen Plan vor den Edits; einen Plan zu korrigieren ist gratis, einen riesigen Diff nicht. - Implementiere einen Schritt, reviewe den Diff, dann mach weiter; halte jede Änderung lesbar klein. - Kleinere Schritte halten auch das Context Window sauber, sodass der Agent über die Aufgabe scharf bleibt. ## Pattern 4: einen Verification Loop bauen Das definierende Merkmal eines Coding Agents ist, dass er Dinge ausführen kann, also sagen die besten Prompts ihm, wie er seine eigene Arbeit prüft und weitermacht, bis die Prüfung besteht. Statt "fix den fehlschlagenden Test" sag "führe die Test-Suite aus, fix, was rot ist, und führe sie wieder aus; hör nicht auf, bis sie grün ist". Statt darauf zu vertrauen, dass eine Änderung funktioniert, sag dem Agenten, er soll den Type-Checker, den Linter und die Tests laufen lassen und den tatsächlichen Output lesen statt anzunehmen. Das macht aus dem Agenten statt einem One-Shot-Generator einen geschlossenen Loop, der sich in echten Ergebnissen verankert. Die stärkste Version backt den Loop in dein Projekt ein, sodass er nicht mal ein Prompt ist: Hooks, die dein Gate automatisch laufen lassen (siehe den Claude Code Hooks Guide), bedeuten, dass der Agent an den Standard gehalten wird, egal ob du daran denkst zu fragen. - Bitte den Agenten, das Gate (Types, Lint, Tests) laufen zu lassen und den echten Output zu lesen, nicht anzunehmen. - Lass ihn iterieren: "fix und führe erneut aus, bis die Suite grün ist", nicht einen einzelnen Durchlauf. - Für UI oder Verhalten lass ihn den Dev-Server oder einen Playwright-Check laufen, damit er das echte Ergebnis sieht. - Automatisiere den Loop mit Hooks, sodass Verifikation jedes Mal passiert, nicht nur wenn du dran denkst. ## Pattern 5: gib dem Agenten den richtigen Kontext, nicht allen Agenten scheitern öfter an fehlendem Kontext als an einem schwachen Modell: Aufgefordert, eine API ohne ihre Docs zu nutzen, raten sie. Also bring dem Agenten, was er braucht, bewusst. Zeig auf die relevanten Dateien, füg den Fehler vollständig ein, verlink die Doku, nenn die exakte Funktion. Aber widersteh der gegenteiligen Falle, alles abzuladen: Ein Context Window vollgestopft mit zwanzig Dateien und einer langen Historie verschlechtert die Qualität, weil das Modell das wichtige Detail im Rauschen verliert (der "Lost in the Middle"-Effekt). Die Kunst ist Kuratierung: genug Kontext zum Gelingen, wenig genug, um scharf zu bleiben. Das ist der Kern des Context Engineering, und unser Context-Engineering-Guide geht tief auf das Managen des Windows über eine lange Aufgabe ein. - Nenn die exakten Dateien, füg den vollständigen Fehler ein und verlink die Doku, die der Agent braucht. - Lad nicht das ganze Repo ab; relevanter Kontext schlägt maximalen Kontext jedes Mal. - Achte auf "Lost in the Middle": ein Schlüssel-Detail in einem riesigen Prompt vergraben wird ignoriert. - Siehe den Context-Engineering-Guide und das Glossar zum Context Window und System Prompt. ## Anti-Patterns, die du vermeidest Der meiste Prompting-Schmerz kommt aus einer kurzen Liste wiederholbarer Fehler. Sie zu benennen macht sie in den eigenen Gewohnheiten leicht zu erkennen. Die Heilung für jeden ist ein Pattern von oben: sei spezifisch, zeig ein Beispiel, zerlege, verifiziere und kuratiere den Kontext. - Vage Wünsche: "mach es besser" gibt dem Agenten nichts zum Verifizieren. Nenn eine Spec und Akzeptanzkriterien. - Der Mega-Prompt: eine riesige Anfrage, die hundert Entscheidungen in einem nicht reviewbaren Diff vergräbt. Zerlege und plane zuerst. - Vertrauen ohne Verifikation: Output annehmen, den du den Agenten nicht testen liessest. Bau einen Verification Loop. - Context Dumping: alles einfügen, sodass das Signal ertrinkt. Kuratiere auf das, was die Aufgabe braucht. - Regeln jede Runde neu tippen: Stack und Konventionen gehören in CLAUDE.md oder AGENTS.md, nicht in jeden Prompt. - Höflichkeit als Anweisung: "bitte versuch vielleicht" liest sich als optional. Sei direkt; Constraints sind Regeln, keine Vorschläge. ## Häufige Fragen ### Wie sollte ich einen Coding Agent wie Claude Code prompten? Nenn die Rolle, gib eine enge Spec mit expliziten Constraints und Akzeptanzkriterien, bitte den Agenten, vor dem Editieren zu planen, zeig auf die exakten Dateien und Docs, die er braucht, und sag ihm, er soll deine Tests laufen lassen und fixen, bis sie bestehen. Halte stehende Regeln in einer CLAUDE.md, damit jeder Prompt nur die Aufgabe trägt. ### Was ist das wichtigste Prompt Pattern fuer Coding Agents? Planen, bevor du editierst. Den Agenten zu bitten, seinen Ansatz vorzuschlagen und freizugeben, bevor Code geschrieben wird, fängt eine falsche Richtung ab, solange sie gratis zu beheben ist, während derselbe Fehler nach einem grossen Diff teuer ist. Kombiniere es mit einem Verification Loop, sodass der Agent dein Gate laufen lässt und iteriert, bis es besteht. ### Sollen meine Coding-Konventionen in den Prompt oder in eine Config-Datei? In eine Config-Datei. Stehende Regeln wie dein Stack, deine Konventionen und dein Quality Gate gehören in eine CLAUDE.md (Claude Code) oder AGENTS.md (Codex CLI), sodass jede Session von ihnen startet. Sie in jedem Prompt neu zu tippen verschwendet Kontext und ist leicht zu vergessen. Der Prompt sollte nur die spezifische Aufgabe tragen. ### Warum ignoriert mein Coding Agent einen Teil meiner Anweisungen? Meist aus einem von drei Gründen: Der Prompt war zu lang und die Schlüssel-Anweisung ging in der Mitte verloren, die Anweisung las sich als optional statt als harte Constraint, oder es gab kein Akzeptanzkriterium zum Prüfen. Kuratiere den Kontext, formuliere Constraints als Regeln und gib dem Agenten etwas Konkretes zum Verifizieren. ### Wie verhindere ich, dass ein Coding Agent zu viele Änderungen auf einmal macht? Zerlege die Arbeit. Teile eine grosse Anfrage in kleine, separat reviewbare Schritte, oder bitte den Agenten, zuerst zu planen und den Plan freizugeben, bevor er editiert. Implementiere einen Schritt, reviewe den Diff, dann mach weiter. Kleinere Schritte sind leichter zu verifizieren und halten das Context Window sauber. ### Was ist Few-Shot-Prompting fuer Code? Es ist, dem Agenten ein Beispiel des gewünschten Outputs zu zeigen, damit er das Muster matcht. Für Code ist das beste Beispiel meist eines, das schon in deinem Repo ist: Sag dem Agenten, er soll der Struktur einer bestehenden Datei und ihrem Test folgen. Deine Codebasis ist der genaueste Style Guide, den du ihm geben kannst.