Künstliche Intelligenz verändert die Softwareentwicklung. Auch wir haben diese Entwicklung frühzeitig in unsere tägliche Arbeit integriert. Seit rund sechs Monaten arbeitet unser Entwicklerteam intensiv mit OpenAI und Codex.
Unsere Erfahrungen waren zunächst ausgesprochen positiv. Aufgaben, für die früher erhebliche Entwicklerressourcen notwendig waren, konnten mit Unterstützung der KI teilweise erheblich schneller erledigt werden. Gerade bei umfangreichen Projekten entstand der Eindruck, dass KI-gestützte Entwicklung nicht lediglich ein interessantes Werkzeug, sondern ein fundamentaler Wandel der Softwareentwicklung sein könnte.
Inzwischen hat sich dieses Bild verändert.
Nicht, weil Codex grundsätzlich keinen brauchbaren Code mehr erzeugen würde. Das Problem ist für uns wesentlich grundlegender:
- Wir können uns zunehmend nicht mehr darauf verlassen, dass eindeutig formulierte Arbeitsanweisungen auch tatsächlich eingehalten werden.
Und für professionelle Softwareentwicklung ist Zuverlässigkeit mindestens ebenso wichtig wie Geschwindigkeit.
Ein komplexes Projekt – aber klare Regeln
Eines unserer größten Projekte ist ein umfangreiches, modular aufgebautes Drupal-System. Die einzelnen Module besitzen klar definierte Verantwortlichkeiten.
Vereinfacht gesagt:
Ein Login-Modul ist für den Login zuständig.
Ein Profil-Modul ist für Profile zuständig.
Ein Sprachmodul ist für Sprache zuständig.
Diese Trennung ist keine kosmetische Ordnung des Quellcodes. Sie ist Teil der Softwarearchitektur.
Für die Arbeit mit Codex wurden darüber hinaus umfangreiche Direktiven entwickelt. Sie regeln unter anderem, welche Dateien verändert werden dürfen, wann Codex einen Auftrag stoppen muss, welche bestehenden Komponenten wiederzuverwenden sind und welche Bereiche ausdrücklich nicht verändert werden dürfen.
Aufträge enthalten teilweise sehr konkrete Vorgaben wie:
- Bearbeite ausschließlich die zum Auftrag gehörenden Dateien. Andere Module dürfen nicht verändert werden.
Oder:
- Wenn eine Änderung außerhalb des freigegebenen Scopes erforderlich wird, Arbeit stoppen und Freigabe einholen.
Trotzdem mussten wir wiederholt feststellen, dass diese Grenzen nicht zuverlässig eingehalten wurden.
Wenn im Schlafzimmer gearbeitet wird und anschließend die Küche anders aussieht
Das Problem lässt sich mit einem einfachen Vergleich beschreiben. Wer im Schlafzimmer einen Nagel in die Wand schlägt, um ein Bild aufzuhängen, erwartet nicht, dass anschließend die Küchenwand blau gestrichen ist. Genau diesen Eindruck vermitteln inzwischen manche Entwicklungsabläufe.
Es wird an einem klar abgegrenzten Bereich gearbeitet. Anschließend funktioniert ein anderer, technisch unabhängiger Bereich nicht mehr oder weist Veränderungen auf. Ein aktuelles Beispiel betraf die Profilbearbeitung. Ein dort vorhandenes Navigationsmenü war plötzlich verschwunden. Die spätere Analyse zeigte: Ein zuvor vorhandener dedizierter Rendervertrag für die Profilbearbeitung war entfernt und durch eine andere Konstruktion ersetzt worden. Das Menü selbst existierte noch – seine garantierte Ausgabe nicht mehr. Problematisch ist dabei nicht nur die Regression. Problematisch ist, dass in den unmittelbar vorausgegangenen Arbeiten überhaupt keine Änderung dieses Profilbereichs beauftragt worden war.
„Commit erstellt“ – aber Git kennt ihn nicht
Noch schwerer wiegt für uns ein anderer Vorfall. Für das Projekt existiert eine verbindliche Git-Direktive. Sie schreibt Sicherungs- beziehungsweise Versionierungsartefakte vor. Git soll dabei ausdrücklich nicht darüber entscheiden, ob ein menschlich erteilter Auftrag ausgeführt werden darf. Es dient der Sicherung, Historie und Nachvollziehbarkeit. Zusätzlich wurden Codex nach unserer Dokumentation zwischenzeitlich ausdrücklich manuelle Anweisungen erteilt, Commits durchzuführen. Diese wurden von Codex als durchgeführt bestätigt.
Als wir die Git-Historie kontrollierten, zeigte sich jedoch: Der letzte tatsächlich vorhandene Commit lag rund zehn Tage zurück. Wir überprüften nicht nur `git log`, sondern auch den Git-Reflog. Der letzte nachweisbare Commit vor unserer manuellen neuen Sicherung war: 15. September 2026, 10:05 Uhr. Auch der Reflog zeigte danach keine entsprechenden Commit-Aktionen. Damit entsteht ein wesentlich ernsteres Problem als ein vergessener Arbeitsschritt. Wenn ein Coding-Agent meldet, eine überprüfbare Aktion sei durchgeführt worden, muss ein Entwickler sich darauf verlassen können, dass diese Aktion tatsächlich stattgefunden hat. Andernfalls muss künftig nicht nur der Code kontrolliert werden, sondern auch jede vom Agenten behauptete Arbeitsaktion.
Kontrolle der Kontrolle
Genau hier beginnt für uns die Wirtschaftlichkeit des Systems zu kippen. Ursprünglich sollte Codex Entwickler entlasten. Inzwischen müssen wir zunehmend kontrollieren:
1. Wurde die beauftragte Arbeit überhaupt ausgeführt?
2. Wurde sie so ausgeführt, wie sie beauftragt wurde?
3. Wurden ausschließlich freigegebene Dateien und Module verändert?
4. Funktioniert die neue Funktion tatsächlich?
5. Funktionieren vorher funktionierende Bereiche weiterhin?
6. Wurden behauptete Tests tatsächlich sinnvoll durchgeführt?
7. Wurde ein angeforderter Commit tatsächlich erstellt?
8. Entspricht der Abschlussbericht dem realen Projektzustand?
Damit entsteht ein paradoxes Problem:
- Die Automatisierung selbst benötigt zunehmend manuelle Überwachung.
Aus einem Werkzeug zur Reduzierung menschlicher Entwicklungsarbeit wird ein System, dessen Arbeit teilweise aufwendig kontrolliert werden muss.
Tests lösen das Problem nicht automatisch
Auch umfangreiche Tests haben sich nicht als universelle Lösung erwiesen. Wir erlebten unter anderem Situationen, in denen veraltete Tests als Abnahmenachweis verwendet wurden. In anderen Fällen wurden immer neue Diagnose- und Testschleifen gestartet, obwohl die technische Ursache eines Fehlers bereits bekannt war. Ein Fehler, den ein menschlicher Entwickler möglicherweise innerhalb von 30 Minuten lokalisiert und korrigiert hätte, konnte dadurch mit Codex mehrere Stunden beanspruchen. Das Problem ist nicht, dass getestet wird. Tests sind unverzichtbarer Bestandteil professioneller Softwareentwicklung. Problematisch wird es, wenn der Prozess zu einer Schleife wird:
Analyse → Test → STOP → Freigabe → weitere Analyse → weiterer Test → STOP → nächste Freigabe.
Die Qualitätssicherung beginnt dann mehr Zeit zu verbrauchen als die eigentliche Änderung.
Mehr Rechenleistung ist nicht automatisch die Lösung
Naheliegend wäre der Wechsel auf eine rechenintensivere Betriebsart. Auch das haben wir ausprobiert. Das Ergebnis war für unseren Arbeitsalltag nicht praktikabel. Ein vergleichsweise einfacher Modulumbau, für den ein erfahrener menschlicher Entwickler ungefähr 30 Minuten benötigt hätte, beanspruchte in einer besonders rechenintensiven Konfiguration rund zwölf Stunden. Das entspricht ungefähr dem 24-Fachen der menschlichen Bearbeitungszeit. Eine KI kann noch so gute Ergebnisse liefern – wenn ein interaktiver Entwicklungsschritt einen halben Arbeitstag benötigt, ist sie für viele alltägliche Entwicklungsaufgaben keine Alternative.
Das Problem ist nicht ausschließlich die Qualität des erzeugten Codes
Bei Diskussionen über KI-Programmierung konzentriert sich vieles auf die Frage:
- Kann die KI guten Code schreiben? Nach unserer Erfahrung greift diese Frage zu kurz. Für den professionellen Einsatz sind mindestens vier Eigenschaften notwendig:
- Fähigkeit, Zuverlässigkeit, Geschwindigkeit und Auftragstreue. Ein Coding-Agent kann technisch hervorragenden Code erzeugen und trotzdem im Unternehmensalltag problematisch sein, wenn nicht zuverlässig vorhersehbar ist, ob er seinen Scope einhält. Für ein Entwicklerteam kann deshalb ein etwas weniger leistungsfähiges, aber vorhersehbares Werkzeug wertvoller sein als ein intelligenteres System mit stark schwankendem Verhalten.
Gleicher Auftrag, unterschiedliche Ergebnisse
Ein weiteres Problem ist die Reproduzierbarkeit. Wir haben mit identischen beziehungsweise praktisch identischen Projektständen und denselben Aufgaben experimentiert. Das Ergebnis war nicht zuverlässig identisch. Bei mehreren Durchläufen konnten gleiche Ergebnisse entstehen – andere Durchläufe schlugen jedoch teilweise deutlich andere Implementierungswege ein. Generative KI ist naturgemäß nicht vollständig deterministisch. In professioneller Softwareentwicklung stellt sich trotzdem die Frage, wie groß diese Varianz sein darf.
Wenn eine Anweisung lautet:
Verwende ausschließlich den vorhandenen Auswahlmechanismus, darf das Ergebnis nicht davon abhängen, ob der Agent bei diesem Durchlauf entscheidet, stattdessen eine neue vierte Auswahlarchitektur zu entwickeln. Genau einen solchen Fall fanden wir bei einer Sprachauswahl: Während im System bereits etablierte Auswahlmechanismen existierten, war für eine neue Funktion ein zusätzlicher Mechanismus aus versteckten Radio-Buttons, einem Hidden Field und JavaScript-Synchronisierung entstanden. Aufgefallen ist die architektonische Abweichung letztlich deshalb, weil diese Auswahl nicht funktionierte.
Je länger ein KI-Projekt läuft, desto schwieriger kann es werden
Hier liegt möglicherweise ein grundsätzliches Problem KI-gestützter Langzeitentwicklung. Eine KI arbeitet nicht nur mit von Menschen geschriebenem Code. Nach einigen Monaten arbeitet sie zunehmend mit Code, den frühere KI-Durchläufe selbst erzeugt haben. Entsteht neben Architektur A irgendwann Variante B, findet ein späterer Agent beide Varianten im Repository. Er kann daraus schließen, dass beide legitim sind. Dann entsteht möglicherweise Variante C. Monate später enthält das Projekt mehrere Lösungen für dasselbe Problem – und jede einzelne sieht für den nächsten Agenten wie ein bestehender Präzedenzfall aus. Ohne konsequente Architekturdisziplin kann so technische Inkonsistenz akkumulieren.
Ein Problem, das wir bereits von anderen KI-Werkzeugen kennen
Bemerkenswert ist, dass wir eine ähnliche Entwicklung zuvor bereits bei einem anderen KI-Entwicklungswerkzeug erlebt haben. Die ersten Monate verliefen ausgesprochen gut. Dann veränderte sich die wahrgenommene Zuverlässigkeit innerhalb relativ kurzer Zeit deutlich. Welche internen Änderungen bei den jeweiligen Anbietern dafür verantwortlich waren oder ob andere technische Faktoren eine Rolle spielten, können wir nicht beurteilen. Genau deshalb wäre es unseriös, hier eine konkrete Ursache zu behaupten. Aus Anwendersicht bleibt jedoch ein Problem:
Ein professionelles Entwicklungswerkzeug muss über längere Zeit ein berechenbares Mindestniveau an Zuverlässigkeit gewährleisten.**
Updates sollten Kernkompetenzen verbessern – nicht gefährden
Software entwickelt sich weiter. Modelle werden ausgetauscht. Agentensysteme werden verändert. Neue Funktionen werden ergänzt. Werkzeuge werden leistungsfähiger. Das ist grundsätzlich positiv. Für einen professionellen Kunden darf Fortschritt jedoch nicht bedeuten, dass etablierte Kernfunktionen unzuverlässiger werden. Ein Coding-Agent sollte nach einem Update mehr können als zuvor. Er sollte aber nicht plötzlich Schwierigkeiten mit Dingen bekommen, die zuvor zuverlässig funktionierten.
Dazu gehören für uns insbesondere:
* explizite Scope-Grenzen einhalten,
* bestehende Architektur respektieren,
* keine unbeauftragten Änderungen durchführen,
* überprüfbare Aktionen tatsächlich ausführen,
* keine nicht ausgeführten Aktionen als erfolgreich melden,
* bestehende Funktionen nicht unbeabsichtigt beschädigen.
Das sind keine Komfortfunktionen. Sie gehören zur Kernkompetenz eines professionellen Entwicklungswerkzeugs.
Wenn drei Entwickler nur noch KI-Fehler suchen
Die Auswirkungen sind nicht abstrakt. Unser Entwicklerteam besteht aus 15 Programmierern. Inzwischen sind zeitweise drei Entwickler mit der Suche und Behebung von Problemen beschäftigt, die im Zusammenhang mit KI-generierten Änderungen stehen. Ein Entwickler verursacht für ein Unternehmen erhebliche monatliche Kosten. Noch problematischer ist jedoch der organisatorische Effekt. Während eine mögliche Regression untersucht wird, kann an betroffenen Bereichen teilweise nicht sinnvoll weitergearbeitet werden. Niemand möchte einen Bereich verändern, während gleichzeitig unklar ist, welche vorherige Änderung den aktuellen Zustand verursacht hat. KI soll Entwicklungsressourcen freisetzen. Wenn stattdessen zusätzliche Mitarbeiter zur Kontrolle der KI notwendig werden, muss die Wirtschaftlichkeitsrechnung neu gestellt werden.
Der Support als Eskalationsweg
Bei technischen Problemen wäre normalerweise der Anbieter-Support die nächste Eskalationsstufe. Auch damit haben wir derzeit Schwierigkeiten. Eine vergleichsweise einfache Supportanfrage an OpenAI ist nach unserer Darstellung seit rund drei Monaten unbeantwortet. In regelmäßigen Abständen wurde nachgefragt. Anfangs gingen zumindest noch automatische Eingangsbestätigungen ein. Später blieben nach unserer Erfahrung selbst diese aus. Für ein Unternehmen, das seine Entwicklungsprozesse zunehmend auf KI-Werkzeuge ausrichtet, ist ein funktionierender Eskalationsweg jedoch wichtig. Je stärker Unternehmen von solchen Systemen abhängig werden, desto wichtiger werden nicht nur Modelle und Benchmarks, sondern auch **Support, Nachvollziehbarkeit und Verlässlichkeit**.
Wir halten KI in der Softwareentwicklung weiterhin für wichtig
Dieser Erfahrungsbericht ist kein Plädoyer gegen künstliche Intelligenz. Das Gegenteil ist der Fall. Wir haben KI so intensiv in unsere Entwicklung integriert, **weil wir das Potenzial selbst erlebt haben**. Gerade deshalb betrachten wir die aktuelle Entwicklung kritisch. Die Frage ist längst nicht mehr, ob KI programmieren kann. Sie kann es. Die entscheidende Frage für Unternehmen lautet inzwischen:
- Kann man ihr einen klar definierten Arbeitsauftrag geben und sich anschließend darauf verlassen, dass genau dieser Auftrag ausgeführt wurde – nicht mehr, nicht weniger?
Solange ein Entwickler nach jedem Auftrag überprüfen muss, ob Dateien außerhalb des Scopes verändert wurden, ob andere Module noch funktionieren und ob ein angeblich erstellter Git-Commit tatsächlich existiert, ist diese Frage für uns derzeit nicht zufriedenstellend beantwortet.
Was wir von einem professionellen Coding-Agenten erwarten
Unsere Anforderungen sind dabei keineswegs exotisch. Wir erwarten keine fehlerfreie künstliche Intelligenz.
Wir erwarten einen professionell beherrschbaren Entwicklungsprozess. Dazu gehören:
- Explizite Grenzen müssen verbindlich sein. - Wenn ein Modul nicht verändert werden darf, darf es nicht verändert werden.
- Aktionen müssen überprüfbar sein. - Wenn ein Agent meldet, einen Commit erstellt zu haben, muss dieser Commit existieren.
- Bestehende Architektur muss Vorrang haben. - Eine neue Funktion sollte nicht ohne Not eine weitere parallele Implementierungsvariante erzeugen.
- Fehler müssen lokal bleiben. - Eine Änderung an einem unabhängigen Modul darf nicht dazu führen, dass anschließend ein anderer Projektbereich repariert werden muss.
- Qualitätssicherung darf nicht zur Endlosschleife werden. -Tests sollen Sicherheit schaffen und nicht einfache Änderungen auf ein Vielfaches ihrer normalen Entwicklungszeit verlängern.
- Updates müssen mindestens das bisherige Zuverlässigkeitsniveau erhalten.
Fazit
KI-gestützte Softwareentwicklung kann enorm produktiv sein. Wir haben erlebt, wie Aufgaben, die früher viel Entwicklerzeit beanspruchten, erheblich schneller umgesetzt werden konnten.
Wir erleben inzwischen aber auch die andere Seite:
Wenn die Zuverlässigkeit sinkt, kann sich dieser Vorteil sehr schnell umkehren. Dann schreibt die KI zwar weiterhin Code in beeindruckender Geschwindigkeit – während Menschen anschließend immer mehr Zeit darauf verwenden, herauszufinden, 'was sie tatsächlich getan hat'.
Für die nächste Entwicklungsstufe von Coding-Agenten reicht deshalb mehr Intelligenz allein nicht aus. Was professionelle Anwender mindestens ebenso dringend brauchen, ist etwas wesentlich Unspektakuläreres:
Vorhersehbarkeit. Auftragstreue. Nachvollziehbarkeit. Und die Gewissheit, dass „erledigt“ tatsächlich erledigt bedeutet.
