KI-unterstützte Softwareentwicklung erzeugt mehr Code, aber nicht automatisch bessere Qualität: Wer doppelt so viel Code schreibt, hat statistisch doppelt so viele Fehler. Automatische Code-Reviews liefern laut vorliegenden Studien nur rund 30 Prozent verwertbare Kommentare. Qualitätssicherung lässt sich durch KI ergänzen, aber nicht ersetzen.
Das Wichtigste in Kürze
- Wer doppelt so viel Code produziert, hat statistisch doppelt so viele Fehler: KI-gestützte Codegenerierung vergrößert das Qualitätsproblem, statt es zu lösen.
- KI-gestützte Code-Reviews liefern laut Studien nur rund 30 Prozent verwertbare Kommentare; der Rest ist irrelevant oder aktiv schädlich für das System.
- Ein KI-Review kostet im Vergleich zur statischen Analyse etwa den Faktor 1000 mehr, weil teure Sprachmodelle für jede Prüfung aufgerufen werden müssen.
- Ohne gezielte Gegenmaßnahmen erodiert die innere Qualität eines Softwaresystems messbar, wenn KI-Agenten unbeaufsichtigt Code erzeugen und verändern.
- Manche Entwickler schreiben einzelne Features bewusst wieder von Hand, um ihre Programmierfähigkeiten nicht durch reines Code-Review zu verlieren.
Doppelt so viel Code bedeutet doppelt so viele Fehler
Wer die Menge an generiertem Code steigert, steigert statistisch die Zahl der Fehler im gleichen Maß. Das ist der blinde Fleck in der aktuellen Debatte um KI-gestützte Softwareentwicklung. Die meisten Diskussionen drehen sich um die Frage, wie sich Code noch schneller erzeugen lässt. Ob das Problem in der Praxis je zu wenig Code war, fragt kaum jemand.
Für langlebige Systeme ist die Rechnung unbequem. Benjamin Hummel arbeitet mit Kunden, deren Software nicht 10.000 oder 20.000 Zeilen umfasst, sondern in die Millionen geht. Solche Systeme sind für Menschen schwer zu durchdringen, und ein KI-Modell tut sich dabei ebenfalls schwer.
Die häufig gehörte Erfolgsstory zeigt selten die zweite Seite. Was im Kleinen funktioniert, etwa eine App, die aus einem Prompt herausfällt, sagt wenig darüber aus, ob dasselbe Vorgehen in einem gewachsenen, komplexen System trägt.
Wo Unternehmen im deutschsprachigen Raum wirklich stehen
Das Spektrum ist breit, und niemand hat die vollautomatische Software Factory am Laufen. Der Eindruck, alle anderen seien schon weiter, hält der Realität nicht stand.
Einige Teams experimentieren im Kleinen mit agentischen Werkzeugen. Andere haben Tools zur agentischen Codeentwicklung flächendeckend an alle Entwicklerinnen und Entwickler ausgerollt. Und manche rollen bereits wieder zurück, weil sie festgestellt haben, dass der Betrieb Geld kostet und neu gemanagt werden muss.
Diese Rückwärtsbewegung ist kein Einzelfall. Agentische Arbeit verbraucht Tokens, und ein Agent, der seinen eigenen Weg geht, wird schnell teuer.
Warum die Qualitätssicherung zum echten Engpass wird
Wenn vorne mehr Code entsteht, verschiebt sich der Flaschenhals nach hinten. Genau dort sitzt die Qualitätssicherung, ein Mensch oder ein langsamer Testprozess.
Die verlockende Antwort lautet, die Absicherung wegzulassen, weil sie bremst. Für einen Prototypen mag das taugen. Für ein Produktivsystem, das Steuerbescheide verschickt oder Versicherungspolicen berechnet, ist es keine gute Idee.
Statt bei der Absicherung zu sparen, gilt die umgekehrte Logik: Die Qualitätssicherung muss mit der neuen Codemenge mitwachsen. Die Frage ist, ob sich bestehende Verfahren einfach hochskalieren lassen, ob neue Ansätze nötig sind oder ob es eine Mischung braucht.
Harness Engineering: Das Gerüst um das Modell herum
Ein LLM ist eine Maschine, die Wörter aufnimmt und Wörter ausgibt. Damit daraus zielgerichtete Codeentwicklung wird, braucht es Steuerung außen herum. Für dieses Gerüst hat sich der Begriff Harness Engineering etabliert.
Das Harness füttert den bestehenden Code ins Modell, nimmt Änderungen entgegen und gibt dem Modell Werkzeuge an die Hand: Compiler starten, Tests starten, auf das Feedback reagieren. Mit KI selbst hat dieser Teil wenig zu tun. Der öffentlich gewordene Source Code von Claude Code umfasst zwei- bis dreihunderttausend Zeilen, klassisches Software Engineering, um die KI überhaupt nutzbar zu machen.
Für die Qualitätssicherung ist dieses Harness der Andockpunkt. Wer hier eingreift, kann die Ausgaben des Modells in eine bessere Richtung treiben: sauberere Struktur, weniger Redundanz. Denn weil Code erzeugen billig ist, produzieren Modelle schnell Funktionen neu, die längst in Utils-Klassen existieren, mit allen bekannten Wartungsproblemen.
Schnelles Feedback entscheidet, auch für den Agenten
Der alte Grundsatz gilt unverändert, nur der Adressat ist neu. Früher sollte der Entwickler schnell Feedback bekommen, damit er nicht drei Tage in die falsche Richtung läuft. Heute stellt sich dieselbe Frage für den KI-Agenten.
Statische Analyse gehört als enge Regelschleife in das Harness. Über eine Schnittstelle, häufig MCP, fließen die Findings direkt zurück an den Agenten, der sie umsetzen kann.
Bei Tests wird es schwieriger, wenn die automatisierte Suite Stunden oder Tage läuft. Dann bremst sie den Agenten aus. Testselektion hilft: Eine Änderung am Exportmodul erfordert nicht die Tests der Bilanzierungslogik, sondern die Tests mit dem höchsten Signal für die konkrete Änderung. Solche Selektionsverfahren werden in der Forschung seit Langem diskutiert, und einige haben es in die Praxis geschafft.
Statische Analyse funktioniert mit KI erstaunlich gut
Das Qualitätsfeedback aus der statischen Analyse setzen die Modelle oft überraschend zuverlässig um. Das senkt sogar eine alte Hemmschwelle.
Früher reagierten Entwickler genervt, wenn ein Werkzeug ihnen nach getaner Arbeit Findings vor die Füße kippte. Füttert man dieselben Findings in den Agenten, räumt er sie weg, und der Code sieht am Ende besser aus. Die Absicherung durch Regressionstests bleibt trotzdem Pflicht, damit beim Aufräumen keine Funktionalität verloren geht.
Interessant ist, dass neue Regeln sinnvoll werden, die man früher nie aktiviert hätte. Ein Beispiel aus der Praxis: Ein Modell wollte in einem Java-System auf die gekapselten Internas einer Klasse zugreifen und griff per Reflection daran vorbei. Von einem erfahrenen menschlichen Entwickler käme diese Idee nicht. Wegen des Zufallselements der Modelle taucht sie aber gelegentlich auf, und dann willst du sie finden, bevor der Code produktiv geht.
Ohne Aufsicht erodiert die innere Qualität
Erste Untersuchungen deuten darauf hin, dass die Qualität eines Systems langfristig sinkt, wenn KI unbeaufsichtigt daran arbeitet. Verschiedene Qualitätsmetriken zeigen einen Trend nach unten, und es gibt anekdotische Hinweise, dass die Modelle sich dann selbst immer schwerer tun, den Code zu ändern.
Das ist keine Überraschung. Lässt man viele Menschen unbeaufsichtigt an einem System arbeiten, entstehen so viele Abhängigkeiten, dass jede Änderung siebzehn Dinge gleichzeitig im Kopf verlangt.
Bei den Modellen kommt ein technisches Limit hinzu. Das Kontextfenster ist begrenzt, und selbst wenn man es voll füllt, berücksichtigt das Modell nicht alles. Es pickt sich Teile heraus und übersieht anderes. Auch ein Modell tut sich schwer, wenn es zu viel gleichzeitig halten muss. Vorsicht ist bei solchen Analogien geboten, denn Begriffe wie Attention sind menschlich aufgeladen, obwohl am Ende Matrizen multipliziert werden.
Wer haftet, wenn der Airbag nicht auslöst?
Am Ende steht immer die Frage, wer für den Code verantwortlich ist. Bei einer Software im Automobil, die einen Airbag steuert, entscheidet diese Frage über Haftung.
Zu OpenAI oder Anthropic zu gehen und ihre Modelle verantwortlich zu machen, funktioniert nicht. Das steht im Kleingedruckten. Es bleibt ein Unternehmensrisiko, und es gab Fälle, in denen einzelne Entwickler in die Haftung genommen wurden, weil sie nicht nach Stand der Technik entwickelt und geprüft hatten. Die Hürden dafür sind hoch, aber die Fälle existieren.
Deshalb sind viele Domänen vorsichtig. Sie wählen einen von zwei Wegen: entweder ein Prüfverfahren, das jede einzelne Zeile Code liest, oder eine starke Einschränkung vorne, bei der jede vorgeschlagene Änderung angeschaut werden muss. Beides ist aufwendig, und nach einer halben Stunde reinen Reviewens sitzt man nur noch da und klickt “Yes, yes, yes”.
Die Rolle des Dauer-Reviewers ist gefährlich
Wer den Großteil des Codes generieren lässt und nur noch prüft, landet in der Rolle, für die Menschen am schlechtesten geeignet sind. Code visuell auf Korrektheit zu kontrollieren, funktioniert konzentriert vielleicht dreißig Minuten. Danach ist Schluss.
In der eigenen Entwicklung fährt Benjamins Team bewusst konservativ. Alle Änderungen wurden schon vorher flächendeckend gereviewt, und das bleibt so. Vor dem eigentlichen Review prüft jemand, ob der vom Agenten gelieferte Code überhaupt den Ansprüchen genügt, denn ungefilterten Code abzukippen wäre dem Reviewer gegenüber nicht fair.
Beide Review-Stufen fördern weiterhin so viele Probleme zutage, dass Benjamins Team sie nicht abschafft. Nicht immer sind es Fehler. Oft ist etwas inkonsistent oder an der falschen Stelle, was sich später bei einer Fehlerbehebung rächt.
Ein konkreter Gegenzug: Tempo gezielt rausnehmen. Einige Kollegen schreiben bestimmte Features wieder von Hand, auch um die Fähigkeit nicht zu verlieren.
Wer nur noch Code liest und nicht mehr schreibt, kann kaum noch einschätzen, was er da eigentlich tut. Benjamin Hummel
KI-Reviews sind Ergänzung, nicht Ersatz
Ein KI-Reviewer durch einen zweiten KI-Reviewer prüfen zu lassen, klingt nach der nächsten logischen Stufe. Die Zahlen sprechen dagegen. Über verschiedene Studien und Kundenerfahrungen hinweg, darunter eine Untersuchung einer australischen Universität, liegen die gängigen Werkzeuge bei rund 30 Prozent guten Review-Kommentaren. Der Rest ist irrelevant oder sogar schädlich für das System.
Blind übernehmen macht den Code also nicht besser. Du musst filtern, welche Kommentare taugen. Das unterscheidet einen KI-Reviewer grundlegend vom erfahrenen Kollegen, dessen Kommentar man früher ohne Rückfrage umgesetzt hat.
Der Vergleich zur statischen Analyse macht die Kosten deutlich. Ein KI-Reviewer findet viel von dem, was auch statische Analyse findet, kostet dabei aber rund den Faktor 1000 mehr, weil teure Modelle laufen müssen.
Selbst nach einem KI-Review findet ein Mensch immer noch viele Dinge. Der Nutzen liegt darin, dass die KI bestimmte Problemklassen vorab wegfiltert. So wie niemand mehr von Hand Zeilen auf Duplikate durchzählt, muss auch der menschliche Reviewer sich nicht mehr um jede maschinell prüfbare Klasse kümmern. Er fragt stattdessen: Stimmt die Architektur? Ist das aus Nutzersicht schlüssig?
Was KI-Reviews wirklich kosten
Die stärksten verfügbaren Modelle lassen die Kosten schnell eskalieren. Erste Experimente in Benjamins Team ergaben über 500 Dollar pro Tag fürs gesamte Team. Hochgerechnet landet man bei sechsstelligen Beträgen im Jahr.
Für manche ist das ein Lacher, für eine mittelgroße Firma ein Grund zum Schlucken. Ein Anbieter solcher Werkzeuge steckt in einem Konflikt: günstige Modelle drücken die Kosten, teurere heben die Review-Qualität. Zwischen beidem balanciert jedes Abo.
Die eigentliche Engineering-Herausforderung ist damit nicht das Modell, sondern der Umgang mit dem Ergebnis. Wie profitierst du von den Vorteilen, ohne die Nachteile zu erben, und bleibst dabei kosteneffizient? Für sechsstellige Beträge lässt sich auch eine Testerin oder ein Tester einstellen.
Ein Nebengedanke gehört dazu: Nicht jede Aufgabe braucht KI. Was ein klassisches Skript billig und zuverlässig erledigt, sollte kein Modell teuer umständlich lösen.
Mehr Ergebnisse sind noch keine besseren Ergebnisse
Die nächste Welle betrifft die Datenmengen, die KI produziert. Sicherheitsanalysen sind ein Beispiel. Werkzeuge in dieser Klasse produzieren enorm viele Ergebnisse, doch nicht jede gemeldete Verletzung ist relevant.
Das kennt man aus der statischen Analyse. Ist das ein reales Bedrohungsszenario? Lässt es sich tatsächlich ausnutzen, oder beschreibt es eine Situation, die in der echten Welt nie eintritt? Diese Bewertung überfordert Teams schnell. Alle Findings zu lesen, zu entscheiden und dann umzusetzen, ist der eigentliche Engpass.
Gerade bei Security verschärft sich die Lage, weil abhängige Bibliotheken gefühlt wöchentlich neue Lücken zeigen. Dasselbe Muster wiederholt sich bei Tests: Lässt die KI viele Tests schreiben, hast du mehr Tests, die fehlschlagen, obwohl niemand etwas geändert hat, und mehr flackernde Tests. Jede neue Fähigkeit zieht neue Probleme nach sich.
Langsamer werden ist eine Fähigkeit
Die ständige Beschleunigung führt zu Burnout, und das lässt sich aus vielen Ecken hören. Die Open-Source-Community trifft es besonders hart. Bots überfluten Projekte mit Security-Issues, während viele Maintainer die Arbeit ehrenamtlich neben ihrem Beruf leisten. Auf ihren Schultern ruht ein Großteil der digitalen Infrastruktur.
Manchmal ist es gar keine echte Beschleunigung, nur ein sehr schnell drehendes Hamsterrad. Neue Tools jeden Monat, die Landschaft ändert sich ständig, und aus dem Management kommt der Ruf nach noch mehr Tempo.
Die Gegenbewegung braucht Mut und ein Umfeld, das sie zulässt. Einen Schritt zurückzugehen und zu hinterfragen, was man da eigentlich tut, ist in dieser Zeit selbst eine Fähigkeit. Denn das Problem war nie zu wenig Code. Es war zu verstehen, was der Anwender wirklich braucht, und genau das gezielt umzusetzen.
Häufig gestellte Fragen
Bringt mehr KI-generierter Code automatisch bessere Software?
Nein. Wer die Menge an generiertem Code verdoppelt, verdoppelt statistisch auch die Zahl der Fehler. Besonders unbequem ist die Rechnung bei Systemen, die nicht 10.000 oder 20.000 Zeilen umfassen, sondern in die Millionen gehen: Solche Codebasen sind für Menschen schwer zu durchdringen, und Modelle tun sich daran ebenfalls schwer. Erfolgsgeschichten aus kleinen Apps sagen darüber wenig.
Setzen Unternehmen agentische Codeentwicklung schon flächendeckend ein?
Das Spektrum ist breit, und die vollautomatische Software Factory hat niemand am Laufen. Einige Teams experimentieren im Kleinen mit agentischen Werkzeugen, andere haben sie an alle Entwicklerinnen und Entwickler ausgerollt. Manche rollen bereits zurück, weil der Betrieb Geld kostet und neu gemanagt werden muss. Agentische Arbeit verbraucht Tokens, und ein Agent, der eigene Wege geht, wird schnell teuer.
Wo kann Qualitätssicherung bei KI-Agenten überhaupt ansetzen?
Am Harness, also dem klassisch programmierten Gerüst um das Modell herum. Es füttert bestehenden Code ins Modell, nimmt Änderungen entgegen und stellt Werkzeuge bereit: Compiler starten, Tests starten, auf Feedback reagieren. Wer hier eingreift, treibt die Ausgaben in Richtung sauberere Struktur und weniger Redundanz. Statische Analyse gehört als enge Regelschleife hinein, deren Findings direkt an den Agenten zurückfließen.
Setzen KI-Agenten die Findings aus statischer Analyse zuverlässig um?
Ja, oft überraschend zuverlässig. Früher reagierten Entwickler genervt, wenn ein Werkzeug nach getaner Arbeit Findings vor die Füße kippte; füttert man dieselben Findings in den Agenten, räumt er sie weg. Regressionstests bleiben trotzdem Pflicht, damit beim Aufräumen keine Funktionalität verloren geht. Sinnvoll werden dabei Regeln, die man früher nie aktiviert hätte, etwa gegen Reflection-Zugriffe auf gekapselte Internas.
Was passiert mit der Qualität, wenn KI-Agenten unbeaufsichtigt an einem System arbeiten?
Sie sinkt langfristig. Erste Untersuchungen zeigen bei verschiedenen Qualitätsmetriken einen Trend nach unten, und es gibt anekdotische Hinweise, dass die Modelle sich anschließend selbst immer schwerer tun, den Code zu ändern. Dazu kommt ein technisches Limit: Das Kontextfenster ist begrenzt, und selbst ein voll gefülltes Fenster wird nicht vollständig berücksichtigt. Das Modell pickt Teile heraus und übersieht anderes.
Kann man den Anbieter eines Sprachmodells für fehlerhaften Code haftbar machen?
Nein, das steht im Kleingedruckten. Die Verantwortung für den Code bleibt beim Unternehmen, und es gab Fälle, in denen einzelne Entwickler in die Haftung genommen wurden, weil sie nicht nach Stand der Technik entwickelt und geprüft hatten. Die Hürden dafür sind hoch, aber die Fälle existieren. Bei sicherheitskritischer Software wie einer Airbag-Steuerung entscheidet genau diese Frage.
Wie viele Kommentare eines KI-Code-Reviews sind brauchbar?
Rund 30 Prozent. Über verschiedene Studien und Kundenerfahrungen hinweg, darunter eine Untersuchung einer australischen Universität, liegen die gängigen Werkzeuge bei etwa diesem Anteil guter Review-Kommentare. Der Rest ist irrelevant oder sogar schädlich für das System. Blindes Übernehmen verbessert den Code also nicht, und ein Mensch findet nach dem KI-Review immer noch viele Dinge.
Was kostet der Einsatz starker Modelle für automatische Code-Reviews?
Deutlich mehr als klassische Werkzeuge: Ein KI-Review findet viel von dem, was auch statische Analyse findet, kostet dabei aber etwa den Faktor 1000 mehr. Erste Experimente in Benjamin Hummels Team ergaben über 500 Dollar pro Tag für das gesamte Team, hochgerechnet sechsstellige Beträge im Jahr. Für dieses Geld ließe sich auch eine Testerin oder ein Tester einstellen.
