Deterministische vs. probabilistische Code-Generierung: Warum Buns vibe-codierte Rust-Konvertierung Warnsignale auslöst

Noah Hall, Autor bei The Tech Enabler, zieht eine scharfe Trennlinie zwischen deterministischer und probabilistischer Codegenerierung. Er verwendet Buns kürzliche vibe-coded Konvertierung einer Millionen-Zeilen-Codebasis von Zig zu Rust als warnendes Beispiel. Sein Kernargument: Deterministische Systeme liefern konsistente, überprüfbare Ergebnisse; LLMs führen Unsicherheit ein, die Code-Reviews in großem Maßstab unmöglich macht.

Deterministische Codegenerierung

Hall verweist auf etablierte deterministische Werkzeuge: Pythons 2to3 für Python 2→3-Migration und Transpiler für Sprachen wie Elm, PureScript und TypeScript, die immer dasselbe JavaScript erzeugen. Seine eigene Sprache Derw kann JavaScript, TypeScript oder Englisch ausgeben; Tegan gibt JavaScript oder Go aus; Mojie zielt auf JavaScript, Python oder Englisch. Alle basieren auf AST-zu-AST-Transformation – bei gleicher Eingabe erhält man stets die gleiche Ausgabe. Konsistenz ist entscheidend: „Wenn ein Bug konsistent ist, können wir ihn beheben. Wenn ein Bug inkonsistent ist, wird es exponentiell schwieriger, ihn zu beheben.“

Probabilistische Codegenerierung

LLMs variieren die Ausgabe bei jedem Durchlauf – manchmal A, manchmal B. Hall hat vor drei Jahren neuro-lingo als Parodie erstellt: Menschen schreiben nur Funktionssignaturen und Kommentare, und LLMs generieren die Implementierung bei jeder Kompilierung neu. Ein Beispiel:

function add(a: number, b: number): number {
  // Add two numbers together
}
function main() {
  // Print "Hello World" to the console
  // Print the result of add(2, 3)
}

„Jedes Mal, wenn neuro-lingo kompiliert wird, wird der Code frisch von den LLMs generiert. Er ist jedes Mal etwas anders. Manchmal führt er Bugs ein. Manchmal ist er sauber und einfach. Manchmal ist er chaotisch.“ Hall argumentiert, dass vollständig KI-gesteuerte Code-Flows genau das tun, aber mit menschlicher Verantwortung in die Produktion gehen.

Der „Es gibt Tests“-Trugschluss

Tests allein können Qualität nicht garantieren. Hall zitiert SQLite als die am meisten getestete Codebasis: 155,8 KSLOC C-Code gegenüber 92.053,1 KSLOC Testcode (590× mehr). Trotz 100% Branch Coverage, Millionen von Testfällen und umfangreichen Testumgebungen verlässt sich SQLite immer noch auf menschliche Überprüfung. „Es ist einem Menschen nicht möglich, 1 Million Zeilen Änderungen in 9 Tagen zu überprüfen. Bun hat den Code, den sie in Master gemergt haben, nicht überprüft.“

Hall schlussfolgert, dass deterministische Codegenerierung immer noch Validierung benötigt und probabilistische Generierung ein Risiko schafft, das mit der Zeilenanzahl skaliert. Der Quellartikel geht auf jedes Beispiel näher ein.