Coding Agent Prompting 2026: ein Prompt, zwei Ergebnisse

Phillip Pham, AI Developer bei Pexon Consulting | 7 Min. Lesezeit | 28.08.2026

TL;DR

Coding Agent Prompting unterscheidet sich je Agent, weil jeder einen eigenen Systemprompt und eine eigene Konfigurationsdatei mitbringt. Codex arbeitet Aufträge bis zum Ende durch, Claude Code hält sich eng an den Auftragsrahmen. Derselbe Prompt liefert deshalb systematisch verschiedene Ergebnisse. Wer das ignoriert, bezahlt die Differenz in Laufzeit.

Das Problem: der Prompt ist identisch, das Ergebnis nicht

Ein Team gibt zwei Coding-Agenten denselben Auftrag. Der eine liefert nach einer Stunde ein fokussiertes Ergebnis. Der andere läuft einen halben Tag, baut deutlich mehr und trifft den Kern trotzdem schlechter.

Die naheliegende Erklärung ist, dass ein Agent besser ist. Sie stimmt selten.

Was tatsächlich passiert: Beide Agenten bekommen Ihren Prompt nicht direkt. Er landet hinter einem Systemprompt, den der Hersteller geschrieben hat, und der sagt dem Modell, wie es Aufträge überhaupt zu lesen hat. Diese Vorgabe ist bei jedem Agenten anders formuliert. Ihr Prompt trifft also nicht auf ein neutrales Modell, sondern auf eine bereits gesetzte Arbeitshaltung.

Was im Systemprompt tatsächlich steht

Die Systemprompts der gängigen Coding-Agenten sind öffentlich analysiert. Daniel Vaughan hat sie im April 2026 vermessen und die Auswertung zuletzt am 21. August 2026 aktualisiert. Die Größenordnungen:

Interessanter als die Länge sind die Anweisungen selbst. Codex bekommt mit auf den Weg, eine Aufgabe durchzuhalten, bis sie vollständig erledigt ist. Claude Code bekommt das Gegenteil: keine Funktionen ergänzen, nicht umbauen, keine Verbesserungen jenseits des Auftrags.

Das ist kein Detail. Das sind zwei entgegengesetzte Grundhaltungen, und sie erklären den größten Teil der Ergebnisunterschiede, die Teams dem Modell zuschreiben. In unserem AI-Engineering-Stack sitzt diese Vorgabe-Schicht zwischen Foundation Model und Anwendung.

Unsere Position dazu: Wer zwei Coding-Agenten vergleicht, ohne diese Vorgaben zu kennen, vergleicht nicht die Modelle. Er vergleicht zwei fremde Arbeitsanweisungen und hält das Ergebnis für eine Modelleigenschaft.

Zwei Prompt-Stile, die zu den Agenten passen

Aus dem Unterschied folgt eine praktische Regel, die sich in unserer täglichen Arbeit bewährt hat.

Für einen Agenten mit engem Auftragsrahmen formulieren Sie das Ziel und den Zustand, der am Ende gelten soll. Nicht den Weg. Der Agent hält sich ohnehin zurück, Sie müssen ihn nicht zusätzlich einschränken, sondern ihm sagen, wann er fertig ist.

Ziel: Der Rechnungs-Import verarbeitet auch PDFs ohne Textebene.

Fertig ist die Aufgabe, wenn:
- die vorhandenen Tests weiter durchlaufen
- ein Test mit einem gescannten PDF existiert und besteht
- die Fehlermeldung bei nicht lesbaren Dateien den Dateinamen nennt

Nicht anfassen: das Datenbankschema, die Endpunkt-Signaturen.

Für einen Agenten, der bis zur vollständigen Erledigung durchläuft, ist der Auftragsrahmen die eigentliche Arbeit. Ohne klare Grenze baut er weiter, und zwar so lange, wie Sie ihn lassen. Genau hier entstehen die teuren Läufe.

Schritt 1: Nur die Datei importer/pdf.py lesen und den aktuellen Ablauf beschreiben.
Schritt 2: Vorschlag für die OCR-Anbindung, noch kein Code.
Schritt 3: Nach meiner Freigabe umsetzen, nur innerhalb von importer/.
Schritt 4: Tests ergänzen, dann stoppen.

Nicht: neue Abhängigkeiten aufnehmen, Nachbarmodule umbauen, Konfiguration ändern.

Der zweite Stil sieht nach Bevormundung aus. Er ist der günstigere. Ein Agent, der ohne Grenze arbeitet, arbeitet nicht falsch, er arbeitet zu viel, und Sie bezahlen jede Runde.

Die Konfigurationsdatei ist der wichtigere Hebel

Prompts sind flüchtig. Was dauerhaft wirkt, steht in der Projektdatei, die der Agent bei jedem Start liest.

Hier gehören die Dinge hinein, die Sie nicht in jedem Prompt wiederholen wollen: Aufbau des Repositories, Build- und Testbefehle, Namenskonventionen und vor allem die dauerhaften Verbote.

# AGENTS.md

## Build und Test
- `make test` vor jedem Commit, nicht pytest direkt aufrufen
- Migrationen nur über `alembic revision --autogenerate`

## Dauerhafte Verbote
- Keine neuen Abhängigkeiten ohne Rücksprache
- `config/prod/` wird nie verändert
- Keine Secrets in Testdaten, auch keine erfundenen

## Konventionen
- Fehlermeldungen auf Deutsch, Log-Ausgaben auf Englisch
- Jede öffentliche Funktion braucht einen Typ-Hint

Wir empfehlen, beide Dateien zu pflegen, wenn im Team mehrere Agenten laufen. Der Inhalt ist zu 90 Prozent identisch, und die Alternative ist, dass die Hälfte des Teams ohne Leitplanken arbeitet.

Ein Hinweis, der Zeit spart: Diese Dateien blähen den Kontext auf. Bei Claude Code kommt die Projektdatei zur ohnehin dynamischen Grundlast hinzu. Eine 400-Zeilen-Konfigurationsdatei ist kein Zeichen von Sorgfalt, sondern ein Kostenposten in jedem einzelnen Lauf.

Was das kostet, wenn man es falsch macht

Wir haben zwei Agenten mit identischem Auftrag arbeiten lassen. Das Ergebnis war nicht, dass einer versagt hätte. Beide lieferten. Der Unterschied lag in Aufwand und Zuschnitt.

Zur Einordnung, damit die Tabelle nicht überinterpretiert wird: Das ist ein Auftrag, kein Benchmark. Und die breitere Variante war nicht schlechter, sie war gründlicher. Für sicherheitskritische Infrastruktur ist genau das die richtige Investition. Für einen Prototyp ist es Verschwendung.

Die brauchbare Kennzahl ist deshalb nicht der Token-Preis, sondern was die fertige Aufgabe insgesamt gekostet hat. Ein Agent, der viermal so viele Runden dreht, ist auch mit einem günstigen Modell teurer als ein präzise gesteuerter mit einem teuren.

Prompten hilft nicht gegen alles

Ein sauberer Prompt verbessert das Ergebnis. Er macht es nicht sicher.

Eine unabhängige Untersuchung von 522 Code-Beispielen aus sechs Sprachmodellen, erhoben im Februar 2026, fand in 25,7 Prozent des erzeugten Codes bestätigte Schwachstellen gegen die OWASP Top 10:2025. Die Spanne zwischen dem besten Modell (GPT-5.2 mit 19,5 Prozent) und den schwächsten (Claude Opus 4.6, DeepSeek V3 und Llama 4 Maverick mit je 29,9 Prozent) lag bei rund zehn Prozentpunkten.

Kein Prompt-Stil schließt diese Lücke. Was sie schließt, ist ein Prüfschritt, der nicht vom selben Agenten kommt, der den Code geschrieben hat. Sobald mehrere Agenten mit getrennten Rollen arbeiten, einer schreibt und einer prüft, wird daraus eine Frage der Orchestrierung mehrerer Agenten.

Dazu kommt der Aufwand, den kaum jemand einplant. Im Harness State of Engineering Excellence Report vom Mai 2026, für den 700 Engineering-Fachleute und Führungskräfte in fünf Ländern befragt wurden, gaben 81 Prozent an, inzwischen mehr Zeit mit manuellem Code-Review zu verbringen. Gemessen wird dieser Aufwand nur in 38 Prozent der Organisationen.

Fünf Regeln, die in beiden Welten funktionieren

1. Sagen Sie, wann fertig ist. Ein Abbruchkriterium ist wirksamer als jede Stilvorgabe. Ohne eines entscheidet der Systemprompt des Herstellers, und der kennt Ihr Projekt nicht.
2. Grenzen Sie negativ ab. Was der Agent nicht anfassen darf, ist konkreter formulierbar als das, was er tun soll, und verhindert mehr Schaden.
3. Dauerhaftes gehört in die Projektdatei. Was Sie zum dritten Mal in einen Prompt tippen, gehört in AGENTS.md oder CLAUDE.md.
4. Halten Sie die Projektdatei kurz. Sie wird bei jedem Lauf mitgelesen und kostet jedes Mal. Wir raten zu unter 150 Zeilen.
5. Trennen Sie Schreiben und Prüfen. Derselbe Agent, der den Code geschrieben hat, ist der schlechteste Prüfer dafür. Nutzen Sie einen anderen oder einen Menschen.

Häufig gestellte Fragen

Warum liefern zwei Coding-Agenten bei identischem Prompt verschiedene Ergebnisse?

Weil Ihr Prompt hinter einem herstellereigenen Systemprompt landet, der die Arbeitshaltung vorgibt. Codex wird angewiesen, Aufgaben bis zur vollständigen Erledigung durchzuhalten, Claude Code ausdrücklich, nichts über den Auftrag hinaus zu bauen. Diese Vorgaben sind gegensätzlich und wirken vor Ihrem Text.

Was ist der Unterschied zwischen AGENTS.md und CLAUDE.md?

Inhaltlich kaum etwas, formal die Reichweite. AGENTS.md wird von 25 und mehr Werkzeugen gelesen und hat sich als offener Standard etabliert. CLAUDE.md ist herstellergebunden. Wenn im Team mehrere Agenten laufen, pflegen Sie beide, der Inhalt ist ohnehin fast identisch.

Wie lang sollte eine Projektdatei für Coding-Agenten sein?

Kürzer als die meisten sind. Die Datei wird bei jedem Lauf in den Kontext geladen und kostet jedes Mal Tokens. Unsere Empfehlung liegt bei unter 150 Zeilen: Build- und Testbefehle, Konventionen, dauerhafte Verbote. Alles Erklärende gehört in die Dokumentation, nicht dorthin.

Macht besseres Prompting den erzeugten Code sicher?

Nein. In einer Untersuchung von 522 Code-Beispielen aus sechs Modellen enthielten 25,7 Prozent bestätigte Schwachstellen. Prompting verschiebt diese Quote, es beseitigt sie nicht. Verlässlich hilft nur ein Prüfschritt, der unabhängig vom schreibenden Agenten läuft.

Sollten wir uns auf einen Coding-Agenten festlegen?

Wir raten davon ab. Die Stärkenprofile unterscheiden sich deutlich, und der jeweilige Vorsprung hält selten eine Modellgeneration lang. Sinnvoller ist, die Steuerung so zu bauen, dass ein Wechsel eine Konfigurationsfrage bleibt: gepflegte Projektdateien, ein eigener Prüfschritt, klare Kostendeckel.

Nächster Schritt

Wenn bei Ihnen mehrere Entwickelnde mit Coding-Agenten arbeiten und jeder seinen eigenen Stil fährt, ist die Projektdatei der schnellste Hebel. Eine Stunde Arbeit, wirkt ab dem nächsten Lauf für alle.

Verwandte Themen