Letzte Woche habe ich über die letzten 10% geschrieben. Über den Unterschied zwischen „sieht fertig aus" und „ist fertig". Seitdem beschäftigt mich eine Folgefrage, die ich für gefährlicher halte als das ursprüngliche Problem:
Wer merkt überhaupt, dass die 10% fehlen?
Das Prüfproblem
Beim KI-generierten C-Compiler CCC produzieren die Optimierungsstufen -O0 bis -O3 byte-identische Binaries. Die Flags existieren, sie werden akzeptiert, sie erzeugen keine Fehlermeldung. Alles sieht korrekt aus.
Um zu erkennen, dass hier etwas grundlegend nicht stimmt, muss man wissen, was Compiler-Optimierung tun sollte. Man muss wissen, dass -O2 Schleifen entrollen sollte, dass -O3 aggressives Inlining betreibt und dass die resultierenden Binaries sich in Größe und Struktur deutlich unterscheiden müssen. Aus der Dokumentation kommt dieses Wissen nicht. Man erwirbt es in Jahren der Arbeit mit Compilern, beim Lesen von Assembler-Output und beim Debugging von Optimierungsproblemen.
Dass KI fehlerhaften Code schreibt, ist nicht das Problem. Man braucht Erfahrung, um die Fehler zu erkennen, und genau diese Erfahrung ist gerade gefährdet.
Der OCaml-PR aus meinem letzten Artikel illustriert dasselbe Muster aus einer anderen Richtung. Die Copyright-Header nannten einen realen Jane-Street-Entwickler als Autor. Wer das OCaml-Ökosystem nicht kennt, wer nicht weiß, wer Mark Shinwell ist und woran er arbeitet, dem fällt das nicht auf. Die Community erkannte die Halluzination sofort. Sie hatte den Kontext, den der Einreicher nicht hatte.
Prüfkompetenz ist unsichtbar, bis sie fehlt.
Automation Complacency
In der Luftfahrt gibt es ein Phänomen, das seit den 1990er Jahren erforscht wird: Automation Complacency, die schleichende Erosion menschlicher Fähigkeiten durch Übervertrauen in automatisierte Systeme. Piloten, die sich zu stark auf den Autopiloten verlassen, verlieren nach und nach die Fähigkeit, in kritischen Situationen manuell zu fliegen. Das liegt nicht daran, dass sie schlechter werden. Können braucht Übung, und Übung braucht Gelegenheit.
Die Parallele zur Softwareentwicklung ist beunruhigend direkt. Wenn ein Coding-Agent in Sekunden eine Funktion produziert, die „funktioniert", sinkt der Anreiz, den Code im Detail zu verstehen. Warum eine Stunde mit einem Algorithmus ringen, wenn die KI ihn in zehn Sekunden schreibt? Wozu manuell Relocations debuggen, wenn der Agent den Linker-Code generiert, oder sich durch eine Spezifikation arbeiten, wenn das Modell sie „kennt"? Weil man nur prüfen kann, was man versteht, und nur versteht, womit man gerungen hat.
Erfahrung ist kein Zustand
Viele stellen sich Erfahrung als etwas vor, das man irgendwann „hat". Ein Plateau, auf dem man sich ausruhen kann. 35 Jahre Programmierung, also kann ich alles bewerten.
Das ist falsch. Erfahrung ist ein fortdauernder Prozess, und Beobachten allein reicht dafür nicht. Sie entsteht durch Tun: durch das Scheitern an einer Race Condition um zwei Uhr nachts, durch das Debuggen eines Memory Leaks, der erst unter Last auftritt. Oder durch den Moment, in dem ein Test grün ist und die Produktion trotzdem brennt, und man lernt, warum.
Jede Abstraktionsschicht, die man zwischen sich und das Problem legt, ist eine Schicht weniger Erfahrung, die man sammelt. KI-Agenten sind die mächtigste Abstraktionsschicht, die unsere Branche je gesehen hat. Das ist gleichzeitig ihre größte Stärke und ihre größte Gefahr.
Erfahrung lässt sich weder abkürzen noch kaufen, und prompten kann man sie auch nicht. Man kann sie nur machen, und man muss sie immer weiter machen, um sie zu behalten.
Ob ich noch prüfen kann, ist dabei nicht die Frage, ich habe 35 Jahre Kontext. Mich treibt um, ob jemand, der heute anfängt, diesen Kontext jemals aufbauen wird. Wenn die ersten 90% in Sekunden erledigt sind, wann lernt man dann, die fehlenden 10% überhaupt zu sehen?
Was ich in der Praxis tue
Ich bin kein Maschinenstürmer. Ich nutze KI-Coding-Agenten täglich, und sie machen mich produktiver. Aber ich habe die Alternative gesehen und mir deshalb über die letzten Monate Strukturen gebaut, die sicherstellen, dass die Prüfung nicht wegfällt.
Tests vor dem ersten Prompt
Bevor ich einen Agenten auf ein Problem loslasse, schreibe ich selbst die Tests. Das zwingt mich, das Problem zu verstehen, bevor ich es delegiere. Was soll die Funktion tun? Welche Randfälle gibt es, und was darf auf keinen Fall passieren?
Erstaunlich viele Entwickler überlassen dem Agenten gleichzeitig das Problem und die Verifikation und wundern sich dann, dass beides perfekt zusammenpasst und trotzdem falsch ist. Ein Agent, der seinen eigenen Code testet, ist wie ein Schüler, der seine eigene Klausur benotet.
Der Agent bekommt eine Pipeline
Jeder Agent in meinem Workflow hat eine definierte Pipeline: Compile, Lint, Test. Sie ist Pflicht und lässt sich nicht übergehen. Der Agent sieht die Fehler seiner eigenen Arbeit und iteriert. Das fängt die offensichtlichen Probleme ab: Syntaxfehler, fehlende Imports, kaputte Typen.
Aber eine grüne Pipeline beweist keine Korrektheit. Sie ist ein notwendiges Minimum. Die dekorativen Optimierungsstufen von CCC würden jede Pipeline bestehen, die halluzinierten Copyright-Header auch.
Quality Gates als Skripte
Für wiederkehrende Probleme, die mir aufgefallen sind, schreibe ich explizite Prüfskripte: Gibt es offene TODOs im Code? Werden Fehler verschluckt statt behandelt? Gibt es Funktionen ohne Tests? Werden Abhängigkeiten importiert, die nicht im Projekt definiert sind? Das sind automatisierbare Heuristiken. Verständnis ersetzen sie nicht, aber sie sind ein Sicherheitsnetz für die Dinge, die man schon einmal übersehen hat.
Der QA-Loop
Der aufwendigste Teil meines Workflows ist ein Prüfzyklus: Ich lasse einen Agenten die Arbeit eines anderen Agenten überprüfen. Die Findings werden zu Tickets, die Tickets werden abgearbeitet, und dann wird die Überarbeitung erneut geprüft.
Das bildet den Prozess ab, der in guten Software-Teams seit Jahrzehnten funktioniert: Jemand schreibt, jemand anderes prüft, und die Diskussion dazwischen ist der Ort, an dem Verständnis entsteht. Der Unterschied: Im QA-Loop bin ich der Mensch, der die Findings liest und entscheidet, ob sie relevant sind. Der Agent findet Muster, ich bewerte sie. Das setzt voraus, dass ich bewerten kann.
Der stille Kreislauf
In der Softwareentwicklung gibt es einen Kreislauf, der selten ausgesprochen wird:
Um Fehler zu erkennen, braucht man Erfahrung. Erfahrung sammelt man durch Fehler, und Fehler macht man nur, wenn man Gelegenheit dazu hat.
Wenn KI-Agenten den Code schreiben, bevor der Mensch das Problem durchdrungen hat, übernehmen sie die Gelegenheit, Fehler zu machen, und unterbrechen damit diesen Kreislauf. Böswillig ist das nicht, und an schlechten Ergebnissen liegt es auch nicht. Die Ergebnisse sind zu gut und zu bequem, und sie kommen zu schnell: Das nimmt den Anreiz, tiefer zu graben.
Ich beobachte in meinem beruflichen Umfeld eine merkwürdige Bereitschaft, diese Unterbrechung zu akzeptieren. Entwickler automatisieren ihre eigene Lernkurve weg, ohne ihre Fähigkeiten geringzuschätzen. Der kurzfristige Produktivitätsgewinn ist so überzeugend, dass die langfristigen Kosten abstrakt bleiben.
Die letzten 10% werden nicht einfacher. Wenn aber niemand mehr die Erfahrung hat, sie zu erkennen, werden sie unsichtbar, und unsichtbare Probleme sind die gefährlichsten.
Handwerk heißt prüfen können
In meiner ersten Firma in Erfurt, Mitte der 90er, stand auf unserer Website ein Satz: „Die Entwicklung von Software ist heute eine rein ingenieurtechnische Leistung. Dies gehört zu unserem Handwerk."
Handwerk bedeutete dort nicht nur, etwas herstellen zu können, sondern auch, die Qualität des Hergestellten beurteilen zu können. Ein Tischler erkennt an einer Verbindung, ob sie hält, und ein Maurer sieht an einer Mauer, ob sie gerade ist. Ein Softwarehandwerker liest Code und weiß, ob er funktioniert, weil er ihn versteht. Ausführen muss er ihn dafür nicht.
Diese Fähigkeit ist die Grundlage von allem, was danach kommt: Wartung, Debugging, Weiterentwicklung, Sicherheit. Sie entsteht nur durch das, was keine KI einem abnehmen kann: die fortdauernde Praxis des eigenen Tuns, oft mühsam und manchmal frustrierend.
90% fertig ist ein guter Anfang. Wenn wir aber 100 Projekte zu 90% fertig haben, wie viel werden uns dann die 100-mal fehlenden 10% kosten?