Was eine Studie zu KI-Code mir über meine Arbeit verrät

Die Zahlen

Eine Studie von CloudBees hat mehr als 200 Technologieleiter befragt, wie sich KI-generierter Code in ihren Unternehmen auswirkt. Golem hat die Ergebnisse zusammengefasst. Die Befragten beschreiben den Stand mit den Tools von 2025. Die Zahlen passen trotzdem zu dem, was ich bei viel kleineren Projekten gesehen habe.

81 Prozent der Befragten berichten von einem Anstieg der Probleme in Produktion, die mit KI-generiertem Code zusammenhängen. Fehler in Funktionen, langsame Systeme, Sicherheitslücken.

70 Prozent empfinden die Pflege der automatischen Tests inzwischen als größere Belastung als das Schreiben des Codes selbst.

92 Prozent sind trotzdem zuversichtlich, dass ihr Code produktionsreif ist, wenn sie ihn einsetzen.

Nur 56 Prozent glauben, dass die formalen Prüfprozesse in ihrem Unternehmen tatsächlich immer angewendet werden.

Der Einsatz von KI-generiertem Code ist um 52 Prozent gestiegen. Nur 31 Prozent der dafür getätigten Ausgaben lassen sich mit Geschäftsergebnissen verknüpfen.

Was die Studie eigentlich sagt

Auf den ersten Blick wirkt das wie ein Enterprise-Problem. Große Unternehmen, große Teams, riesige Programme. Es ist aber das gleiche Muster, das ich bei Solo-Gründern sehe, die mit Manus, Cursor oder Bolt ihr erstes MVP bauen.

Das Kernproblem liegt zwischen Erzeugung und Validierung. Code entsteht schneller, als er geprüft werden kann. Wenn Validierung nicht skaliert, wird sie weggelassen. Sie wird verschoben, sie wird oberflächlich, oder sie findet einfach nicht statt. Wer auslässt, merkt es meistens erst in Produktion. Bei einem Großunternehmen heißt das Ausfall und Regelverstoß. Bei einem Solo-Gründer heißt das App-Store-Ablehnung, ein Datenschutzproblem oder eine Sicherheitslücke, die in der ersten Nutzungswoche auffliegt. Eine Analyse von 670 KI-generierten Websites zeigt, wie oft das mit den Tools von 2025 vorkam.

Warum das ein Prozessproblem ist

Die widersprüchlichste Zahl der Studie ist die mit den 92 Prozent Zuversicht bei gleichzeitig 81 Prozent Produktionsproblemen. Die Befragten wissen, dass es schiefgeht, und glauben trotzdem, ihr eigener Code sei in Ordnung.

Das hat mit Können wenig zu tun. Es liegt daran, dass Prüfen nicht mitwächst.

KI generiert Code, der gut aussieht. Die Syntax stimmt, die Struktur wirkt sauber, das Beispiel funktioniert. Das erzeugt ein Vertrauen, das nicht durch Verständnis gedeckt ist. Auf Schwachstellen weist die KI oft nur hin, wenn jemand danach fragt. Wer nicht fragt, bekommt ein überzeugend formuliertes “fertig”.

Dazu kommt: Wer keinen Code geschrieben hat, dem fehlt das körperliche Gefühl dafür, was an einer Lösung wackelig ist. Beim eigenen Code merkt man, an welcher Stelle man geschlampt hat. Beim generierten Code sieht man nur das Ergebnis.

Was das für meine Arbeit bedeutet

Ich begleite Solo-Gründer, die mit KI ihren ersten Prototyp gebaut haben und jetzt vor der Frage stehen, wie sie daraus ein veröffentlichtes Produkt machen. Meine Arbeit setzt dort an, wo niemand mehr fragt. Beim Hinterfragen.

Konkret heißt das: Eine Prüfung, bevor die App in den Store geht. Eine Kontrolle, ob die Datenablage trägt, was sie tragen soll. Die häufigsten Befunde: Zugangsschlüssel offen in der App, mehrere Login-Systeme nebeneinander und fehlender Schutz für Nutzerdaten. Ein Review nach jeder größeren Änderung. Eine Frage zu jeder Annahme, die die KI getroffen hat. Das Prüfen selbst übernimmt heute oft ein Agent. Ich schaue, ob die Prüfung die richtigen Stellen abdeckt.

Ein Beispiel aus einem Projekt von 2025: Die KI hatte eine Datenbank mit 26 Tabellen für ein einfaches MVP gebaut, inklusive Zugriffsregeln, die niemand mehr durchschauen konnte. Der Code lief. Die KI meldete “Success”. Aber es war eine Datenbank, die ein größeres Team auf Jahre beschäftigt hätte und für ein MVP völlig überdimensioniert war. Die eigentliche Arbeit war zu sagen: Das gehört da nicht hin. Diese Entscheidung trifft kein Agent für dich, denn sie hängt an der Frage, was das Produkt braucht.

Die CloudBees-Studie validiert das auf Enterprise-Ebene. Wenn 200 Tech-Führungskräfte das gleiche Problem haben wie ein einzelner Gründer mit einer Manus-App, liegt es im Ablauf. Es entsteht durch das Tempo der Generierung im Verhältnis zur Validierung. Eine Grenze des Modells ist das nicht.

Prozesse skalieren anders als Output.

Was ich daraus mitnehme

Generierung ist schnell, Validierung braucht Disziplin. Ein Agent wie Claude Code kann Code gegen eine Spec prüfen, Tests schreiben und ausführen. Das ist inzwischen ein Werkzeug, das man nutzen kann.

Die Spec schreibst du. Was in den Scope gehört, entscheidest du. Und die Frage, ob dieser Code so existieren soll, beantwortet dir kein Agent.

Code generieren kann inzwischen jeder. Diese Frage zu stellen ist die eigentliche Arbeit.