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, dass die resultierenden Binaries sich in Größe und Struktur deutlich unterscheiden müssen. Dieses Wissen kommt nicht aus der Dokumentation. Es kommt aus Jahren der Arbeit mit Compilern, aus dem Lesen von Assembler-Output, aus dem Debugging von Optimierungsproblemen.
Das Problem ist nicht, dass KI fehlerhaften Code schreibt. Das Problem ist, dass man Erfahrung braucht, um die Fehler zu erkennen, und dass genau diese Erfahrung gerade gefährdet ist.
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? Warum manuell Relocations debuggen, wenn der Agent den Linker-Code generiert? Warum sich durch eine Spezifikation arbeiten, wenn das Modell sie „kennt"?
Die Antwort ist unbequem: Weil man nur prüfen kann, was man versteht. Und man versteht nur, womit man gerungen hat.
Erfahrung ist kein Zustand
Es gibt eine verbreitete Vorstellung, dass Erfahrung etwas ist, 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. Sie entsteht nicht durch Beobachten, sondern durch Tun. Durch das Scheitern an einem Race Condition um zwei Uhr nachts. Durch das Debuggen eines Memory Leaks, der erst unter Last auftritt. 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 kann man nicht abkürzen, nicht kaufen und nicht prompten. Man kann sie nur machen. Und man muss sie immer weiter machen, um sie zu behalten.
Was mich dabei umtreibt, ist nicht die Frage, ob ich noch prüfen kann, ich habe 35 Jahre Kontext. Es ist die Frage, 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 mir über die letzten Monate Strukturen gebaut, die sicherstellen, dass die Prüfung nicht wegfällt. Weil ich die Alternative gesehen habe.
Tests vor dem ersten Prompt
Bevor ich einen Agenten auf ein Problem loslasse, schreibe ich Tests. Nicht der Agent. Ich. Das zwingt mich, das Problem zu verstehen, bevor ich es delegiere. Was soll die Funktion tun? Was sind die Randfälle? Was darf auf keinen Fall passieren?
Das klingt offensichtlich. Aber es ist erstaunlich, wie viele Entwickler dem Agenten gleichzeitig das Problem und die Verifikation überlassen, und sich dann wundern, 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. Nicht optional, nicht übergehbar. 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 ist kein Beweis für Korrektheit. Sie ist ein notwendiges Minimum, kein hinreichendes Kriterium. 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. Kein Ersatz für Verständnis, aber 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, der zählt: 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. Und damit sind wir wieder beim Kern des Problems.
Der stille Kreislauf
In der Softwareentwicklung gibt es einen Kreislauf, der selten ausgesprochen wird:
Man braucht Erfahrung, um Fehler zu erkennen. Man braucht Fehler, um Erfahrung zu sammeln. Man braucht Gelegenheit, um Fehler zu machen.
Wenn KI-Agenten die Gelegenheit übernehmen, Fehler zu machen, weil sie den Code schreiben, bevor der Mensch das Problem durchdrungen hat, dann unterbrechen sie diesen Kreislauf. Nicht böswillig. Nicht durch schlechte Ergebnisse. Sondern durch zu gute, zu schnelle, zu bequeme Ergebnisse, die den Anreiz nehmen, tiefer zu graben.
Ich beobachte in meinem beruflichen Umfeld eine merkwürdige Bereitschaft, diese Unterbrechung zu akzeptieren. Entwickler automatisieren ihre eigene Lernkurve weg. Nicht weil sie ihre Fähigkeiten geringschätzen, sondern weil der kurzfristige Produktivitätsgewinn so überzeugend ist, dass die langfristigen Kosten abstrakt bleiben.
Die letzten 10% werden nicht einfacher. Aber wenn 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. Es bedeutete, die Qualität des Hergestellten beurteilen zu können. Ein Tischler erkennt an einer Verbindung, ob sie hält. Ein Maurer sieht an einer Mauer, ob sie gerade ist. Ein Softwarehandwerker liest Code und weiß, ob er funktioniert. Nicht weil er ihn ausführt, sondern weil er ihn versteht.
Diese Fähigkeit ist kein Luxus. Sie ist die Grundlage von allem, was danach kommt: Wartung, Debugging, Weiterentwicklung, Sicherheit. Und sie entsteht nur durch das, was keine KI einem abnehmen kann: die fortdauernde, oft mühsame, manchmal frustrierende Praxis des eigenen Tuns.
90% fertig ist ein guter Anfang. Aber hier eine Warnung: Wenn wir 100 Projekte zu 90% fertig haben, wieviel werden uns dann die 100 mal fehlenden 10% kosten?