In den letzten Monaten hat sich etwas in der Softwareentwicklung verschoben. KI-Coding-Agenten wie Claude Code, GitHub Copilot oder Cursor produzieren Code, der auf den ersten Blick professionell aussieht. Manchmal sogar beeindruckend. Anthropic lässt Claude einen kompletten C-Compiler schreiben. Ein Entwickler lässt KI einen DWARF-Debugger für OCaml implementieren. Die Ergebnisse sehen fertig aus.
Aber sind sie es?
Wir arbeiten mit Wahrscheinlichkeiten
Was man über große Sprachmodelle verstehen muss: Sie arbeiten mit Wahrscheinlichkeiten. Jedes generierte Token ist eine statistische Vorhersage, das wahrscheinlichste nächste Wort basierend auf dem Kontext. Das funktioniert erstaunlich gut. Oft sogar besser als erwartet.
Aber „wahrscheinlich richtig" und „richtig" sind zwei grundverschiedene Dinge.
Vereinfacht ausgedrückt: Wenn ein Modell bei jedem einzelnen Token eine Genauigkeit von 99% erreicht (was bemerkenswert wäre), dann liegt bei einer Funktion mit 500 Tokens die Wahrscheinlichkeit, dass alles korrekt ist, bei 0,99500 ≈ 0,7%. Die Mathematik der Wahrscheinlichkeiten ist unbarmherzig.
In der Praxis bedeutet das: Je größer und komplexer ein Projekt wird, desto mehr akkumulieren sich kleine Ungenauigkeiten. Und genau dort beginnen die interessanten letzten 10%.
Fall 1: Claude baut einen C-Compiler
Anthropic hat im Februar 2026 Claude’s C Compiler (CCC) vorgestellt: ein in Rust geschriebener C-Compiler, bei dem 100% des Codes von Claude Opus 4.6 stammt. Ein Mensch hat nur die Testfälle geschrieben. Das Ergebnis: Frontend, SSA-basierte IR, Optimizer, Code-Generator, Assembler, Linker und DWARF-Debug-Info. Alles from scratch, ohne Compiler-spezifische Dependencies.
Die Schlagzeile: „Kann den Linux-Kernel kompilieren."
Die Realität ist differenzierter. Ein unabhängiger Benchmark von Harshanu zeigt, was in den Details steckt:
- Korrektheit: CCC kompilierte alle 2.844 C-Dateien des Linux-Kernels fehlerfrei. Beeindruckend.
- Linker-Problem: Der Build scheiterte dann mit 40.784 undefined-reference-Fehlern. CCC generiert fehlerhafte Relocations für
__jump_tableund__ksymtab. Der Compiler funktioniert. Der Linker nicht. - Performance: CCC-kompiliertes SQLite braucht 2 Stunden für einen Benchmark, den GCC in 10 Sekunden schafft. Bei Subqueries: 158.000x langsamer.
- Optimierung: Die Flags
-O0bis-O3produzieren byte-identische Binaries. Die Optimierungsstufen sind dekorativ.
Die Ursache ist technisch aufschlussreich: CCC hat kein vernünftiges Register-Allocation. Statt Variablen in CPU-Registern zu halten, schiebt es alles über den Stack, mit Offsets bis zu 11.000 Bytes Tiefe. Jede Operation wird zu stack → rax → stack, wobei %rax als einziger Shuttle-Register dient.
„The assembly output reminds me of the quality of an undergraduate’s compiler assignment." — Kommentar auf GitHub Issue #1, in dem „Hello World" nicht kompilierte
Der Compiler ist zu 90% fertig. Er parst C, er generiert Maschinencode, er versteht die Architektur. Aber die letzten 10% (effizientes Register-Allocation, korrekte Relocations, funktionierende Optimierungspasses) sind die Dinge, an denen GCC seit 1987 mit tausenden Entwicklern arbeitet.
Fall 2: KI schreibt einen DWARF-Debugger für OCaml
Ein noch aufschlussreicherer Fall spielte sich im OCaml-Repository ab. Ein Entwickler reichte einen Pull Request ein: DWARF v5 Debugging Support für den OCaml Native Compiler. In der Beschreibung: ein sauber strukturiertes Feature mit Core DWARF Support, Platform-Unterstützung für Linux und macOS, einem LLDB-Plugin und einer Testsuite.
Dann kam die Community-Review.
Erste Frage: Die Copyright-Header nannten Mark Shinwell als Autor, einen Jane-Street-Entwickler, der tatsächlich an ähnlichem Code im oxcaml-Repository arbeitete. Hat die KI Code kopiert oder die Attribution halluziniert?
Die Antwort des Einreichers:
„Claude Sonnet 4.5 (Claude Code) wrote most of it with ChatGPT 5 (Codex) reviewing and Claude addressing issues in each review. Codex wrote the last 10% or so when Claude kept getting stuck. I did not write a single line of code."
Der PR wurde geschlossen. Nicht weil der Code nicht funktionierte. Sondern aus grundlegenderen Gründen:
- Copyright: Die KI hat Copyright-Header eines realen Menschen generiert. Das ist ein juristisches Problem.
- Wartbarkeit: Tausende Zeilen Code, die niemand (auch nicht der Einreicher) im Detail versteht, können von einer Community nicht gewartet werden.
- Prozess: Es gab keine Design-Diskussion. Kein Review durch die Personen, die den Code langfristig pflegen müssen.
Der OCaml-Maintainer formulierte es diplomatisch: Es sei ein Fall von „different-to-the-point-of-being-incompatible software development processes". Was er damit meinte: Software-Entwicklung ist mehr als Code produzieren.
Fall 3: Die Sicherheitsperspektive
Ich habe jahrelang an Systemen gearbeitet, bei denen Korrektheit keine Ermessensfrage war. Wenn ich mir den CCC-Compiler aus dieser Perspektive anschaue, sehe ich ein Muster, das mir Sorgen macht.
Für jemanden, der Sicherheits- oder Infrastrukturverantwortung trägt, ist „meistens korrekt" kein Qualitätsmerkmal. Es ist ein Risiko. Ein Compiler, der in der Mehrzahl der Fälle valide Binaries produziert, aber bei bestimmten Konstellationen fehlerhafte Relocations generiert, ist nicht zuverlässig.
Ein Linker, der „fast alle" Symbole korrekt auflöst, erzeugt keine robuste Software. Er erzeugt Laufzeitfehler, die sich kaum reproduzieren lassen. Ein DWARF-Generator, der nur ungefähr spezifikationskonform arbeitet, macht die gesamte Fehlersuche unbrauchbar.
In sicherheitsrelevanten Kontexten gibt es keinen graduellen Zustand zwischen sicher und unsicher. Eine Tür, die nur in neun von zehn Fällen verriegelt, erfüllt ihre Funktion nicht. Dasselbe gilt für Compiler, kryptografische Implementierungen, Zugriffskontrollsysteme oder medizinische Software. Wo Korrektheit nicht verhandelbar ist, reicht „wahrscheinlich richtig" nicht aus. Genau hier kollidiert die probabilistische Natur aktueller KI-Systeme mit den Anforderungen, die wir an Technik stellen, der wir vertrauen.
Was steckt in den letzten 10%?
Wenn man die Fälle zusammennimmt, kristallisiert sich heraus, was die letzten 10% eigentlich sind:
Edge Cases und Spezifikationstreue. Ein C-Compiler muss nicht nur typischen Code kompilieren, sondern auch obskure Corner Cases der Spezifikation korrekt behandeln. GCC hat dafür 40 Jahre Bug-Reports.
Performance-Engineering. Funktionierender Code und effizienter Code sind verschiedene Dinge. CCC zeigt das drastisch: korrekte Ergebnisse, aber 158.000x langsamer bei bestimmten Operationen.
Integration in bestehende Systeme. Software existiert nicht isoliert. Der OCaml-PR scheiterte nicht am Code selbst, sondern an der Integration in einen Community-Prozess, an Copyright-Fragen, an Wartbarkeit.
Die Fähigkeit, das eigene Werk zu erklären. Wenn der Einreicher eines PRs den Code nicht erklären kann, weil er ihn nicht geschrieben hat, fehlt das tiefe Verständnis, das für Debugging, Wartung und Weiterentwicklung nötig ist.
Determinismus. Sicherheitskritische Systeme brauchen deterministische, verifizierbare Ergebnisse. Keine statistischen Annäherungen.
Wer macht die letzten 10%?
Das ist der paradoxe Teil.
Die letzten 10% erfordern genau die Expertise, die man nur durch jahrelange Praxis aufbaut. Register-Allocation verstehen heißt, CPU-Architekturen verstehen. Korrekte Relocations schreiben heißt, ELF-Binärformate verstehen. Code reviewbar machen heißt, Software-Engineering als sozialen Prozess verstehen.
Das sind Fähigkeiten, die man nicht durch Prompting erlernt.
Die Ironie: Wenn wir eine Generation von Entwicklern ausbilden, die mit KI die ersten 90% überspringt, wer entwickelt dann die Expertise für die letzten 10%? Das ist keine rhetorische Frage. Das ist die zentrale Herausforderung der nächsten Jahre in unserer Branche. Das Problem ist nicht nur das Überspringen, sondern dass die “Junior-Tasks”, an denen man früher gelernt hat (die “Drecksarbeit”), jetzt wegfallen. Man lernt Compilerbau nicht, indem man dem Senior zuschaut, sondern indem man erst mal einen Parser schreibt. Wenn die KI das macht, fehlt das Trainingsgelände.
„There will always be room for individuals to write software based on their unique knowledge. The craft of writing software will not become obsolete." — Freeman Dyson, 1998
Dieses Zitat stand auf der alten Version dieser Webseite, als ich sie 2011 gründete. Es ist heute aktueller denn je.
Was bedeutet das für die Praxis?
Ich nutze KI-Tools täglich. Sie sind hervorragend für Boilerplate, für das Erkunden von APIs, für erste Entwürfe. Sogar für komplexe und große Softwareentwicklung. Aber ich habe aufgehört, sie als Ersatz für Verständnis zu betrachten.
KI taugt für den ersten Entwurf: Prototyping, Exploration, Gerüstbau. Aber alles, was in Produktion geht, braucht menschliche Review. Jede Zeile, die deployed wird, muss verstanden sein. Dafür muss man die Grundlagen kennen. Wer nicht weiß, wie ein Compiler funktioniert, kann keinen KI-generierten Compiler bewerten. Und es braucht Ehrlichkeit über Grenzen. „90% fertig" ist nicht „fertig".
90% ist ein guter Anfang. Aber Software-Handwerk zeigt sich in den letzten 10%.