AI Coding: 5 Zahlen zeigen das Produktionsproblem

AI Coding ist in Unternehmen angekommen, aber der neue New-Relic-Report zeigt eine unbequeme Lücke: KI-generierter Code wirkt im Review sauber, verursacht in Produktion aber messbar mehr Incidents, Rework und Senior-Firefighting.

94 Prozent. So viele befragte Technologieverantwortliche bewerten KI-generierten Code im Review als hochwertiger als Code, der von Menschen geschrieben wurde. Klingt nach einem Triumphzug für AI Coding. Fast schon nach: Thema erledigt, bitte alle IDEs auf Agentenmodus stellen.

Dann kommt der hässliche Teil.

Sobald derselbe Code in Produktion läuft, berichten 78 Prozent der Befragten von mehr Incidents. 82 Prozent hatten in den vergangenen sechs Monaten mindestens einen Produktionsausfall, der mit KI-generiertem Code zusammenhing. 86 Prozent sehen mehr Zeitaufwand bei Senior Engineers, die solche Probleme wieder einfangen müssen. Das ist keine kleine Delle in der Begeisterung. Das ist ein Warnschild mit Blinklicht.

Die Zahlen stammen aus dem State of AI Coding Report von New Relic. Für die Studie befragte Hanover Research im Auftrag von New Relic 200 US-Technologieverantwortliche aus IT und Engineering, alle auf Managementebene oder darüber. Die Befragten arbeiten in Unternehmen, die generative und agentische KI bereits in der Softwareentwicklung nutzen.

Wir bei digital-magazin.de haben uns den Report genauer angesehen. Meine Einschätzung: Der spannende Befund ist nicht, dass KI-Code Fehler macht. Natürlich macht er Fehler. Der eigentliche Befund ist, dass viele Unternehmen diese Fehler erst zu spät sehen.

AI Coding sieht im Review besser aus, als es läuft

Der Widerspruch ist ziemlich menschlich. Ein Pull Request kann sauber aussehen. Klare Struktur, konsistenter Stil, keine offensichtlichen Syntaxpatzer, ein paar Tests dazu. Wer so etwas im Review sieht, nickt schneller. Gerade dann, wenn die Alternative ein hastig zusammengeschobener Patch nach einem langen Sprint ist.

Doch Code ist kein Aufsatz. Er muss nicht nur hübsch lesbar sein, sondern sich im Betrieb unter echten Abhängigkeiten, echtem Traffic und echten Randfällen benehmen. Genau da kippt laut New Relic die Wahrnehmung. Die Pressemitteilung zum Report nennt den Kern sehr deutlich: KI-generierter Code wird im Review hoch bewertet, löst nach dem Deployment aber mehr operative Arbeit aus.

Das passt zu dem, was viele Entwicklungsteams bereits leise beobachten. KI-Assistenten sind hervorragend darin, plausiblen Code zu erzeugen. Plausibel ist aber nicht dasselbe wie belastbar. Ein Modell kennt die lokale Architektur nur so gut, wie sie im Kontext auftaucht. Es kennt Produktionsdaten nicht automatisch, es versteht historisch gewachsene Sonderfälle oft nur bruchstückhaft, und es hat keinen echten Schmerz, wenn ein Deployment am Freitagabend schiefgeht.

Der bestehende dm-Artikel zu AI Coding Observability als Kontrollschicht hatte genau diesen Punkt bereits vorweggenommen: Sobald KI-Assistenten echte Entwicklungsarbeit übernehmen, reicht Bauchgefühl nicht mehr. Der neue Report liefert nun die Zahlen dazu.

Die neue Normalität: KI schreibt große Teile der Codebasis

New Relic beschreibt AI Coding nicht mehr als Spielwiese einzelner Power-User. 67 Prozent der Befragten sagen, dass KI inzwischen zwischen 51 und 75 Prozent des wöchentlichen Code-Outputs generiert oder wesentlich refaktoriert. Das ist keine Autocomplete-Anekdote mehr. Das ist industrielle Softwareproduktion mit maschineller Vorarbeit.

Auch Vibe Coding hat laut Report den Weg in regulierte Prozesse gefunden. 88 Prozent der Organisationen haben Vibe Coding in formale Produktionsrichtlinien geschrieben. Nur 5 Prozent beschränken es auf Nicht-Produktionsumgebungen, niemand in der Stichprobe verbietet es komplett. Der Wildwuchs ist also nicht mehr nur heimlich. Er wird offizieller.

Das ist einerseits vernünftig. Unternehmen können kaum so tun, als würden Entwickelnde keine KI-Werkzeuge nutzen. Wer den Einsatz offiziell macht, kann Regeln setzen, Audit-Trails definieren und Tooling standardisieren. Andererseits verschiebt diese Freigabe Verantwortung nach vorn. Wenn AI Coding offiziell in Produktionsrichtlinien steht, muss die Organisation auch erklären können, was dabei entsteht.

Genau hier liegt die Falle. 62 Prozent der Technologieverantwortlichen geben an, dass ihre Teams KI-generierten Code häufig ohne manuelle Zeilenprüfung in Produktion geben. Das heißt nicht zwingend, dass niemand prüft. Es heißt aber: Die alte Review-Disziplin wird durch Vertrauen in Muster, Tests, Toolausgaben und Zeitdruck ersetzt.

Mal ehrlich: Das ist nachvollziehbar. Wenn ein KI-Assistent in zehn Minuten eine Änderung erzeugt, fühlt sich eine einstündige Review-Schleife plötzlich wie Bürokratie an. Nur verschwindet die Komplexität nicht. Sie wandert.

Was die Studie zeigt und was sie nicht zeigt

Ein kurzer Realitätscheck gehört dazu. Die New-Relic-Studie ist keine neutrale Laborstudie über alle Codebasen dieser Welt. Befragt wurden 200 US-Entscheidungstragende, die bereits mit generativer und agentischer KI in der Softwareentwicklung arbeiten. Das verzerrt die Stichprobe bewusst in Richtung Unternehmen, die beim Thema weiter sind als der Durchschnitt. Eine kleine Agentur ohne formale Plattformgruppe taucht darin vermutlich nicht auf.

Außerdem sind viele Werte Selbstauskünfte. Wenn Führungskräfte sagen, dass Incidents gestiegen sind oder Senior Engineers mehr Zeit mit Reparaturen verbringen, ist das ein starkes Signal, aber keine automatisch gemessene Produktionsmetrik über alle Systeme hinweg. Genau deshalb sollte man die Zahlen nicht als Naturgesetz lesen. Sie sind ein Lagebild.

Und dieses Lagebild ist trotzdem wertvoll. Denn die Befragten sitzen nah genug an Budget, Toolauswahl, Engineering-Prozessen und Incident-Folgen, um den operativen Druck zu spüren. Wenn fast vier von fünf Organisationen mehr produktionsnahe Störungen melden, ist das mehr als ein paar genervte Stimmen aus einem Slack-Channel.

Interessant ist auch, dass die Studie nicht sagt: KI-Code ist schlechter. Sie sagt: Die aktuelle Art, KI-Code zu erzeugen, zu prüfen und in Produktion zu bringen, passt noch nicht zur Geschwindigkeit, mit der dieser Code entsteht. Das ist ein anderer Befund. Und ein lösbarer.

Die vier häufigsten Fehler sind keine exotischen KI-Pannen

Spannend sind auch die konkreten Fehlerarten. New Relic nennt vier Hauptmuster, die in den vergangenen sechs Monaten jeweils rund drei von zehn Unternehmen betroffen haben: Integrationsfehler, Compliance- und Governance-Issues, Datenintegritätsprobleme und neu eingeführte Sicherheitslücken.

Das sind keine futuristischen KI-Katastrophen. Das ist normaler Enterprise-Schmerz. Schnittstellen passen nicht zusammen. Eine Annahme über Daten stimmt nicht. Eine Policy wird verletzt. Eine Sicherheitsprüfung übersieht ein Detail. Der Unterschied: KI kann diese Probleme schneller, breiter und unauffälliger in mehrere Codepfade tragen.

Wer schon einmal eine vermeintlich kleine API-Änderung in einer verteilten Architektur nachverfolgt hat, kennt das Muster. Der Code sieht lokal korrekt aus. Die Tests decken den Happy Path ab. Im Zusammenspiel mit einer alten Service-Version, einem seltenen Nullwert oder einer schlecht dokumentierten Berechtigung fliegt das Ganze dann auseinander.

Bei KI-Coding und Developer-Rollen wurde diese Verschiebung bereits sichtbar: Die reine Codeproduktion wird billiger, aber Prüfung, Kontext und Verantwortung werden wertvoller. Genau das zeigt sich auch hier. Senior Engineers sparen nicht automatisch Zeit, wenn ein Assistent mehr Code erzeugt. Sie können im Gegenteil zu Aufräumkräften für maschinelle Annahmen werden.

Der Report nennt dafür eine besonders unangenehme Zahl: 86 Prozent berichten von mehr Zeit, die erfahrene Fachkräfte mit dem Beheben solcher Probleme verbringen. In manchen Fällen geht es laut New Relic um bis zu ein Drittel der Arbeitswoche. Das ist bitter. Die Menschen, die eigentlich Architektur, Plattformqualität und schwierige Produktentscheidungen voranbringen sollten, löschen Brände, die durch vermeintlich produktivere Workflows entstanden sind.

Observability wird vom Betrieb in den Prompt verschoben

96 Prozent der Befragten halten Observability beim Umgang mit KI-generiertem Code für sehr oder extrem wichtig. Kein einziger Befragter bewertete sie als unwichtig. Das ist für eine Anbieterumfrage natürlich ein dankbares Ergebnis, aber es ist trotzdem bemerkenswert. Die Diskussion ist offenbar weiter als „Brauchen wir Monitoring?“

Die bessere Frage lautet: Wo beginnt Monitoring?

78 Prozent der Teams fordern ihre KI-Tools laut Report mittlerweile häufig oder immer dazu auf, Telemetrie direkt in den generierten Code einzubauen. Also Logs, Traces, Metriken oder ähnliche Hooks. Das ist ein interessanter Kulturwechsel. Observability entsteht nicht erst, wenn SREs später Dashboards bauen. Sie rückt in den Prompt, in die Codevorlage, in den ersten Entwurf.

Technisch passt das zur Entwicklung rund um OpenTelemetry. Die OpenTelemetry-Spezifikation für generative KI beschreibt bereits semantische Konventionen für GenAI-Systeme, Events, Metriken und Traces. Wenn KI-Assistenten künftig Code schreiben, der von Anfang an beobachtbar ist, müssen Unternehmen solche Konventionen nicht mehr nachträglich mühsam in jede Anwendung stopfen.

Aber Vorsicht: „Schreib bitte Logs dazu“ ist noch keine Observability-Strategie. Ein Modell kann Logging aufblasen, sensible Daten protokollieren, falsche Metriknamen erzeugen oder Trace-Attribute uneinheitlich setzen. Wer Telemetrie in Prompts verlagert, braucht Prompt-Standards. Sonst entsteht nur sehr schnell sehr viel Rauschen.

Das Problem heißt nicht KI-Code, sondern unbeobachteter KI-Code

Ich würde aus den Zahlen nicht ableiten, dass Unternehmen AI Coding bremsen sollten. Das wäre die bequeme, aber falsche Reaktion. Der produktive Schluss lautet eher: AI Coding braucht dieselbe Ernsthaftigkeit wie jede andere produktionsnahe Automatisierung.

Wer CI/CD eingeführt hat, musste irgendwann Freigabeprozesse, Tests, Rollbacks, Artefakt-Signaturen und Deployment-Metriken definieren. Wer Cloud-Infrastruktur automatisiert, braucht Policies, Budgets, Drift-Erkennung und Incident-Prozesse. Warum sollte ausgerechnet maschinell erzeugter Code davon ausgenommen sein?

Die praktische Antwort beginnt mit Inventur. Welche Tools schreiben heute Code? Claude Code im Entwickleralltag, Cursor, GitHub Copilot, interne Agenten, Skripte, MCP-gestützte Workflows? Welche Repositories dürfen sie anfassen? Welche Daten landen im Prompt? Welche Teile der Codebasis sind reguliert, sicherheitskritisch oder kundennah?

Dann braucht es eine Metrik-Schicht. Nicht als Kontrollfantasie gegenüber einzelnen Entwickelnden, sondern als Systemblick: Welche KI-generierten Änderungen führen später zu Reverts? Wo steigen Incidents nach agentischen Refactorings? Welche Prompts erzeugen brauchbare Telemetrie? Welche Modelle produzieren die meisten Nacharbeiten? Wie hoch sind Kosten pro akzeptierter Änderung?

In diesem Sinne ist Observability kein nachträgliches Debugging-Werkzeug. Sie wird zum Produktionsvertrag für KI-Code. Der Code darf schneller entstehen, aber nicht unsichtbarer werden.

Was Engineering-Teams jetzt konkret ändern sollten

Erstens: KI-generierten Code markieren. Nicht unbedingt mit einem großen Warnschild im Repository, aber nachvollziehbar in Pull Requests, Commit-Metadaten oder internen Review-Feldern. Wenn später ein Incident entsteht, muss das Team erkennen können, welche Rolle KI bei der Änderung spielte.

Zweitens: Review-Kriterien anpassen. Ein klassischer Code-Review prüft Lesbarkeit, Logik, Stil und Tests. Bei AI Coding muss zusätzlich die Entstehung geprüft werden: Welche Eingaben hatte das Tool? Welche Annahmen hat es getroffen? Welche Stellen hat es nicht gesehen? Welche Telemetrie wurde eingebaut?

Drittens: Telemetrie-Standards vorschreiben. Nicht jedes Team sollte eigene Log-Felder erfinden, nur weil ein Prompt gerade danach klingt. Unternehmen brauchen Vorgaben für Metriknamen, Trace-Attribute, Fehlerklassen und Redaction. Sonst entsteht eine neue Schatten-Observability, diesmal direkt im Code.

Viertens: Senior-Zeit schützen. Wenn KI-Tools schneller Code erzeugen, darf die gewonnene Zeit nicht vollständig in Reparaturarbeit verpuffen. Teams sollten bewusst Zeitfenster für Refactoring, Testhärtung und Architekturarbeit reservieren. Sonst wird AI Coding zum Produktivitätskredit mit hohem Zinssatz.

Fünftens: Tool-Auswahl an Produktionsdaten koppeln. Ein Assistent, der im Editor beeindruckt, ist noch nicht der beste Assistent für die Organisation. Entscheidend ist, welche Änderungen nach zwei Wochen Betrieb stabil laufen. Genau diese Verbindung zwischen Entwicklungsworkflow und Produktion wird zur Bewertungsgrundlage.

Sechstens: Kleine, harte Experimente fahren. Ein Team kann zum Beispiel vier Wochen lang alle KI-gestützten Änderungen markieren und danach prüfen, wie viele Review-Schleifen, Hotfixes, Reverts und Incident-Bezüge daraus entstanden sind. Das ist nicht perfekt wissenschaftlich. Aber es ist besser als die übliche Mischung aus Begeisterung, Bauchgefühl und Monatsrechnung.

Siebtens: Menschen nicht aus der Verantwortung drängen. AI Coding darf Review-Arbeit verändern, aber nicht in eine rituelle Absegnung verwandeln. Gerade bei sicherheitskritischem Code, Datenmigrationen, Authentifizierung, Zahlungsflüssen oder komplexen Integrationen braucht es weiterhin Fachleute, die nicht nur den Code lesen, sondern das System verstehen. Das klingt altmodisch. Es ist aber der Teil, den kein hübscher Diff ersetzt.

Für Tool-Anbietende ergibt sich daraus ebenfalls ein klarer Auftrag. Die nächste Generation von Coding-Assistenten muss nicht nur bessere Vorschläge machen, sondern ihre Vorschläge besser erklärbar machen. Welche Dateien wurden als Kontext genutzt? Welche Annahmen waren unsicher? Welche Tests fehlen? Welche Laufzeitdaten würden die Änderung bestätigen oder widerlegen? Das wäre produktiver als noch ein größerer „Generate“-Button.

Der eigentliche Wettbewerb beginnt nach dem Merge

AI Coding verändert Softwareentwicklung nicht, weil es Code schreiben kann. Das konnten Generatoren, Templates und Frameworks in kleinerem Maßstab schon lange. Neu ist die Geschwindigkeit, die Breite und die Überzeugungskraft. KI-Code sieht oft so gut aus, dass Teams ihn schneller durchwinken.

Der New-Relic-Report zeigt, warum diese Phase gefährlich ist. Nicht dramatisch im Sinne von „alles brennt“. Eher lästig, teuer und schleichend. Mehr Incidents hier, mehr Rework dort, mehr Senior-Zeit im Reparaturmodus. Genau solche Effekte fressen Produktivitätsgewinne auf, ohne dass sie in der nächsten Demo auftauchen.

Nach unserer Recherche bei digital-magazin.de wird der Markt deshalb in zwei Gruppen auseinanderlaufen. Die eine Gruppe nutzt AI Coding als schnelleren Textgenerator für Code und wundert sich später über operative Nebenwirkungen. Die andere Gruppe behandelt KI-generierten Code als messbaren Produktionsinput: mit Telemetrie, Review-Kontext, Standards und Feedback aus dem Betrieb.

Die zweite Gruppe wird weniger laut jubeln. Aber sie wird besser schlafen.

Der Punkt ist: AI Coding ist nicht das Problem. Blindes Vertrauen ist das Problem. Wenn Unternehmen diese Lücke schließen, kann KI-Code tatsächlich produktiver machen. Wenn nicht, schreibt der Assistent vielleicht schneller Code, aber die Rechnung landet später bei den Menschen im Bereitschaftsdienst.