Viele nutzen Codex wie einen normalen Chat – und wundern sich später über unklare Änderungen, große Diffs oder kaputte Abläufe. In echten Projekten entscheidet nicht der eine perfekte Prompt, sondern ein sauberer Workflow aus Projektregeln, Kontext, Reviews, Tests und klaren Grenzen.
Viele reden über KI-Coding so, als würde alles am perfekten Prompt hängen. Als gäbe es diesen einen Satz, der dafür sorgt, dass Codex sofort das Projekt versteht, die richtigen Dateien findet, nichts kaputtmacht, sauber testet und am Ende einen perfekten Diff liefert.
Das klingt gut. In echten Projekten ist es aber zu kurz gedacht.
Codex ist nicht einfach nur ein Chatfenster, in das man schreibt: „Bau mir mal Feature X.“ Codex ist ein Coding-Agent, der direkt an einem Projekt arbeiten kann – je nach Umgebung im Terminal, in der IDE, in der App oder über Cloud- beziehungsweise Web-Workflows.
Genau deshalb ist Codex nicht nur eine Prompt-Frage. Es ist eine Workflow-Frage.
Der typische Fehler: Codex wie einen normalen Chat behandeln
Viele starten mit Codex wie mit einem normalen KI-Chat. Man beschreibt grob, was gebaut werden soll, wartet auf das Ergebnis und schaut sich danach an, was passiert ist.
Am Anfang wirkt das beeindruckend. Codex liest Dateien, schreibt Code, ergänzt Komponenten, verschiebt Logik, passt Tests an oder schlägt neue Strukturen vor. Der Diff sieht nach Fortschritt aus.
Und dann schaut man genauer hin.
Eine Datei wurde geändert, die mit der eigentlichen Aufgabe kaum etwas zu tun hatte. Eine neue Hilfsfunktion wurde gebaut, obwohl es schon ein bestehendes Muster gab. Ein Test wurde nicht angepasst. Ein Build wurde nicht ausgeführt. Oder Codex sagt „fertig“, aber es ist nicht klar, was wirklich geprüft wurde.
Das ist der Moment, in dem viele denken: KI-Coding ist spannend, aber irgendwie auch gefährlich.
Ich glaube: Das Problem ist oft nicht Codex selbst. Das Problem ist, dass Codex ohne sauberen Rahmen arbeitet.
Schneller Output ist nicht automatisch sauberer Output
Codex kann sehr schnell sehr viel schaffen. Aber schnell ist nicht automatisch sauber.
Wie bei einem echten Entwickler braucht es Kontext, Projektregeln, Grenzen und einen vernünftigen Ablauf. Der Unterschied ist nur: Codex produziert in wenigen Minuten so viel Output, dass ein schlechter Rahmen auch sehr schnell sichtbar wird.
Wenn die Aufgabe unklar ist, wird der Diff schnell größer als nötig. Wenn Projektregeln fehlen, entstehen Stilbrüche. Wenn keine Grenzen gesetzt sind, werden Nebenbaustellen geöffnet. Wenn keine Checks laufen, entsteht falsche Sicherheit. Wenn kein Review folgt, merkt man Fehler oft erst später.
Codex nimmt einem also nicht das Denken ab. Es kann aber sehr viel Arbeit abnehmen, wenn man vorher weiß, was man eigentlich will.
Was viele Anleitungen überspringen
Viele Codex-Erklärungen fangen direkt bei Prompts, Modellen oder AGENTS.md an. Das ist nicht falsch, aber oft fehlt der praktische Anfang.
Wichtige Fragen sind zum Beispiel:
Wo starte ich Codex überhaupt?
Arbeite ich im Terminal, in der IDE oder in der App?
In welchem Projektordner läuft Codex?
Welche Dateien darf Codex ändern?
Welche Befehle darf Codex ausführen?
Welche Tests gehören zu diesem Projekt?
Was darf niemals automatisch passieren?
Wann brauche ich ein Review?
Wann muss Codex stoppen und nachfragen?
Was gehört dauerhaft in Projektregeln und was nur in den aktuellen Prompt?
Genau diese Fragen entscheiden in der Praxis darüber, ob Codex hilfreich wird oder ob man am Ende nur einen riesigen Diff sortiert.
Codex sollte im richtigen Projektkontext starten
Ein vermeintlich kleiner Punkt ist in der Praxis sehr wichtig: Codex sollte dort gestartet werden, wo das Projekt wirklich liegt.
Nicht irgendwo im Home-Verzeichnis. Nicht im falschen Parent-Ordner. Nicht in einem alten Clone. Nicht in einer Umgebung, in der wichtige Tools fehlen.
Der Arbeitsordner entscheidet, welche Dateien Codex sieht, welche Projektregeln greifen und in welchem Kontext gearbeitet wird.
Gerade auf Windows sollte man außerdem bewusst entscheiden, ob man nativ, über PowerShell, in WSL, über eine IDE oder über eine App arbeitet. Viele Probleme entstehen nicht durch Codex selbst, sondern durch falsche Pfade, falsche Shells, fehlende Abhängigkeiten oder eine nicht passende Entwicklungsumgebung.
Der Prompt muss nicht immer direkt in Codex entstehen
Ein Punkt wird oft unterschätzt: Der perfekte Codex-Prompt muss nicht im Terminal entstehen.
Gerade bei größeren Aufgaben kann es sinnvoll sein, vorher in einem normalen Chat die Aufgabe zu sortieren. Dort kann man Risiken klären, den nächsten Schritt planen, Grenzen formulieren und daraus einen sauberen Codex-Prompt machen.
Das ist keine Schwäche. Das ist ein guter Arbeitsablauf.
Man kann es so sehen:
Codex ist der Arbeiter im Projekt.
Der Chat ist der Sparringspartner zum Denken.
Die IDE zeigt den Code.
Git zeigt den Diff.
Tests und Reviews sichern das Ergebnis ab.
Für kleine Änderungen reicht ein direkter Prompt in Codex oft völlig aus. Wenn es aber um Architektur, Auth, Datenbank, Deployment, größere Refactors oder schwer nachvollziehbare Fehler geht, lohnt sich ein Planungsschritt vorher fast immer.
Ein praktischer Ablauf kann so aussehen:
Problem oder Ziel beschreiben.
Risiken und Grenzen klären.
Daraus einen sauberen Codex-Prompt erstellen.
Codex im Projekt arbeiten lassen.
Ergebnis prüfen.
Review durchführen.
Erst danach committen oder den nächsten Block planen.
Das wirkt im ersten Moment länger. In der Praxis spart es oft genau die Zeit, die man sonst später mit Aufräumen verbringt.
AGENTS.md: Projektregeln statt jedes Mal alles neu erklären
Eine AGENTS.md ist einer der wichtigsten Bausteine für saubere Codex-Arbeit.
Darin stehen dauerhafte Projektregeln: Arbeitsweise, Grenzen, No-Gos, Testverhalten, Sicherheitsvorgaben und Erwartungen an Abschlussberichte.
Nicht hilfreich sind allgemeine Sätze wie:
„Schreibe sauberen Code.“
Das klingt gut, ist aber zu ungenau.
Besser sind konkrete Regeln:
Arbeite minimal-invasiv.
Ändere nur Dateien, die für die aktuelle Aufgabe nötig sind.
Suche zuerst bestehende Muster, bevor du neue Strukturen baust.
Keine neuen Dependencies ohne ausdrückliche Begründung.
Keine Produktionsdeploys ohne Freigabe.
Keine .env-Dateien ausgeben, kopieren oder committen.
Wenn Tests oder Builds nicht laufen können, ehrlich melden.
Am Ende immer geänderte Dateien, Checks und offene Punkte nennen.
Dauerhafte Regeln gehören in die AGENTS.md. Die konkrete Aufgabe gehört in den Prompt.
So muss man Codex nicht jedes Mal das ganze Projekt neu erklären.
Modelle, Reviews und klare Grenzen
Nicht jede Aufgabe braucht dasselbe Setup.
Für kleine Textkorrekturen, einfache UI-Fixes, Doku oder kleine Umbenennungen reicht oft ein schnelleres Setup. Für normale Feature-Arbeit ist ein gutes Standardmodell mit mittlerem Reasoning sinnvoll. Für Architektur, Auth, Security, Datenbankmigrationen, schwierige Bugs oder große Refactors sollte man ein stärkeres Modell mit höherem Reasoning verwenden.
Auch Reviews sollten nicht nebenbei behandelt werden. Ein guter Review braucht Konzentration und klare Grenzen.
Der wichtigste Punkt ist nicht, immer das stärkste Modell zu nehmen. Der wichtigste Punkt ist, die Aufgabe richtig einzuordnen.
Wer jede Mini-Änderung mit maximalem Aufwand fährt, verbrennt unnötig Ressourcen. Wer Auth, Datenbank oder Architektur im falschen Sparmodus erledigen lässt, spart an der falschen Stelle.
In echten Projekten sollte Codex außerdem nicht einfach alles dürfen. Besonders bei Netzwerkzugriff, neuen Dependencies, Datenbankmigrationen, Auth-Änderungen, Produktionsdeploys, .env-Dateien oder größeren Löschaktionen sollte Codex stoppen und nachfragen.
Ein guter Workflow ist nicht:
„Codex darf alles und ich schaue am Ende mal.“
Ein guter Workflow ist eher:
„Codex darf im Projekt arbeiten, aber bei riskanten Aktionen muss es stoppen.“
Das ist keine übertriebene Vorsicht. Das ist Arbeitskontrolle.
Skills: Wiederkehrende Abläufe nicht jedes Mal neu erklären
Skills sind besonders spannend, wenn man Codex regelmäßig nutzt.
Ein Skill ist ein wiederverwendbarer Arbeitsablauf. Er kann Anweisungen, Skripte, Referenzen und projektspezifische Regeln enthalten. Damit muss man wiederkehrende Dinge nicht jedes Mal neu in den Prompt schreiben.
Typische Beispiele:
Dev-Check
Security-Review
Release-Prüfung
Doku-Sync
Migrationscheck
UI-Review
Testlücken-Analyse
Wenn man Codex dieselbe Arbeitsweise zum dritten Mal erklärt, gehört daraus wahrscheinlich ein Skill gebaut.
Skills sorgen nicht automatisch für Qualität. Aber sie helfen, wiederkehrende Arbeit konsistenter zu machen.
Reviews: Codex nicht nur bauen lassen
Viele lassen Codex nur Code schreiben. Das ist verschenkt.
Codex sollte auch prüfen.
Ein guter Review-Prompt ist nicht:
„Schau mal drüber.“
Besser ist:
„Prüfe die uncommitted Changes auf unnötige Refactors, Security-Risiken, fehlende Tests, Stilbrüche und mögliche Regressionen. Nimm keine Änderungen vor. Fasse die Ergebnisse nach Risiko zusammen.“
Der wichtigste Satz ist: Nimm keine Änderungen vor.
Wenn ich Review will, will ich zuerst Analyse. Reparieren kann danach ein eigener Schritt sein. Sonst vermischen sich Prüfung und Umsetzung, und am Ende ist nicht mehr klar, was eigentlich bewertet wurde.
Ein guter Codex-Lauf endet außerdem nicht mit „fertig“, sondern mit Nachweis:
Welche Dateien wurden geändert?
Was wurde geändert?
Welche Checks liefen?
Was konnte nicht geprüft werden?
Welche offenen Punkte bleiben?
Ein nicht gelaufener Test ist kein bestandener Test. Ein „sieht gut aus“ ist kein Review. Und wenn Codex nicht klar sagt, was nicht geprüft wurde, entsteht falsche Sicherheit.
Subagents, Hooks und MCP: Erst später sinnvoll
Subagents klingen zuerst nach Turbo: mehrere Agenten parallel, verschiedene Blickwinkel, schnelleres Ergebnis.
Das kann sinnvoll sein, aber nicht blind.
Sinnvoll sind Subagents besonders für Analyse, Exploration und Reviews. Zum Beispiel:
ein Agent prüft Security-Risiken
ein Agent prüft Testlücken
ein Agent prüft Wartbarkeit und Architektur
Danach werden die Ergebnisse zusammengeführt und priorisiert.
Schlecht wäre dagegen: Drei Agenten bauen gleichzeitig dasselbe Feature um.
Mehr Agenten bedeuten nicht automatisch mehr Qualität. Ohne klare Trennung bekommt man nur schnelleres Chaos.
Auch Hooks, Plugins und MCP können einen Codex-Workflow erweitern. Sie werden interessant, wenn Codex Kontext außerhalb des Repositories braucht oder bestimmte Prüfungen automatisch im Arbeitsprozess laufen sollen.
Zum Beispiel:
interne Dokumentation
Issue-Tracker
Design-Systeme
API-Dokumentation
Testdatenbank-Informationen
Preview- oder Browser-Kontext
Trotzdem sollte man damit nicht anfangen, bevor die Grundlagen sitzen.
Erst sauber installieren. Dann im richtigen Projektordner arbeiten. Dann AGENTS.md, Projektregeln, Sandbox, Freigaben und Reviews sauberziehen. Dann Skills für wiederkehrende Abläufe bauen. Und erst danach größere Integrationen einbinden.
Sonst entsteht ein beeindruckendes Setup, das in der Praxis mehr Komplexität als Nutzen bringt.
Typische Fehler, die man vermeiden sollte
Der erste Klassiker ist:
„Mach das schöner.“
Gerade bei UI-Code ist das gefährlich. Codex interpretiert dann vielleicht Farben, Abstände, Komponenten oder Layouts neu. Besser ist: Bestehenden Stil übernehmen. Nur Alignment und Spacing im betroffenen Bereich ändern. Keine neuen Designmuster.
Der zweite Klassiker ist:
„Refactor das mal kurz mit.“
Feature und Refactor sollten meistens getrennt bleiben. Wenn Codex Refactor-Bedarf sieht, soll es ihn als offenen Punkt nennen, aber nicht nebenbei das halbe Projekt anfassen.
Der dritte Klassiker ist:
„Mach alles in einem Lauf.“
Große Aufgaben sollten geschnitten werden: Analyse, Plan, Umsetzung, Checks, Review, nächster Block. Ein riesiger Prompt erzeugt oft einen riesigen Diff. Und ein riesiger Diff ist schwer zu prüfen.
Der vierte Klassiker ist:
„Tests später.“
Tests später heißt oft: nie. Besser ist, relevante Tests direkt anzupassen oder klar erklären zu lassen, warum keine Tests betroffen sind.
Der fünfte Klassiker ist die Annahme, Codex werde schon wissen, was Dev, Staging und Prod bedeuten.
Nein. Das muss ausdrücklich im Projektkontext stehen.
Fazit
Codex ist stark, aber nicht, weil es den einen magischen Prompt gibt.
Codex wird stark, wenn der Workflow stimmt.
Dazu gehören:
sauberer Projektkontext
klare AGENTS.md
gute Prompts
bewusste Grenzen
passende Modellwahl
Reviews
Git-Diffs
Tests
ehrliche Abschlussberichte
kleine, kontrollierte Arbeitsschritte
Der beste Codex-Prompt ist nicht:
„Bau mir das.“
Sondern eher:
„Prüfe zuerst den Kontext. Halte dich an die Projektregeln. Ändere nur das Nötige. Nutze bestehende Muster. Führe passende Checks aus. Sag am Ende ehrlich, was du getan hast und was offen bleibt.“
Das ist weniger spektakulär als „10 geheime KI-Hacks“.
Aber genau so wird Codex vom Spielzeug zum Werkzeug.
Persönliche Einschätzung
Ich glaube, viele unterschätzen bei Codex genau diesen Punkt:
Es geht nicht darum, der KI möglichst viel Arbeit hinzuschmeißen und zu hoffen, dass am Ende schon etwas Gutes herauskommt.
So funktioniert es vielleicht bei kleinen Tests. Aber nicht in echten Projekten.
Für mich ist Codex eher wie ein sehr schneller Entwickler, der gute Vorgaben braucht. Wenn man ihm Chaos gibt, bekommt man sehr schnell sehr viel Chaos zurück. Wenn man ihm aber einen sauberen Rahmen gibt, kann er richtig stark werden.
Nicht perfekt. Nicht magisch. Aber stark.
Gerade dieses Zusammenspiel aus Projektregeln, guten Prompts, Reviews, Git-Diffs, Tests und ehrlichem Nacharbeiten macht den Unterschied. Codex nimmt einem nicht das Denken ab. Aber es kann enorm viel Arbeit abnehmen, wenn man vorher weiß, was man eigentlich will.
Ich sehe Codex deshalb nicht als Spielzeug und auch nicht als „mach mal alles für mich“-Knopf. Eher als Werkzeug für Menschen, die wirklich an Projekten arbeiten und bereit sind, ihren Workflow sauber aufzubauen.
Andere Coding-Agenten und lokale Agenten-Systeme gehen in eine ähnliche Richtung. Entscheidend ist dabei nicht die Hype-Frage, welches Tool gerade am lautesten wirkt.
Entscheidend ist die praktische Frage:
Was funktioniert in echten Projekten wirklich – und was sieht nur in Demos gut aus?
Kommentare
Moderierte Rückmeldungen
Kommentare erscheinen erst nach Prüfung. E-Mail-Adressen werden nicht veröffentlicht.