Warum KI-generierter Code ohne Verifizierung zum Wartungsrisiko wird

KI-basierte Codegenerierung hat einen Wendepunkt erreicht. Doch während die Implementierung exponentiell beschleunigt wird, hinkt die Verifizierung hinterher – und das wird zum größten Risiko für Softwareprojekte.

Nach 47 Tagen, 1.384 Commits und über 250 Spezifikationsdateien in Obsidian funktionierte mein System endlich. Die Features waren implementiert, die Tests liefen grün, die Pull Requests wurden gemerged. Doch statt Erleichterung spürte ich nur den dringenden Impuls, den gesamten Codebase wegzuwerfen.

Nicht, weil KI schlecht codet. Sondern weil sie zu viel, zu schnell und mit zu viel Selbstvertrauen schreibt. Die eigentliche Herausforderung lag nicht in der Umsetzung, sondern in der Frage: Wie weit kann man autonome KI-Coding-Prozesse in komplexen Projekten treiben, ohne die Kontrolle zu verlieren?

Meine Antwort war ernüchternd: sehr weit – aber nicht besonders vertrauenswürdig.

Irgendwann wurde die Implementierung nicht mehr zum Engpass. Die KI schrieb Code schneller, als ich ihn überprüfen konnte. Das schuf eine neue Art von Schulden – keine klassische technische Schuldenlast, sondern eine Validierungsschulden, die sich in Reviews, Debugging-Sessions und zukünftigen Refactorings rächt.

Wenn KI den Implementierungsprozess überholt

Bei der Codeprüfung durch menschliche Entwicklerinnen und Entwickler greifen unbewusste Mustererkennung und Kontextwissen. Man kennt die Arbeitsweise des Teams, die Architektur des Projekts und die akzeptablen Kompromisse.

Bei KI-generiertem Code fällt dieser Kontext plötzlich weg.

Die Lösungen, die die KI fand, funktionierten oft technisch. Doch sie passten selten zu den bewährten Mustern des Teams. Mal waren sie zu clever, mal unnötig komplex, mal lokal richtig, aber architektonisch falsch.

Jede Review begann bei null.

Es reichte nicht mehr aus, nur die Funktionalität zu prüfen. Man musste verstehen, warum der Code so gebaut wurde. Ob er zur Architektur passte. Ob die Tests überhaupt etwas bewiesen. Ob ein Fix nur Symptome kaschierte. Ob ein neuer Helfer in drei Wochen zum Problem werden würde.

Die KI hatte die Implementierungsgeschwindigkeit überholt. Anfangs fühlte sich das wie ein Durchbruch an.

Dann begann es sich wie Kontrollverlust anzufühlen.

Am Ende stand ein System, das formal funktionierte – praktisch aber nicht mehr wartbar war. Von 25 gemergten Pull Requests lief die Anwendung, doch der Code sah so schlecht aus, dass ich ihn nicht einmal mehr ansehen wollte, geschweige denn debuggen.

Das Problem war nicht, dass KI schlechten Code schreibt.

Das Problem war, dass wir zuließen, dass er funktioniert, ohne gleich schnell verifiziert zu werden.

Das vergessene Entwicklungsprinzip: Keine Implementierung ohne Verifizierung

Irgendwann erinnerte ich mich an ein Grundprinzip der Softwareentwicklung, das wir alle irgendwann auf die harte Tour lernen:

Es gibt keine Implementierung ohne Verifizierung.

Das ist kein abstraktes Ideal. Es ist der Kern jeder Softwareentwicklung.

Wir bauen etwas. Wir prüfen es. Wir passen es an. Wir prüfen erneut.

Nur so entsteht Vertrauen.

Bei Code, den wir schon hundertmal geschrieben haben, wird dieser Loop fast unsichtbar. Wir kennen die Fehlerquellen, wir erkennen Probleme beim Tippen, wir wissen, was funktioniert.

Mit KI passiert etwas anderes:

Wir geben die Implementierung ab, behalten aber die Verifizierung.

Das schafft ein asymmetrisches Workflow:

KI-Speed-Implementierung. Menschliche Verifizierungsgeschwindigkeit.

Das skaliert nicht.

Diese Erkenntnis ist nicht neu. Gleichzeitig tauchte sie in verschiedenen Formen bei großen KI-Laboren und Technikführungskräften auf. Anthropic formuliert es in seinen Claude-Code-Best-Practices klar: „Wenn du es nicht verifizieren kannst, schicke es nicht in Produktion.“ Addy Osmani, Leiter der Developer Experience bei Google Chrome, bringt es auf den Punkt: „Deine Aufgabe ist es, Code zu liefern, den du als funktionierend bewiesen hast.“

Die eigentliche Einsicht war nicht: Ich brauche bessere Prompts.

Die Einsicht war:

Was KI implementiert, muss KI auch beweisen.

Nicht am Ende eines langen Runs. Nicht als nachträgliche Zusammenfassung. Nicht als freundliche Aussage wie „Ich habe das geprüft“.

Sondern während des Prozesses. Schritt für Schritt. Kriterium für Kriterium. Mit Beweisen, die nicht von derselben Instanz stammen, die den Code geschrieben hat.

Ab diesem Moment hörte ich auf, nach besseren Prompts zu suchen.

Ich begann, nach Workflows zu suchen, in denen Verifizierung keine Option war, sondern eine Notwendigkeit.

Warum Prompts allein nicht ausreichen

Mein erster Ansatz war naheliegend: Ich schrieb bessere Spezifikationen.

In Obsidian übertrug ich Akzeptanzkriterien direkt in die Spezifikationsdateien. Jede Aufgabe bekam eine Checkliste – ähnlich einem Projektmanagement-Tool, aber viel näher am Code.

Das half sofort.

Zum ersten Mal konnte ich pro Aufgabe sehen, was tatsächlich erfüllt werden sollte. Die KI arbeitete strukturierter. Sie korrigierte sich häufiger selbst. Reviews wurden einfacher. Commits wurden sauberer. Prompts wurden seltener.

Doch das Kernproblem blieb bestehen.

Denn eine Anweisung in einem Prompt ist keine Garantie.

Eine KI kann sagen: „Bitte prüfe alle Kriterien.“

Doch sie kann eines überspringen. Sie kann den Überblick während langer Läufe verlieren. Sie kann behaupten, etwas sei geprüft, obwohl es das nicht ist. Sie kann auf einen Test verweisen, der das Kriterium überhaupt nicht abdeckt. Am Ende einer langen Session kann sie eine gut klingende Zusammenfassung liefern, die sich wahr anfühlt – aber keine verlässliche Spur hinterlässt.

Das ist der Unterschied zwischen einer Regel und einer Grenze.

Eine Regel sagt: Bitte mach es so.

Eine Grenze sagt: Du darfst nicht weitermachen, bis das erledigt ist.

Bei KI-Coding spielt dieser Unterschied eine entscheidende Rolle.

Wenn Verifizierung nur im Prompt lebt, ist sie Teil des Agentenverhaltens.

Wenn Verifizierung Teil der Infrastruktur wird, wird sie zur Systemanforderung.

Verifizierung muss in das Datenmodell integriert werden

Die nächste Version meines Workflows basierte auf einer einfachen Annahme:

Ein Akzeptanzkriterium darf nicht nur im Text stehen. Es muss in die Datenstruktur eingebettet sein.

Das bedeutet konkret:

• Jedes Kriterium wird als strukturiertes Objekt mit Prüfregeln, Abhängigkeiten und Nachweisen modelliert.
• Die KI kann nur dann einen Schritt abschließen, wenn alle zugehörigen Kriterien durch Nachweise belegt sind.
• Die Nachweise müssen in einem Format vorliegen, das unabhängig von der KI verifizierbar ist – etwa als automatisierte Testausführung, manuelle Überprüfungsprotokolle oder Code-Reviews durch menschliche Entwickler.

Dieser Ansatz erzwingt einen symmetrischen Workflow:

KI implementiert und dokumentiert. Das System prüft und validiert.

Plötzlich wird Verifizierung nicht mehr zur optionalen Aufgabe, sondern zur systemischen Voraussetzung.

Die KI kann nicht mehr einfach „fertig“ sagen. Sie muss beweisen, dass sie fertig ist.

Und dieses „Beweisen“ muss für Menschen nachvollziehbar sein – nicht nur für die KI selbst.

Die Zukunft: KI-Coding als Teamwork mit klaren Verantwortlichkeiten

Die Ära des „KI schreibt, Mensch prüft“ muss enden.

Stattdessen brauchen wir Workflows, in denen KI und menschliche Entwickler klar getrennte Rollen haben:

• Die KI verantwortet die Implementierung.
• Das System verantwortet die Verifizierung.
• Die Entwickler verantworten die Architektur und die finalen Freigaben.

Das erfordert neue Tools, neue Prozesse und eine neue Kultur des Vertrauens – aber vor allem eines:

Eine Abkehr von der Vorstellung, dass KI irgendwann „fertig“ ist, wenn sie sagt, sie sei fertig.

Echte Reife entsteht nicht durch Geschwindigkeit, sondern durch Verlässlichkeit.

Und Verlässlichkeit entsteht nur dort, wo Verifizierung genauso ernst genommen wird wie die Implementierung selbst.