Mehr Code, nicht mehr Software: Warum KI-Webprojekte prüfbarer gebaut werden müssen

Den Unterschied macht nicht das Modell, sondern ob ein Projekt von Anfang an prüfbar angelegt ist.

Die Oberfläche steht, die API antwortet, die Tests sind grün. In wenigen Stunden hat ein Coding-Agent aus einer Anforderung das Grundgerüst eines Kundenportals gebaut: Benutzerkonten, Rechnungsübersicht, Anbindung an die Warenwirtschaft. Im Review taucht dann eine Frage auf, die kein grüner Test beantwortet hat: Kann ein angemeldeter Kunde auch die Rechnungen eines anderen abrufen?

Was solche Momente in Summe bedeuten, zeigen zwei aktuelle Studien, deren Ergebnisse sich auf den ersten Blick ausschließen. Ökonomen der Harvard University haben die Entwicklungsdaten von 718 Softwareunternehmen ausgewertet. Nach Einführung von Coding-Agenten schrieben die Teams rund 30 Prozent mehr Code. Die Zeit vom Pull Request bis zum Merge stieg jedoch um 49 Prozent, während sich bei der Zahl abgeschlossener Aufgaben kein statistisch signifikanter Anstieg nachweisen ließ.

Bei Meta dagegen, wo Forschende mehr als 400.000 Code-Änderungen von über 10.000 Entwicklern zeichengenau zurückverfolgt haben, liefen Änderungen mit KI-Anteil schneller durch den Review und lösten seltener Produktionsvorfälle aus. Allerdings landete der KI-Code dort auffallend oft in Testdateien und Randbereichen, selten im Kern der Systeme.

Beide Arbeiten sind vorläufig: die eine ein noch nicht begutachtetes Job Market Paper, die andere eine ausdrücklich als „preliminary“ bezeichnete Konferenzstudie. Zusammen erzählen sie dennoch eine klare Geschichte. Zusammen zeigen sie, wie stark die Ergebnisse vom Entwicklungskontext abhängen. Nicht allein die Leistungsfähigkeit der Modelle zählt, sondern auch die Art der Aufgaben, die Architektur der Systeme und die Qualität der bestehenden Prüfprozesse.

Der Engpass heißt Verifikation

Dass sich die Arbeit vom Schreiben zum Prüfen verschiebt, ist in der Branche angekommen. Auch eine Befragung unter Entwicklern, über die it-daily berichtete, nennt die Qualitätssicherung als Nadelöhr des Vibe Coding. Die Harvard-Daten zeigen, wie konkret das ist. Der Anteil der Pull Requests, bei denen Reviewer Änderungen verlangen, hat sich nach Einführung der Agenten etwa verdoppelt. Fast 80 Prozent der untersuchten Firmen nutzten bis März 2026 KI-gestützte Review-Werkzeuge, trotzdem stammten nur 23 Prozent der Review-Kommentare von einer Maschine. Den Rest schrieben Menschen, und deren Zeit wächst nicht mit.

Googles DORA-Team nennt diesen Effekt in seinem Bericht zum Return on Investment KI-gestützter Entwicklung eine „Verification Tax“ und beschreibt eine J-Kurve:

Die Produktivität kann zunächst sinken, wenn Tests, Freigaben und eingespielte Prozesse mit dem steigenden Entwicklungsvolumen nicht Schritt halten.

Die naheliegende Antwort lautet: mehr Review-Kapazität. Die wirtschaftlichere: Projekte so anlegen, dass weniger und leichter geprüft werden muss.

Prüfbarkeit beginnt vor der ersten generierten Zeile

Wie hoch der spätere Prüfaufwand ausfällt, hängt auch von Entscheidungen ab, die getroffen werden, bevor ein Agent die erste Datei anlegt. Drei Hebel sind dabei zentral.

Spezifikation statt Prompt

Ein Agent, der nur eine grobe Aufgabenbeschreibung erhält, muss fehlende Vorgaben selbst ergänzen. Im Kundenportal sind das Lücken wie diese: Welche Daten darf ein Nutzer lesen? Welche Operationen sind Administratoren vorbehalten? Was passiert, wenn die Warenwirtschaft nicht antwortet, und welcher Zustand darf nach einem abgebrochenen Vorgang zurückbleiben? Bleiben diese Fragen offen, muss der Agent Annahmen treffen, die fachlich oder sicherheitstechnisch falsch sein können. Wer dagegen Datenmodell, Schnittstellenverträge, Berechtigungsmodell und Design Tokens maschinenlesbar vorgibt, verwandelt offene Fragen in prüfbare Regeln.

Wie wenig die Spezialisierung eines Modells allein über die Sicherheit seines Codes aussagt, zeigt der GenAI Code Security Report 2026 von Veracode. Ohne sicherheitsbezogene Vorgaben bestanden die getesteten Modelle im Schnitt nur 56 Prozent der Sicherheitsprüfungen. Auf Code spezialisierte Modelle schnitten mit 51 Prozent nicht besser ab als allgemeine mit 52.

Ein auf Programmierung spezialisiertes Modell ist damit noch keine Sicherheitsgarantie. Ob der erzeugte Code den Anforderungen eines produktiven Systems genügt, hängt auch von klaren Sicherheitsvorgaben und unabhängigen Prüfverfahren ab. Damit werden die Vorgaben allerdings selbst zum Angriffsziel: Das OWASP-Cheat-Sheet zur sicheren KI-gestützten Programmierung stuft Regeldateien für Agenten ausdrücklich als sicherheitskritische Konfiguration ein.

Unabhängige Tests als Abnahmekriterien

Grüne Tests beweisen zunächst nur, dass Code und Tests zueinander passen. Schreibt derselbe Agent beides, prüft der Test im Zweifel, was der Code tut, nicht was er tun soll. OWASP warnt vor einem noch subtileren Muster: Agenten, die Tests ändern dürfen, schwächen sie mitunter ab oder entfernen sie, bis die Pipeline grün meldet. Abnahmekriterien gehören deshalb vor die Implementierung, abgeleitet aus fachlichen Anforderungen und in menschlicher Verantwortung. Das schließt Negativtests ein. Für das Kundenportal genügt kein Test, der zeigt, dass ein Kunde seine Rechnungen sieht. Ebenso muss belegt sein, dass er die eines fremden Kontos nicht abrufen kann. KI kann solche Tests formulieren, ausführen und pflegen. Festlegen, was sie beweisen müssen, kann sie nicht.

Prüffläche verkleinern

Jede zusätzliche Laufzeitkomponente kann den Aufwand für Prüfung, Wartung und Absicherung vergrößern. Webprojekte bieten hier ungewöhnlich viel Spielraum. Inhalte, die sich selten ändern, lassen sich vorab generieren und statisch ausliefern. Kritische Funktionen wie Authentifizierung, Formulare mit personenbezogenen Daten oder Zahlungsprozesse lassen sich in wenigen, gezielt geprüften Diensten bündeln. Das ist kein Dogma: Auch eine statisch ausgelieferte Website kann über ein CMS redaktionell gepflegt werden. Ob eine dynamische oder statische Architektur sinnvoller ist, hängt von den Anforderungen an Inhalte, Interaktionen und Betrieb ab.

Dasselbe gilt für die Agenten selbst: minimale Rechte, getrennte Entwicklungs-, Test- und Produktionsumgebungen, keine Zugangsdaten zu Live-Systemen. Ein Agent, der Abhängigkeiten installiert und Shell-Befehle ausführt, ist ein Akteur mit Rechten, keine Autovervollständigung. Auch Repository-Inhalte sind nicht automatisch vertrauenswürdig: Über manipulierte Dateien können Anweisungen in seinen Arbeitskontext gelangen.

Prüfaufwand nach Risiko staffeln

Der zweite Teil der Antwort auf das Harvard-Meta-Rätsel liegt in der Frage, wer was prüft. Meta hat mit RADAR ein System beschrieben, das risikoarme Code-Änderungen automatisch freigibt. Ein Risiko-Score schätzt die Wahrscheinlichkeit eines Produktionsvorfalls, ein Sprachmodell begutachtet den Code, deterministische Prüfungen sichern ab. Regulatorisch relevanter Code ist von vornherein ausgenommen. Bei mehr als 535.000 bewerteten Änderungen wurden die automatisch freigegebenen nur etwa ein Drittel so häufig zurückgenommen wie die übrigen und lösten nur rund ein Fünfzigstel so viele Produktionsvorfälle aus. Das überrascht wenig, denn ausgewählt wurden gezielt die risikoarmen Fälle. Es sind Beobachtungsdaten aus einem Konzern-Monorepo, keine Blaupause.

Das Prinzip aber lässt sich übertragen. Auch in Webprojekten haben Änderungen sehr unterschiedliche Fallhöhen. Eine Textkorrektur oder ein angepasstes Stylesheet verdient einen prüfenden Blick, Änderungen an Anmeldung, Zahlungsabwicklung oder Gesundheitsdaten eine Prüfung Zeile für Zeile. Wer diese Klassen vorab definiert und in der Pipeline verankert, etwa über geschützte Branches und verpflichtende Prüfungen für sensible Komponenten, lenkt die knappe menschliche Aufmerksamkeit dorthin, wo sie Schaden verhindert. Wie kritisch eine Änderung ist, sollte dabei nicht der Agent bewerten, der sie geschrieben hat. Für KI-generierten Code zieht OWASP die Grenze bewusst konservativ: Eine maschinelle Freigabe soll das menschliche Review nicht ersetzen, und jede Änderung braucht einen verantwortlichen Menschen. Automatisierung legt also fest, wie gründlich geprüft wird, nicht ob.

Was das für Auftraggeber bedeutet

Für Unternehmen, die ein Webprojekt vergeben, folgt daraus eine unbequeme, aber nützliche Erkenntnis. KI macht anspruchsvolle Projekte nicht automatisch günstiger. Sie kann den Aufwand verlagern: weg von der reinen Implementierung, hin zu Spezifikation, Architektur und Verifikation. Dafür rücken Lösungen in Reichweite, deren individuelle Entwicklung bislang unverhältnismäßig aufwendig gewesen wäre. Die aufschlussreichere Frage an eine Agentur lautet daher nicht, welche KI-Werkzeuge sie einsetzt, sondern wie sie prüft, was diese Werkzeuge erzeugen.

Bei der Webdesign Agentur tpi Media hat man diese Konsequenz früh gezogen:

„Dass der eigentliche Engpass nicht beim Schreiben von Code liegt, sondern beim Prüfen, haben wir in unseren Projekten schon länger beobachtet“, sagt Robert Kühne, COO. „Deshalb stehen bei uns am Anfang und am Ende eines jeden Projekts Menschen: Die Architektur entwerfen wir selbst, die Freigabe erteilen wir selbst. Dazwischen arbeitet kein einzelner Agent, sondern ein System aus Schleifen und Feedbackloops die an deterministische Hooks gekoppelt sind. Coding-Agenten verteilen Teilaufgaben an Sub-Agenten, eigene Prüfagenten gleichen jedes Ergebnis mit der Spezifikation ab, und Hooks lösen an festen Punkten Prüfungen aus, die kein Agent überspringen kann. Echte Kundendaten bekommen die Agenten dabei nicht zu sehen. In diesen Schleifen steckt das eigentliche Handwerk: Sie reduzieren nicht die menschliche Verantwortung, sondern schaffen die Grundlage für eine gezieltere und verlässlichere abschließende Prüfung.“

Schneller prüfen, nicht nur schneller bauen

Ob die Frage nach den fremden Rechnungen vor dem Launch gestellt wird oder erst nach einem Sicherheitsvorfall, hängt nicht an der Zahl erzeugter Codezeilen, sondern daran, ob Anforderungen, Architektur und Prüfverfahren von Anfang an zusammenspielen. Wer KI lediglich schneller programmieren lässt, beschleunigt zunächst nur die Produktion. Wer ihre Ergebnisse zuverlässig überprüfbar macht, schafft die Voraussetzungen für mehr fertige, tragfähige Software.