# Ihr habt kein Problem mit dem KI-Einsatz. Ihr habt ein Verifikationsproblem. Source: https://normanholz.de/articles/ai-adoption-verification-problem/ Language: de Last updated: 2026-08-14 Reading time: 9 Minuten Lesezeit Erfahrene Entwickler meiden KI-generierten Code aus guten Gründen. Der Engpass ist nicht der KI-Einsatz, sondern der Aufwand, eine Änderung als sicher nachzuweisen. Ein Kunde überlegte vor Kurzem, einen Director of AI Engineering einzustellen. Der Auftrag klang vertraut: mehr KI-Werkzeuge im Einsatz, skeptische Entwickler überzeugen, den Anschluss nicht verlieren. Die Werkzeuge waren längst gekauft und eingeführt. Neue Entwickler wurden gezielt danach ausgesucht, ob sie KI von Anfang an nutzen. Nur der erwartete Anstieg in der Entwicklungsleistung blieb aus. Im Raum stand die übliche Behauptung, Coding-Assistenten könnten die Produktivität von Entwicklern vervielfachen. Wenn ein Entwickler das Fünffache schafft, betreut er vielleicht auch fünf Produkte. Nur: Niemand konnte sagen, was "das Fünffache" überhaupt bedeuten soll. Geschriebene Zeilen Code? Diese Kennzahl ist seit Jahrzehnten wertlos. Commits oder Pull Requests? Sobald man sie zählt, wird für die Zahl optimiert. Tokenverbrauch wäre noch schlechter. Viele Tokens beweisen nur eines: dass viele Tokens verbraucht wurden. Sobald wir aufhörten, über den KI-Einsatz zu reden, und uns die tatsächliche Arbeit ansahen, sah das Problem völlig anders aus. Das Unternehmen hatte kein Problem mit dem KI-Einsatz. Es hatte ein Verifikationsproblem. ## Die erfahrenen Entwickler nutzten KI längst Die erste Vermutung: Erfahrene Entwickler sperren sich gegen die Werkzeuge. In anderen Abteilungen hatte es ja funktioniert. Personal, Beratung und Operations nutzten KI für wiederkehrende Aufgaben, Zusammenfassungen, Entwürfe, Recherche und interne Abläufe. Sie sparten Zeit und steckten sie in wichtigere Arbeit. Im Engineering war es anders. Je erfahrener die Entwickler, desto seltener ließen sie KI an die Software, auf die es ankam. Das klang nach einem Kulturproblem. Es war keines. Die Entwickler nutzten Coding-Assistenten für Prototypen, kleine interne Werkzeuge, Dashboards, Dokumentation und abgegrenzte Hilfsfunktionen. In einem großen, alten, geschäftskritischen Teil des Produkts ließen sie die Finger davon. Genau dieser Unterschied war der Punkt. Das kritische System war über Jahre gewachsen. Fachliche Regeln steckten darin, die nirgends vollständig dokumentiert waren. Kleine Berechnungen bewegten echtes Geld. Eine Änderung, die lokal aussah, konnte Kundenguthaben, Bestellungen, Rechnungen oder nachgelagerte Prozesse treffen. Manche Abkürzung war Absicht, andere eine historische Notwendigkeit. Den Unterschied kannte eine Handvoll erfahrener Entwickler, und zwar aus dem Kopf. Schrieben sie eine Änderung selbst, kannten sie jede Entscheidung darin. Bei generiertem Code mussten sie die Überlegungen eines anderen nachträglich rekonstruieren. Die Prüfung dauerte oft länger als eine eigene Implementierung. Das abzulehnen war kein Widerstand, sondern Berufserfahrung. ## Code zu erzeugen wurde billig. Vertrauen nicht. KI-Werkzeuge senken die Kosten für plausiblen Code. Sie senken nicht automatisch die Kosten für den Nachweis, dass dieser Code stimmt. Je riskanter und komplexer das System, desto größer diese Lücke. In einem kleinen Dashboard ist eine falsche Marge oder ein kaputter Filter ärgerlich. Man behebt sie und spielt neu aus. In einem Modul für Zahlungen, Preise oder Bestellungen kostet derselbe kleine Fehler Geld, beschädigt Daten oder löst einen Kundenfall aus, dessen Bereinigung Tage dauert. Derselbe generierte Diff hat je nach Umgebung völlig unterschiedliche Prüfkosten. Erfahrene Entwickler wissen das intuitiv. Sie fragen nicht nur, ob der Code kompiliert und die Tests grün sind. Sie fragen: - Welche undokumentierte Annahme steckt in dieser Änderung? - Welcher alte Workaround wurde so nebenbei entfernt? - Prüft der Test die fachliche Regel oder nur die Implementierung? - Was passiert mit Daten, die vor fünf Jahren entstanden sind? - Welcher nachgelagerte Prozess hängt an diesem seltsamen Ergebnis? - Kann ich meinen Namen unter diesen Pull Request setzen? Die letzte Frage ist die wesentliche. Die Verantwortung bleibt beim Menschen, der prüft. Das Werkzeug sitzt nachts nicht in der Bereitschaft. Es erklärt dem Kunden keinen Verlust. Es trägt keinen Rollback. Wer nicht effizient Vertrauen aufbauen kann, bekommt durch mehr generierten Code mehr Arbeit, nicht mehr Durchsatz. ## Menge ist die falsche Kennzahl Mengenkennzahlen sind verlockend, weil man sie leicht zählen kann. Codezeilen, Commits, Pull Requests, geschlossene Tickets, Tokens: alles ergibt saubere Dashboards. Keine dieser Zahlen sagt, ob das Unternehmen wertvolle Software besser ausliefert. KI macht diese Kennzahlen noch schlechter, weil sie das Erzeugen von Menge billiger macht. Ein Team kann mehr Code produzieren und dabei Prüfzeit, Nacharbeit, Fehler und Betriebsrisiko gleichzeitig erhöhen. Messt stattdessen, ob validierter Mehrwert erzeugt wird. Hilfreiche Fragen: - Wie lange braucht eine Änderung von der Entscheidung bis zum sicheren Einsatz in Produktion? - Wie viel Prüfzeit kostet sie? - Wie oft wird generierter Code verworfen oder stark überarbeitet? - Wie viele Fehler landen in Produktion? - Wie oft folgt auf eine Änderung ein Rollback oder Nacharbeit? - Hat die Änderung für Kunden oder Geschäft etwas verbessert? Diese Kennzahlen sind unbequemer als die Anzahl der Commits. Dafür liegen sie näher an dem, worauf es dem Unternehmen ankommt. Das Ziel ist nicht möglichst viel Code. Das Ziel ist der kürzeste Weg zu einem Ergebnis, dem man trauen kann. ## Teilt die Software nach Konsequenzen ein Das System des Kunden war keine einheitliche Codebasis. Es enthielt mindestens zwei völlig verschiedene Umgebungen für Änderungen. Die erste: ein geschützter Kern. Alte, komplexe, geschäftskritische Logik. Fehler mit direkten finanziellen oder operativen Folgen. Prüfen ging dort nur mit Fachwissen. Die zweite: eine schnelle Zone. Dashboards, interne Anwendungen, Reporting, Prototypen, Oberflächen. Fehler waren sichtbar, aber reparierbar. Beide Zonen mit derselben KI-Regel zu behandeln, ergab keinen Sinn. In der schnellen Zone kann offensiver KI-Einsatz der Standard sein. Erste Implementierung generieren lassen. In kurzen Schritten arbeiten. Änderungen klein halten. Die wichtigen Pfade testen. Fehler beheben, wenn sie auftauchen. Für den geschützten Kern gilt zunächst das Gegenteil. Keine von Agenten generierten Änderungen in Produktion, solange das Team Verhalten nicht zuverlässig vergleichen und Risiken nicht einschätzen kann. Die erfahrenen Entwickler behalten die Verantwortung. Das ist kein dauerhaftes Verbot, sondern eine Grenze, die sich an Belegen orientiert. Drei Fragen ziehen sie schärfer: 1. Was passiert, wenn die Änderung falsch ist? 2. Wie schnell merken wir das? 3. Wie sicher bekommen wir den vorherigen Zustand zurück? Schwere Folgen, späte Erkennung, mühsame Wiederherstellung: geschützter Kern. Geringe Folgen, schnelle Erkennung, einfache Wiederherstellung: schnelle Zone. Alles dazwischen braucht eine bewusste Entscheidung. ## Baut mit KI zuerst das Sicherheitsnetz Legacy-Systemen fehlen meist die Tests, mit denen sich größere generierte Änderungen prüfen ließen. Für jedes Modul vollständige Tests zu schreiben, dauert zu lange, erst recht wenn das Team nebenbei Funktionen liefern soll. Hier bringen Coding-Agenten Nutzen, bevor sie eine Zeile produktive Logik schreiben. Fangt mit Charakterisierungstests an. Ein Charakterisierungstest hält fest, wie sich ein System heute bei definierten Eingaben verhält. Er behauptet nicht, dass dieses Verhalten richtig ist. Steckt im System ein alter Rundungsfehler oder ein schräger Sonderfall, hält der Test auch den fest. Das ist der Sinn der Sache. Bevor ihr ein System verbessert, müsst ihr merken können, wann ihr es verändert habt. Für ein ausgewähltes Modul läuft das so: 1. Typische Eingaben, Ausgaben, Seiteneffekte und Fehlerfälle bestimmen. 2. Das aktuelle Verhalten in ausführbaren Tests festhalten. 3. Die Tests mit Entwicklern durchgehen, die die Fachlichkeit kennen. 4. Sie gegen die aktuelle Implementierung laufen lassen, das ist die Ausgangsbasis. 5. Den Agenten ein Refactoring oder eine Änderung vorschlagen lassen. 6. Verhalten vergleichen und jede Abweichung untersuchen, ob gewollt oder nicht. Die wiederkehrenden Teile dieser Arbeit liegen Coding-Agenten. Sie lesen vorhandenen Code, sammeln Verzweigungen, schlagen Eingabekombinationen vor, erzeugen Testdaten und gießen beobachtete Ein- und Ausgaben in Tests. Auch das braucht ein Review, aber das Prüfziel ist viel enger. Ihr verlangt vom Agenten nicht, das richtige fachliche Verhalten zu erfinden. Er soll beschreiben, was ohnehin schon da ist. Das lässt sich deutlich sicherer abgeben. ## Testet nicht alles auf einmal Die bequeme Antwort wäre, vollständige Testabdeckung zu fordern, bevor KI überhaupt an das Altsystem darf. Sie sorgt zuverlässig dafür, dass sich monatelang nichts bewegt. Sucht die Module, in denen ein Sicherheitsnetz sofort etwas bringt. Gute Kandidaten erfüllen mehrere dieser Punkte: - Sie ändern sich häufig. - Entwickler machen einen Bogen darum, weil das Risiko unklar ist. - Sie blockieren wertvolle Produktarbeit. - Ihre Ein- und Ausgaben lassen sich beobachten. - Es gab dort schon mehrfach Störungen oder Regressionen. - Ihre Verantwortlichen verbringen zu viel Zeit mit manueller Prüfung. Fangt mit einem Modul an. Baut die Charakterisierungstests. Messt, ob Reviews schneller werden und mehr Sicherheit geben. Wiederholt es dort, wo das Ergebnis den Aufwand rechtfertigt. So wird aus dem KI-Einsatz ein Programm zur Verbesserung des Engineerings statt einer Motivationskampagne. ## Erweitert die Autonomie in Stufen Steht das Sicherheitsnetz, springt trotzdem nicht von "keine KI-Änderungen" direkt zu "der Agent besitzt das Modul". Geht in kleinen Schritten: 1. **Erklären:** Der Agent beschreibt das Modul, seine Abhängigkeiten und die bekannten Risiken. 2. **Charakterisieren:** Er schlägt Tests für das aktuelle Verhalten vor. 3. **Unterstützen:** Er schlägt kleine Änderungen vor, während ein Entwickler die Umsetzung schreibt oder steuert. 4. **Implementieren:** Er baut eng begrenzte Änderungen hinter belastbaren Tests und einem Review. 5. **Betreiben:** Mehr Automatisierung erst dann, wenn Erfahrungen aus der Produktion dafür sprechen. Die genauen Stufen zählen weniger als die Richtung. Vertrauen folgt auf Belege. Nicht umgekehrt. Damit bekommen erfahrene Entwickler eine produktive Rolle. Sie sind kein Hindernis, das man umgeht. Sie wissen, wo das System dünn ist, welches Verhalten zählt und welche Tests echte Sicherheit schaffen. Ihre Erfahrung wird zur Kontrollinstanz für KI-gestützte Entwicklung. ## Die Rolle wurde irrelevant, als das Problem konkret wurde Am Anfang glaubte das Unternehmen, es brauche eine Führungskraft, die Entwickler von KI überzeugt. Am Ende war das nicht mehr die naheliegende Antwort. Die Entwickler brauchten keinen Motivator. Sie brauchten ein sichereres Modell, um Arbeit abzugeben, bessere Verifikation und klare Grenzen für die verschiedenen Teile des Produkts. Damit konnte das vorhandene Team sofort anfangen, mit den Werkzeugen, die es schon hatte. Ein Director of AI Engineering kann sinnvoll sein: bei breiter Plattformstrategie, mehreren KI-Produkten, eigener Modellinfrastruktur, Governance-Anforderungen oder einer großen organisatorischen Einführung. Als Antwort auf zögerlich genutzte Coding-Werkzeuge ergab die Rolle keinen Sinn. Stellt niemanden ein, der Widerstand auflösen soll, bevor ihr wisst, wogegen sich die Leute wehren. Wenn erfahrene Entwickler KI in einem Teil des Systems meiden, schaut auf die Folgen eines Fehlers. Schaut auf den Prüfaufwand. Schaut auf die fehlenden Tests. Schaut darauf, wer am Ende geradesteht. Wenn generiertem Code schwer zu trauen ist, ist der KI-Einsatz nicht das erste Problem. Macht die Verifikation billiger. Der Einsatz der Tools kommt von selbst.