Dein Vibe-Coding-Stack hat keine Andon-Schnur. Deshalb bricht er zusammen.
Bisher hast du eine Programmiersprache danach ausgewählt, was du kanntest, was dein Team kannte oder was das Projekt erforderte. Python für Datenscripts, Go für Backend-Services, C oder Assembly für Treiber. Die Logik war simpel: Ein Mensch, der sich mit einer Sprache auskennt, ist ein Mensch, der liefert.
Diese Logik ist tot.
Bun hat 960.000 Zeilen Zig zu Rust umgeschrieben – in 6 Tagen, mit Claude als primärem Agent. 1.009.257 Zeilen hinzugefügt, 6.755 Commits, 99,8% der bestehenden Tests bestanden. Das Ergebnis: 13.044 unsafe-Blöcke im KI-generierten Rust, verglichen mit 73 in uv, Astrals Python-Paketmanager (350.000 Zeilen handgeschriebenes Rust zum Vergleich). Der Rust-Compiler sagte ja zu allem. Die Menschen sagten nein. 13.044 Mal. Der Unterschied war nicht der Agent. Es war die Andon-Schnur.
Der Mensch schreibt keinen Code mehr. Er beschreibt, und der Agent schreibt. Claude Code, Cursor, Copilot Workspace (der Wrapper ist egal). Der Agent findet Rust nicht einschüchternd. Er braucht keine 3 Jahre, um den Borrow Checker zu verinnerlichen. Er schreibt in jeder Sprache mit derselben Geschwindigkeit, mit derselben Gleichgültigkeit.
Wenn du also ein neues Projekt startest, verschiebt sich die Frage. Nicht mehr welche Sprache du kennst, sondern welche Sprache dem Agent sagt, was er falsch gemacht hat – schnell genug, um ihn zu stoppen, bevor 500 weitere Zeilen auf den Fehler draufkommen?

Die CI nannte es Slop
PR #30412 gemergt am 14. Mai. 1.009.257 Zeilen neues Rust. 4.024 gelöscht. 2.188 Dateien geändert. 6 Tage vom ersten Commit bis main. Binary schrumpfte um 3 bis 8 MB. 99,8% der Testsuite bestanden auf Linux x64.
GitHubs CI taggete dann automatisch den Zig-Lösch-PR als "ai slop." Diese Regel hatte niemand manuell konfiguriert.
Die Hacker News-Diskussion lief über 742 Kommentare, 667 Punkte. Die Tech-Presse griff die Zahl auf, die eine gute Schlagzeile macht: 1 Million Zeilen in 6 Tagen. Was weniger Aufmerksamkeit bekam, war die strukturelle Fußnote: 13.044 unsafe-Blöcke im KI-generierten Rust, verglichen mit 73 in uv, einem vergleichbaren 350.000-Zeilen-Rust-Projekt, das vollständig von Hand geschrieben wurde. Etwa 178x mehr unsafe-Blöcke insgesamt. Die Dichte pro Codezeile liegt bei etwa 62x.
Der Rust-Compiler genehmigte jede einzelne dieser Zeilen.
Jarred Sumner, der Bun gebaut hat, bestätigte, dass das Team "seit vielen Monaten keinen Code mehr selbst tippt." Der Wechsel von Zig zu Rust war teilweise erzwungen: Zigs Kernteam hat eine explizite No-AI-Contributions-Policy, die unvereinbar mit Buns Workflow wurde, als Anthropic das Projekt im Dezember 2025 übernahm. Anstatt gegen die Upstream-Kultur zu kämpfen, wechselte das Team die Sprache.
Das ist kein verpfuschtes Rewrite. Der Code funktioniert. Es ist eine Demonstration dessen, was durchkommt, wenn man mit Geschwindigkeit generiert, ohne den richtigen Ablehnungsmechanismus.
Alle sagen Rust. Niemand sagt warum
Frag einen Dev, warum Agents Rust verwenden sollten, und du bekommst die Performance-Antwort. Schnellere Binaries, Memory Safety, Zero-Cost Abstractions. Die Antwort ist nicht falsch, sie ist nur der falsche Grund speziell für Agents.
Rust führt seit 2016 jedes Jahr die Stack Overflow "most loved language"-Umfrage an. Die Umfrage fragt nicht, ob die Befragten diejenigen sind, die es tatsächlich schreiben. Lange Zeit waren "most loved" und "most used" sehr separate Listen (der Borrow Checker macht das mit Adoptionskurven). Agents haben keine Adoptionskurven. Sie haben keine Gefühle zum Borrow Checker. Sie haben eine Compile-Schleife.
Runtime-Benchmark-Zahlen ändern nichts an der Feedback-Schleife des Agents. Ein Rust-Binary, das zur Ausführungszeit 40% schneller läuft als Go, ist orthogonal dazu, ob der Agent während der Generierung besseren Code schreibt. Die Binary-Geschwindigkeit beeinflusst nicht, wie schnell der Agent Fehler erkennt.
Was zählt, ist wie schnell und wie präzise die Umgebung dem Agent sagt, dass er Mist gebaut hat.
Die Syntax ist gültig, die Semantik ist kaputt, und es gibt kein Signal, bis zur Laufzeit etwas fehlschlägt. Bis dahin wurden 3 weitere Funktionen auf der kaputten Annahme aufgebaut. Die Kette hielt nie an. Rust sagt dem Agent sofort: Compile fehlgeschlagen, Fehlermeldung, Ort, Type Mismatch, Pfad zur Korrektur. Der Agent liest, korrigiert, führt erneut aus.
Die Andon-Schnur
In Toyota-Fabriken in den 1950ern installierten sie eine Schnur entlang jeder Produktionslinie. Jeder Arbeiter konnte sie jederzeit ziehen. Die gesamte Linie hielt an. Ein defektes Teil kam an, die Schnur wurde gezogen, das Problem wurde behoben, bevor die nächste Komponente darauf montiert wurde.
Sie nannten es die Andon-Schnur. Ein 2-Minuten-Stopp war billiger als 40 Minuten Nacharbeit am Ende der Linie. Die Einschränkung machte das Gesamtsystem schneller, nicht langsamer.
Der Compiler ist die Andon-Schnur für den Agent. Die Schleife funktioniert so: Der Agent schreibt Code, der Compiler prüft ihn, der Compiler lässt den Code entweder durch oder zieht die Schnur und gibt eine strukturierte Diagnose aus. Der Agent liest die Diagnose, behebt das Problem und führt erneut aus. Ohne die Schnur schreibt der Agent 500 Zeilen auf eine kaputte Annahme, und das Problem taucht zur Laufzeit auf, 3 Sessions später, in einem Stack Trace, der auf ein Symptom statt auf die Ursache zeigt. Mit der Schnur taucht das Problem in Sekunden auf, in Compiler-Output, der spezifisch genug ist, dass der Agent sofort handeln kann.
Das ist die echte Variable in KI-unterstützter Code-Qualität: nicht welches Modell du verwendest, nicht wie sorgfältig du promptest, sondern ob die Umgebung die Schnur schnell genug und mit genug diagnostischer Präzision zieht, dass der Agent sich selbst korrigieren kann, bevor sich die Schulden anhäufen.
(Völlig off topic: Ich habe diese Woche alte Hanna-Barbera-Cartoons mit meinem Kind geschaut und kann nicht aufhören zu denken, wie der Limited-Frame-Budget-Animationsstil zu einer Ästhetik wurde, die Leute noch lange nachahmen, nachdem die Budget-Einschränkung, die ihn schuf, verschwunden ist. Ein Produktionslimit, das in ein Medium eingebaut wurde. Hat nichts mit Compilern zu tun, so funktioniert nur mein Gehirn.)
Die Reichhaltigkeit der Schnur ist genauso wichtig wie ihre Existenz. Ein Compiler, der "Fehler in Zeile 42" sagt, gibt dem Agent einen Ort. Ein Compiler, der sagt "du versuchst Option<&u32> mit u32 in Zeile 42 zu multiplizieren, rufe .unwrap() auf oder matche zuerst auf die Option" gibt dem Agent einen Ort, beide Typen, was versucht wurde und einen Reparaturpfad. Der Agent muss nichts ableiten. Er liest, wendet an, führt erneut aus.
Das ist dasselbe Prinzip, das erklärt, warum CLIs MCP für AI-Agents schlagen. Die Umgebung, die du wählst, bestimmt, wie viel Signal zurückkommt, wenn etwas kaputtgeht. Die Sprachwahl ist dieselbe Entscheidung auf einer niedrigeren Ebene.
Von keiner Schnur zu voller Schnur
Dasselbe Szenario über das Spektrum. Du hast ein Dictionary. Ein Schlüssel fehlt. Du versuchst, den Wert in Arithmetik zu verwenden.
Python: keine Schnur.
data = {"price": 100}
total = data["quantity"] * data["price"]
KeyError: 'quantity' trifft zur Laufzeit, möglicherweise 3 Funktionen downstream, möglicherweise in Production. Der Agent hatte null Signal zur Generierungszeit. Die Kette lief. Das Teil war defekt. Niemand zog die Schnur, weil es keine Schnur zum Ziehen gab.
TypeScript mit noUncheckedIndexedAccess: teilweise Schnur.
const data: Record<string, number> = { price: 100 };
const quantity = data["quantity"]; // type: number | undefined
const total = quantity * data["price"];
// TS2532: Object is possibly 'undefined'
Vor der Ausführung gefangen. Kurze Nachricht, umsetzbar: Ort und Type-Constraint. TypeScript hilft nicht bei Memory Layout oder Thread Safety, aber für Application-Layer-Logik fängt es diese Fehlerklasse zuverlässig ab.
Go: syntaktische Schnur, keine semantische Schnur.
data := map[string]int{"price": 100}
total := data["quantity"] * data["price"]
fmt.Println(total) // prints 0, no error
Go weigert sich, unbenutzte Imports oder unbenutzte Variablen zu kompilieren. Echte Hygiene. Aber Map-Lookups auf fehlende Schlüssel geben stillschweigend den Nullwert zurück. data["quantity"] gibt 0 zurück. total ist 0. Die Funktion läuft weiter. Etwas downstream bekommt eine falsche Zahl, und die Fehlermeldung taucht 3 Funktionen später auf und zeigt auf ein Symptom. Stack Overflow nennt das "so funktioniert Go halt." Dein Agent nennt es einen Bug.
Go kompiliert in etwa 2 Sekunden bei einer typischen Service-Codebase. Rust braucht 30 Sekunden oder mehr bei vergleichbarem Code. Ich denke, TypeScript strict mode schlägt Go tatsächlich für die meisten Web-Service-Use-Cases, aber ich könnte mich bei Teams mit schweren Concurrency-Anforderungen irren. Gos Schnur ist real, sie ist nur schmal: Struktur wird gefangen, Semantik nicht.
Rust: volle Schnur.
use std::collections::HashMap;
let mut data = HashMap::new();
data.insert("price", 100u32);
let quantity = data.get("quantity"); // type: Option<&u32>
let total = quantity * data.get("price").unwrap_or(&0);
error[E0369]: cannot multiply `Option<&u32>` by `u32`
--> src/main.rs:8:21
|
8 | let total = quantity * data.get("price").unwrap_or(&0);
| ^^^^^^^^
| Option<&u32>
help: use `Option::unwrap_or`, `Option::unwrap_or_else`,
or match to handle the None variant before multiplying
Ort, beide Typen, was versucht wurde und ein Reparaturpfad (4 Zeilen). Der Agent liest, wendet an, führt erneut aus. Der Rust-Compiler klingt, als hätte er ein persönliches Interesse an deinem Erfolg, und für einen Agent ist das genau das, was du von einem Tool willst.
Ada: maximale Schnur.
Ada wurde 1983 so entworfen, dass Fehler in militärischen Embedded-Systemen keine Menschen töten würden. Uninitialisierte Variablen, Integer Overflow, Array Bounds Violations, implizite Typkonvertierungen: alles zur Compile-Zeit gefangen, standardmäßig, mit Diagnosen, die präzise genug sind, um konfrontativ zu wirken. Der Mars-Rover läuft auf Ada. Das James Webb Space Telescope läuft auf Ada. Die betreffenden Compiler haben nie einmal gefragt, ob ein Mensch heute Lust darauf hat, sich damit zu beschäftigen.
Die Industrie lehnte Ada für allgemeine Software-Nutzung größtenteils ab, weil die Strenge für menschliche Entwickler zu schmerzhaft war. Zu viel Zeremonie. Zu viele Dinge, die explizite Annotation erfordern.
Ada: zu streng für Menschen. Agents ist das egal.
Geschwindigkeit ohne Schnur ist Schuld
Sicherheitsgurte wurden Pflicht, als Autos schnell wurden, nicht als sie langsam wurden. Circuit Breaker wurden zu Finanzmärkten hinzugefügt, nachdem algorithmisches Trading anfing, Tausende von Orders pro Sekunde auszuführen, ohne etwas, das sie stoppen konnte. Das Muster: Generierungsgeschwindigkeit braucht Ablehnungsinfrastruktur in passendem Maßstab.
Die 13.044 unsafe-Blöcke in Buns Rewrite sind kein Versagen von Claudes Code-Generierung. Es sind die Stellen, wo der Agent bewusst um die Schnur herumging, mit Rusts unsafe-Keyword, um den Borrow Checker bei semantisch komplexen Abschnitten zu umgehen. Die Schnur war da. Der Agent entschied sich, sie an diesen Stellen zu trennen. Die Schuld ist strukturell, auditierbar, und das Bun-Team wird sie abarbeiten. Aber sie existiert, weil Generierungsgeschwindigkeit die Feedback-Schleife überholte.
Dein Vibe-Coding-Stack läuft dasselbe Muster in kleinerem Maßstab. Was Claude Code-Tutorials über Production verpassen schließt diese Environment-Level-Entscheidungen ein: welcher Compiler, welche Strictness-Einstellungen, welches Typsystem (gesetzt vor dem ersten Prompt).
Für eine Next.js SaaS: TypeScript mit strict: true und noUncheckedIndexedAccess aktiviert. Fängt die Fehlerklasse ab, die Agents am häufigsten auf Application-Layer generieren.
Für Backend-Services oder CLIs: Go oder TypeScript je nach Performance-Constraints. Gos 2-Sekunden-Compile-Schleife macht Iteration schnell, auch mit schwächeren semantischen Garantien.
Für System-Software, Edge-Runtimes, alles was Memory direkt berührt: Rust. Nicht für die Performance. Für den Compiler.
Für Missile-Guidance-Software: Ada. (Niemand fragt, aber die Antwort ist Ada.)
2 Prompts für das nächste Mal, wenn du ein Projekt startest oder eine bestehende Codebase auditest:
Ich starte ein Projekt, wo AI-Agents den meisten Code schreiben werden.
Ich will die Sprache, die dem Agent das reichhaltigste Compile-Time-Feedback
gibt, wenn er Fehler macht. Ignoriere meine persönliche Vertrautheit mit der Sprache.
Projekttyp: [saas app / CLI tool / system service / other].
Empfiehl eine Sprache und ihre strengste Compiler/Type-Konfiguration,
optimiert für Agent-Error-Signal-Qualität, nicht für menschlichen Developer-Komfort.
Ich habe eine [language]-Codebase, wo AI-Agents den meisten Code generieren.
Welche Compiler-Flags, Type-Checker-Settings und Linter-Rules sollte ich
aktivieren, um mehr Fehler zur Compile-Zeit zu fangen, bevor sie Runtime erreichen?
Gib mir eine priorisierte Liste von am einfachsten zu aktivieren bis am aggressivsten.
Ich verwende Claude Code jeden Tag. Bun ist die Runtime darunter. Ich wusste bis letzte Woche nicht, dass diese Runtime auf 1M Zeilen läuft, die Claude in 6 Tagen geschrieben hat, mit 13.044 unsafe-Blöcken, die auf Audit warten.
Es macht mir keine Angst. Die Tests bestehen. Jarred Sumner ist nicht der Typ, der eine scharfe Granate in Prod liegen lässt.
Was es mich machen ließ, ist meine eigenen Pipelines anzuschauen. Die Stellen, wo ich Raum für den Agent gelassen habe, schnell zu generieren ohne Netz. TypeScript läuft ohne strict: true, Schema-Validierung sitzt in einem Kommentar statt in einem Constraint (überall wo der Compiler die Schnur nicht zieht, sammeln sich Bugs unter anderen Namen).
In deiner Codebase tauchen sie nicht als unsafe-Blöcke auf. Sie tauchen als Prod-Bugs auf, 6 Wochen später.
Quellen
- Bun Rewrites 960K Lines of Zig to Rust Using Claude, AI Weekly, May 2026
- Bun Rust Rewrite Merged: The 13,000 Unsafe Block Problem, ByteIota, May 14, 2026
- Rewrite Bun, EarlyTerms, May 2026
- Anthropic's Bun Rust Rewrite Merged at Speed of AI, The Register, May 14, 2026
Dieser Post könnte Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich qualitativ hochwertige Artikel zu liefern).