In den vergangenen Wochen habe ich mich intensiv mit dem OpenAI Codex Agent in Visual Studio Code beschäftigt. Genauer gesagt wollte ich nicht einfach nur herausfinden, wie gut GPT-5.3 Codex Code schreiben kann. Das können moderne Modelle inzwischen alle erstaunlich gut. Mich hat vielmehr interessiert, wie sich ein echter KI-Agent im täglichen Entwickleralltag verhält. Also dann, wenn man nicht nur eine einzelne Funktion erstellen lässt, sondern über Stunden oder sogar Tage gemeinsam an einem bestehenden Projekt arbeitet.

Als Modell kam bei mir GPT-5.3 Codex zum Einsatz, welches ich über Azure AI Foundry bereitgestellt habe. Dem Agenten hatte ich dabei Vollzugriff auf mein lokales Projekt gegeben. Er durfte Dateien lesen, verändern, neue Dateien anlegen und Werkzeuge eigenständig ausführen. Genau so, wie es ein Coding-Agent eben tun soll.

Und ganz ehrlich? Die ersten Tage waren beeindruckend.

Genau so habe ich mir einen KI-Agenten vorgestellt

Der Agent arbeitete sich eigenständig durch mein Projekt, analysierte den Aufbau der Anwendung und verstand erstaunlich schnell die Zusammenhänge zwischen Frontend, Backend und den verschiedenen Komponenten. Ich musste ihm nicht jede Datei einzeln zeigen oder erklären, wo sich welcher Code befindet. Stattdessen konnte ich ihm einfach ein Problem schildern und beobachten, wie er sich selbstständig auf die Suche nach der Ursache machte.

Noch beeindruckender war allerdings, dass er anschließend nicht nur erklärte, was geändert werden sollte.

Er änderte den Code tatsächlich.

Genau das unterscheidet einen KI-Agenten von einem klassischen Chatbot. Während ein Chatbot hauptsächlich Empfehlungen ausspricht, übernimmt ein Agent selbstständig Aufgaben. Er öffnet Dateien, passt Methoden an, legt neue Klassen an oder startet Tests. Genau dieses Verhalten konnte ich in den ersten Tagen immer wieder beobachten.

Ich erinnere mich noch an einen Fehler im Backend meines Projektes. Nachdem ich dem Agenten lediglich die Fehlermeldung beschrieben hatte, begann er eigenständig damit, verschiedene Dateien zu untersuchen. Er verfolgte die Ursache Schritt für Schritt, fand schließlich den eigentlichen Fehler und änderte anschließend mehrere Dateien, ohne dass ich ihn dazu einzeln auffordern musste. Anschließend führte er sogar noch Tests aus, um zu prüfen, ob die Änderungen das Problem tatsächlich behoben hatten.

Genau in solchen Momenten denkt man sich als Entwickler:

“Okay… genau so habe ich mir einen KI-Agenten vorgestellt.”

Mit jeder weiteren Unterhaltung wuchs mein Vertrauen in das System. Ich begann immer häufiger, den Agenten zunächst selbst analysieren zu lassen, bevor ich überhaupt in den Code schaute. Oft lag er richtig. Teilweise entdeckte er sogar Zusammenhänge, die ich selbst zunächst übersehen hatte.

Irgendwann änderte sich das Verhalten

Doch nach einigen längeren Entwicklungssitzungen bemerkte ich plötzlich eine Veränderung.

Nicht schlagartig.

Nicht nach einem Update.

Nicht nach einer Fehlermeldung.

Es war eher ein schleichender Prozess.

Je länger unsere Unterhaltung wurde, desto häufiger hatte ich das Gefühl, dass der Agent zwar weiterhin genau wusste, was zu tun war, den letzten Schritt aber plötzlich nicht mehr ausführte.

Zunächst schenkte ich dem keine große Aufmerksamkeit.

Ich beschrieb ein Problem.

Der Agent analysierte mein Projekt.

Er erklärte mir sehr detailliert, wodurch der Fehler verursacht wurde.

Anschließend schrieb er einen Satz wie:

„Ich habe den Fehler gefunden und setze die Änderung jetzt um.“

Ich wartete.

Aber nichts passierte.

Keine Datei wurde geändert.

Kein Tool wurde gestartet.

Keine Änderung erschien im Projekt.

Also fragte ich noch einmal nach.

Der Agent entschuldigte sich freundlich und antwortete sinngemäß:

„Du hast Recht. Ich führe die Änderung jetzt durch.“

Doch wieder passierte… nichts.

An diesem Punkt begann ich mich zu fragen, ob vielleicht irgendetwas mit meiner Umgebung nicht stimmte.

Hatte der Agent plötzlich keine Berechtigungen mehr?

War die Verbindung zu meinem lokalen Projekt unterbrochen?

Oder hatte ich versehentlich irgendeine Einstellung verändert?

Doch genau das war nicht der Fall.

Das Interessante war nämlich, dass der Agent weiterhin problemlos auf mein Projekt zugreifen konnte. Er öffnete Dateien, analysierte meinen Quellcode und erklärte mir bis ins Detail, warum ein Fehler entstanden war. Er wusste sogar ganz genau, welche Datei geändert werden musste und welche Methode angepasst werden sollte.

Nur die eigentliche Umsetzung fand nicht mehr statt.

Der Agent wusste die Lösung – handelte aber nicht mehr

Je länger ich darüber nachdachte, desto spannender wurde dieses Verhalten.

Denn offensichtlich fehlte dem Agenten weder Wissen noch Zugriff.

Er verstand das Problem.

Er kannte die Lösung.

Er hatte Zugriff auf sämtliche Dateien.

Und trotzdem blieb der eigentliche Werkzeugaufruf irgendwann einfach aus.

Meine ersten Experimente

Aus reiner Neugier begann ich anschließend ein wenig zu experimentieren.

Ich schrieb einfach nur:

go

Und plötzlich passierte etwas.

Der Agent öffnete wieder Dateien.

Er änderte Code.

Er führte seine Werkzeuge aus.

Der komplette Arbeitsablauf funktionierte wieder.

Natürlich hielt ich das zunächst für einen Zufall.

Also probierte ich weitere Begriffe aus.

“run tools”

“tool run”

“gogogo”

Und tatsächlich schien genau dieser zusätzliche Impuls den Agenten gelegentlich wieder dazu zu bringen, seine Werkzeuge tatsächlich auszuführen.

Das Kuriose daran war allerdings, dass dies keineswegs zuverlässig funktionierte. Mal genügte ein einfaches „go“, ein anderes Mal blieb der Agent trotzdem in seinem merkwürdigen Zustand. Es fühlte sich fast so an, als müsste man ihn manchmal daran erinnern, dass er eigentlich nicht nur analysieren, sondern auch handeln sollte.

Der Zufallstreffer: „Developer: Reload Window“

Der entscheidende Hinweis kam allerdings erst einige Tage später.

Während einer weiteren Sitzung blieb der Agent erneut in genau diesem Zustand hängen. Er erklärte ausführlich, welche Änderungen notwendig wären, kündigte deren Umsetzung an – und tat anschließend wieder nichts.

Aus Frust öffnete ich die Command Palette in Visual Studio Code.

STRG + SHIFT + P

Anschließend wählte ich den Eintrag:

Developer: Reload Window

Nach wenigen Sekunden war Visual Studio Code wieder einsatzbereit.

Ich stellte dem Agenten dieselbe Aufgabe erneut.

Und plötzlich war alles wieder wie am ersten Tag.

Er analysierte mein Projekt.

Er nutzte seine Werkzeuge.

Er änderte Dateien.

Er führte seine Aufgaben vollständig autonom aus.

Genau in diesem Moment wurde mir klar, dass ich vermutlich nicht auf ein Problem des Sprachmodells gestoßen war.

Wäre GPT-5.3 Codex selbst die Ursache gewesen, dürfte ein einfacher Reload der VS-Code-Oberfläche kaum einen solchen Effekt gehabt haben. Das Modell wurde dadurch schließlich nicht verändert. Auch meine Berechtigungen blieben unverändert. Der Agent hatte nach wie vor denselben Zugriff auf mein Projekt wie zuvor.

Also begann ich zu recherchieren

Also begann ich zu recherchieren.

Und tatsächlich stellte ich fest, dass ich mit dieser Beobachtung keineswegs alleine war.

In verschiedenen GitHub-Issues und Diskussionen berichten Entwickler von sehr ähnlichen Erfahrungen. Immer wieder ist dort von langen Agent-Sitzungen die Rede, bei denen sich das Verhalten des Codex Agenten verändert. Manche beschreiben, dass der Agent nach einer gewissen Zeit deutlich träger reagiert. Andere berichten davon, dass Aktionen angekündigt, anschließend aber nicht mehr ausgeführt werden. Wieder andere nennen als temporäre Lösung genau den Workaround, den ich ebenfalls entdeckt hatte: „Developer: Reload Window“.

Natürlich bedeutet das nicht automatisch, dass jeder identische Ursachen hat. Trotzdem fand ich es beruhigend zu sehen, dass dieses Verhalten offenbar kein Einzelfall ist.

Was könnte technisch dahinterstecken?

Je tiefer ich mich anschließend mit der technischen Architektur beschäftigt habe, desto plausibler erschien mir eine andere Erklärung.

Viele stellen sich einen KI-Agenten vereinfacht so vor:

Benutzer
    │
    ▼
GPT-5.3 Codex
    │
    ▼
Datei wird geändert

Tatsächlich besteht ein Agentensystem jedoch aus deutlich mehr Komponenten.

Visual Studio Code
        │
        ▼
Codex Extension
        │
        ▼
Agent Runtime
        │
        ▼
GPT-5.3 Codex
        │
        ▼
Lokale Tools
(Dateien, Terminal, Tests)

Das Sprachmodell selbst verändert also keine Dateien.

Es analysiert die Aufgabe, entwickelt einen Lösungsweg und entscheidet, welcher Werkzeugaufruf als Nächstes sinnvoll wäre.

Die eigentliche Ausführung übernimmt anschließend die Agent-Umgebung innerhalb von Visual Studio Code.

Genau dort vermute ich mittlerweile die eigentliche Ursache.

Während einer längeren Entwicklungssitzung entsteht eine enorme Menge an Zustandsinformationen. Der Agent merkt sich bereits untersuchte Dateien, frühere Tool-Ergebnisse, Änderungen am Projekt, offene Aufgaben, neue Anforderungen und den kompletten Gesprächsverlauf. All diese Informationen müssen während der gesamten Sitzung synchron gehalten werden.

Je länger eine Unterhaltung dauert, desto komplexer wird dieser interne Zustand.

Meine Vermutung ist deshalb, dass sich irgendwo innerhalb dieser Agent-Laufzeit ein Zustand aufbauen kann, bei dem die eigentliche Werkzeugausführung nicht mehr sauber angestoßen wird. Das Modell analysiert weiterhin korrekt, entwickelt weiterhin die richtige Lösung und formuliert sogar den nächsten Handlungsschritt. Nur die Übergabe an die eigentliche Tool-Ausführung scheint in manchen Situationen nicht mehr zuverlässig zu funktionieren.

Dass ein einfacher Reload Window dieses Verhalten wieder zurücksetzt, passt erstaunlich gut zu dieser Theorie.

Natürlich kann ich nicht mit Sicherheit behaupten, dass genau das die Ursache ist. Dazu fehlen Einblicke in die interne Architektur der Codex-Erweiterung. Trotzdem sprechen meine Beobachtungen und die Erfahrungen anderer Entwickler aus meiner Sicht sehr deutlich dafür, dass wir es hier eher mit einem Zustand der Agent-Umgebung als mit einem Problem des eigentlichen Modells zu tun haben.

Meine persönliche Einschätzung

Und genau das finde ich eigentlich am spannendsten.

Vor zwei Jahren haben wir noch darüber diskutiert, ob eine KI überhaupt sinnvoll programmieren kann.

Heute diskutieren wir darüber, warum ein Agent nach mehreren Stunden Entwicklung zwar noch exakt weiß, welche Datei geändert werden muss – den eigentlichen Werkzeugaufruf aber manchmal nicht mehr ausführt.

Allein diese Diskussion zeigt, wie unglaublich schnell sich diese Technologie entwickelt.

Trotz dieser kleinen Eigenheiten möchte ich den Codex Agent heute nicht mehr missen. Gerade bei größeren Projekten spart er mir enorm viel Zeit und übernimmt Aufgaben, für die ich früher deutlich länger gebraucht hätte. Gleichzeitig zeigen solche Erfahrungen aber auch, dass wir uns noch mitten in der Entwicklung echter autonomer Software-Agenten befinden.

Und genau deshalb finde ich es wichtig, nicht nur über die beeindruckenden Fähigkeiten dieser Systeme zu sprechen, sondern auch über die kleinen Eigenheiten, auf die man im Entwickleralltag stößt. Denn genau dort entscheidet sich letztendlich, wie zuverlässig ein KI-Agent in der täglichen Praxis wirklich ist.

Fazit

Meine Erfahrungen mit dem OpenAI Codex Agent zeigen eindrucksvoll, wie leistungsfähig moderne KI-Agenten bereits heute sind. Gleichzeitig habe ich beobachtet, dass die Autonomie nach längeren Entwicklungssitzungen teilweise nachlassen kann, obwohl der Agent weiterhin vollständigen Zugriff auf das Projekt besitzt und Fehler korrekt analysiert. Dass ein einfacher „Developer: Reload Window“ die vollständige Arbeitsweise häufig wiederherstellt, spricht aus meiner Sicht eher für ein Zustandsproblem innerhalb der Agent-Umgebung als für eine Schwäche des eigentlichen Modells. Ich bin gespannt, wie sich diese noch jungen Agentensysteme in den kommenden Monaten weiterentwickeln – denn das Potenzial ist schon heute enorm.