Ich arbeite seit einiger Zeit mit codex.agent beim Programmieren. Das Tempo ist hoch, die Trefferquote oft gut – aber es gibt wiederkehrende Muster, die mich Zeit kosten und im schlimmsten Fall neue Fehler in den Code tragen.

Vier Probleme sind bei mir immer wieder aufgetaucht:

Codex neigt zu Overengineering. Aus einer kleinen Änderung wird schnell ein Umbau, neue Abstraktionsschichten entstehen „vorsorglich“, und am Ende ist der Diff größer als nötig.

Außerdem werden Fehler häufig am Ende der Kette repariert: Das Symptom wird ruhiggestellt, aber die erste Ursache bleibt bestehen. Das produziert Folgefehler, die später an anderen Stellen wieder hochkommen.

Drittes Thema: PHP-Striktheit. Ohne harte Leitplanken entstehen implizite Typkonvertierungen, unscharfe Nullability, fehlende Return-Typen oder Kontrollflüsse, die in PHP zwar „irgendwie laufen“, aber wartungsfeindlich sind.

Und schließlich Härtung und Regressionen: Wenn Eingaben nicht sauber validiert werden oder Grenzfälle ignoriert werden, kann die Änderung zwar „grün“ wirken, aber still neue Fehler erzeugen – gerade dann, wenn kein Testnetz vorhanden ist.

Irgendwann war klar: Das ist kein „Codex ist schlecht“-Problem, sondern ein Steuerungsproblem. Ein Agent liefert, was er für sinnvoll hält – und „sinnvoll“ ist ohne Constraints oft: größer, allgemeiner, abstrakter. Was fehlte, war ein wiederholbarer Rahmen, der Overengineering begrenzt, Root-Cause-Fixing erzwingt, Striktheit lokal erhöht und Regressionen sichtbar macht.

Daraus ist ein Prompt entstanden, den ich inzwischen wie einen Vorspann vor Aufgaben setze. Ich nenne ihn „Zauberprompt“, weil er die Qualität der Ergebnisse erstaunlich zuverlässig in die Richtung drückt, die ich im Backend-Alltag brauche: minimal-invasiv, robust, nachvollziehbar.

Der Zauberprompt (Steuer-Anweisung)

Der Prompt ist so gebaut, dass der Agent nicht nur „irgendwas“ fixt, sondern nach einem festen Debug- und Review-Prozess arbeitet: Reproduzieren, Root Cause finden, minimal fixen, strikter machen, härten, Regressionen absichern, Self-Check. Zusätzlich zwingt das Output-Format zu einem Patch/Diff und zu einer Verifikation.

Act like a principal PHP engineer (Backend), Security-minded code reviewer und pragmatischer Debugger.

Ziel: Liefere eine minimal-invasive, robuste Änderung im bestehenden PHP-Code, die das eigentliche Problem (Root Cause) behebt, den Code strikter macht und neue Fehler/Regressionen verhindert. Keine Overengineering-Lösungen.

Aufgabe (vom User wird gleich beschrieben): Implementiere exakt die angeforderte Änderung und behebe alle dabei auftretenden Fehler nachhaltig.

Vorgehen (verpflichtend, in dieser Reihenfolge):
1) Reproduktion: Identifiziere den konkreten Failure (Fehlermeldung, Stacktrace, Test, Log). Stelle sicher, dass du den Fehler zuverlässig auslösen kannst (oder erkläre präzise, welche Inputs/Umstände dafür nötig sind).
2) Root-Cause-Analyse: Verfolge den Fehler zur ersten Ursache (nicht nur das letzte Symptom). Fixe bevorzugt die Quelle (Invariante/Vertrag verletzt? falscher Typ? unvalidierter Input? Nebenwirkung?).
3) Minimaler Fix: Ändere so wenig wie möglich. Keine neuen Architekturen, keine neuen Layer, keine “Future-proofing”-Refactors. Keine neuen Dependencies ohne explizite Anforderung.
4) PHP-Striktheit: Wo sinnvoll und lokal möglich: declare(strict_types=1); klare Typen (Parameter/Returns), defensive Nullability, Exceptions statt stiller Fehler. Vermeide implizite Typ-Jonglage.
5) Härtung: Validiere externe Inputs, sichere Datenbankzugriffe (prepared statements), sichere Output-Kontexte (XSS), sauberes Error-Handling (keine Informationsleaks), Grenzfälle (empty, null, unicode, große Zahlen).
6) Regression-Schutz: Ergänze/aktualisiere Tests (mindestens: ein Test, der vorher fehlschlug und jetzt grün ist). Wenn Tests nicht verfügbar sind: baue eine minimale reproduzierbare Prüffunktion/Script und dokumentiere die Ausführung.
7) Self-Check: Prüfe kurz auf neue Warnungen/Fehlerquellen (unreachable code, falsche Annahmen, Nebenwirkungen, BC-breaks). Wenn du Annahmen triffst, liste sie explizit.

Output-Format:
- Kurzüberblick (max. 5 Bullets): What changed / Where / Why (Root Cause) / Risks / Next steps
- Patch/Diff (nur relevante Dateien)
- Tests: Wie verifiziert (Befehl/Schritte) + erwartetes Ergebnis
- Offene Risiken/Unsicherheiten (falls vorhanden, knapp)

Take a deep breath and work on this problem step-by-step.

Unter der Haube

Der Kern ist nicht „mehr Text“, sondern Prozesszwang.

Reproduktion am Anfang verhindert, dass der Agent sofort in den Lösungsmodus springt, ohne das Problem wirklich zu greifen. Gerade bei PHP-Fehlern, die nur unter bestimmten Inputs auftreten, ist dieser Schritt der Unterschied zwischen Symptombehandlung und belastbarem Fix.

Root-Cause-Analyse zwingt dazu, den Fehler bis zur ersten verletzten Annahme zurückzuverfolgen: falscher Typ an einer Schnittstelle, unvalidierter Input, implizite Konvertierung, Nebenwirkung durch Shared State. Genau hier entsteht in meinen Projekten der größte Hebel, weil danach meist mehrere spätere Folgefehler verschwinden.

Der Abschnitt „Minimaler Fix“ ist die Anti-Overengineering-Bremse. Er nimmt dem Agenten die Freiheit, aus einer Bugfix-Aufgabe eine Architekturübung zu machen. Das Ergebnis sind kleinere Diffs, weniger Moving Parts, weniger Angriffsfläche.

„PHP-Striktheit“ sorgt dafür, dass Verbesserungen lokal und konkret passieren: strict_types, klare Signaturen, explizite Nullability, Exceptions statt stillem Weiterlaufen. Der Code wird nicht „schöner“, sondern weniger interpretierbar – und damit stabiler.

„Härtung“ und „Regression-Schutz“ sind der zweite große Hebel. Viele Agenten liefern Code, der auf den Happy Path optimiert ist. Dieser Prompt verlangt explizit Grenzfälle und eine Form von Verifikation. Wenn Tests existieren: gut. Wenn nicht: Dann wenigstens ein minimales reproduzierbares Script, das vorher rot war und jetzt grün ist. Damit werden stille Regressionen deutlich seltener.

Der „Self-Check“ am Ende ist eine kurze Qualitätsbarriere: neue Warnungen, falsche Annahmen, Nebenwirkungen, mögliche BC-Breaks (Backward Compatibility Breaks). Das ist keine Formalität; es zwingt den Agenten, kurz gegen den eigenen Output zu arbeiten.

Was sich bei mir konkret verbessert hat

Seit ich Aufgaben mit diesem Vorspann an codex.agent übergebe, sind die typischen Ausreißer seltener: weniger unnötige Abstraktionen, weniger „Fix am letzten Symptom“, spürbar mehr strikte Signaturen und deutlich öfter ein expliziter Verifikationsschritt statt „sollte funktionieren“. Vor allem aber ist der Output besser prüfbar: Patch/Diff, knapper Überblick, und ein klarer Bezug auf Root Cause statt nur „Fehler weg“.

Das ist kein Ersatz für eigenes Denken und keinen Review-Prozess – aber es ist ein sehr effektiver Filter, der den Agenten in einen Modus bringt, der im Backend-Alltag zählt: kleine Änderungen, klare Ursachen, stabile Ränder.