535.000 Zeilen Zig in 11 Tagen: KI senkt die Wechselkosten zwischen Programmiersprachen

535.000 Zeilen Zig, 22 Millionen monatliche Downloads, portiert in eine neue Sprache in 11 Tagen. Jarred Sumners eigene Schätzung für dieselbe Arbeit von Hand: drei Engineers, ein volles Jahr. Die Wahl einer Programmiersprache galt jahrzehntelang als Einbahnstraße. Diese Annahme ist gerade teuer geworden.

Key Takeaways (TL;DR)

• Lerne eine Sprache tief, nicht exklusiv: Die Fundamente aus der ersten Sprache übertragen sich, die Stammeszugehörigkeit nicht.
• Behandle das Modell als Tutor, nicht als Ghostwriter: Wer Code in einer Sprache ausliefert, die er nicht lesen kann, sammelt subtile Bugs statt Erfahrung.
• Wähle den Stack pro Problem, nicht pro Identität: Wenn die Aufgabe einen strengeren Compiler belohnt, ist die Unvertrautheitssteuer jetzt niedrig genug, um sie zu zahlen.
• Liefere nichts aus, das du nicht erklären kannst: Die Werkzeuge multiplizieren, was du mitbringst.

Basiert auf “Thanks AI! Your tech stack is not your personality anymore” von Francesco Ciulla. Das Original findest du hier: start.dev

Der Tweet, dem niemand widersprochen hat

Diese Woche ging ein Satz viral, dessen Kern man hier unzitiert lassen kann: Wer tief an einen einzigen Tech-Stack gebunden ist, hat gerade ein Problem. Überraschend war nicht der Satz, sondern die Antworten. Tech-Twitter ist ein Ort, an dem sich Menschen über Tabs und Spaces streiten. Unter diesem Tweet herrschte Konsens.

Francesco Ciulla, Developer Advocate und Gründer von Start.dev, hat die Debatte zum Anlass genommen, eine größere Verschiebung zu beschreiben: KI hat nicht das Programmieren verändert, sondern die Kostenrechnung hinter der Wahl der Werkzeuge.

Sprachwahl war eine Heirat, und die Scheidung war teuer

Jahrzehntelang war die Entscheidung für eine Sprache eine Langzeitbindung. Monate, manchmal Jahre bis zur echten Flüssigkeit. Projekte, Jobperspektiven und oft die berufliche Identität hingen an dieser einen Wahl. Niemand benutzte eine Sprache einfach. Man trat ihr bei.

Wenn eine Entscheidung so viel kostet, optimieren alle auf dieselben Kriterien: sanfte Lernkurve, großes Ökosystem, schnelle Auslieferung. Diese Präferenz erklärt den Großteil der modernen Webgeschichte. Rails explodierte auf Basis einer 15-Minuten-Blog-Demo, PHP brachte eine Generation von Entwicklern ins Internet, Nodes gesamtes Versprechen war eine Sprache für alles, und Next.js gewann, indem es die schwierigen Teile verschwinden ließ.

Der eigentliche Preis einer neuen Sprache war dabei nie das Lernen selbst, sondern die unproduktive Strecke: die Monate, in denen du langsam und gefährlich bist, jede Aufgabe viermal so lange dauert und du guten Code noch nicht von schlechtem unterscheiden kannst. Diese Strecke hielt Entwickler in ihren Stacks. Kein Team rechtfertigt ein Quartal, in dem nichts ausgeliefert wird.

Die unproduktive Strecke ist kollabiert

Genau diese Strecke hat KI beseitigt. Das Modell ist bereits flüssig in der Sprache, in der du es nicht bist. Du produzierst ab Tag eins funktionierenden Code, und die Flüssigkeit reibt ab: Du fragst, warum der Compiler sich beschwert, warum der Code so strukturiert ist, was das Idiom ist, und die Sprache sickert hinein, während das Produkt entsteht. Die alte Reihenfolge war erst lernen, dann liefern. Die neue ist beides gleichzeitig.

Carl Lerche, der Tokio geschaffen hat und die Rust-Adoption innerhalb Amazons unterstützt, beobachtet das im Maßstab eines Konzerns: Engineers steigen ohne Rust-Kenntnisse in Rust-Projekte ein, nutzen KI als Lern-Copilot und liefern echte Features, während sie lernen. Ausgerechnet Rust, die Sprache mit dem berüchtigt unversöhnlichen Compiler.

Der Extremfall ist Bun. Die Runtime umfasst 535.000 Zeilen Zig bei 22 Millionen monatlichen Downloads, und Sumner hat das gesamte Projekt in 11 Tagen in eine neue Sprache portiert: dutzende KI-Agenten parallel, eine Testsuite mit über einer Million Assertions, die vor dem Merge zu 100 Prozent grün war. Seine manuelle Schätzung: drei Engineers, ein Jahr. In seinen Worten:

“Until very recently, programming language choice was a one-way decision.”

Beide Fälle teilen ein Muster: Menschen greifen jetzt zu den Sprachen, die als schwierig gelten. Amazon-Engineers laufen in die Sprache mit dem unerbittlichen Compiler. Sumner verließ eine Sprache, die er mochte, für eine, die zur Compile-Zeit exakt die Absturzklasse zurückweist, die sein Projekt geplagt hatte. Der Gewinn der schwierigeren Sprache war immer da. Der Aufstieg war das Veto, und das ist gefallen.

Das stärkste Gegenargument: Ökosystem-Wissen lässt sich nicht herunterladen

Tiefe Erfahrung in einem Ökosystem bleibt einer der wertvollsten Besitztümer eines Entwicklers. Das war vor KI so, und nichts davon ändert sich daran. Syntax zu kennen ist der kleinste Teil von Kompetenz. Zu wissen, welche Library verlassen wurde, welches Muster bei Skalierung kippt, wie ein Produktionsausfall um 3 Uhr nachts aussieht: Das ist jahrelang akkumulierter Kontext, und kein Assistent reicht ihn dir durch. Ein Entwickler mit zehn Jahren in einem Ökosystem wird einen Touristen darin noch lange ausliefern.

Auch an der Abreibungs-Geschichte hakt es. Wenn das Modell die unvertraute Sprache für dich schreibt, kannst du wochenlang ausliefern, ohne sie wirklich zu lesen, und Code in einer halb verstandenen Sprache zu reviewen ist exakt der Ort, an dem subtile Bugs wohnen. Deshalb funktioniert der Amazon-Fall: Diese Engineers bringen tiefe allgemeine Fundamente mit und behandeln die KI als Tutor statt als Ghostwriter. Das ist kein Vibe Coding. Das Modell füllt die Syntax-Lücke, nicht die Kompetenz-Lücke. Auch Sumner hat keine Million generierter Zeilen auf Vertrauen gemergt. Er verbrachte die 11 Tage mit Steuern und Reviewen, und es funktionierte, weil er diese Codebasis besser versteht als jeder andere Mensch. Wer Zeile 14 nicht erklären kann, besitzt den Code nicht, und das gilt in der neuen Sprache genauso wie in der alten, wie der Artikel zu KI-Code-Ownership ausführt.

Der Einwand ist also real. Er argumentiert nur für eine andere Schlussfolgerung als “bleib verheiratet”. Er argumentiert dafür, dass die Tiefe zählt und die Exklusivität nicht. Dass die Fundamente das sind, was sich überträgt, bestätigt auch die Analyse zu Fundamenten statt Tools: Wer Problemlöser ist, adoptiert neue Werkzeuge automatisch. Wer nur ein Werkzeug beherrscht, fängt bei jedem Wechsel bei null an.

4 Schritte zur Umsetzung

1. Eine Sprache tief lernen: Tiefe ist weiterhin die Quelle der Fundamente. TypeScript und Python sind aus gutem Grund beliebte Einstiege, aber die beste erste Sprache ist die, die an etwas hängt, das du tatsächlich bauen willst.
2. Als erste Sprache behandeln, nicht als lebenslanges Urteil: Datenstrukturen, Systemdenken und der Blick für guten Code sind der Teil, der überträgt. KI ist der Teil, der das Übertragen erledigt.
3. Pro Problem wählen, nicht pro Identität: Wenn die Aufgabe einen strengeren Compiler oder eine andere Runtime belohnt, ist die Unvertrautheitssteuer niedrig genug, um sie zu zahlen. Die Ablehnung aus Stammesgründen ist die teure Option.
4. Nichts ausliefern, das du nicht erklären kannst: Die Werkzeuge multiplizieren, was du mitbringst. Wer nichts mitbringt, multipliziert nichts.

Die Entwickler, die gerade in Schwierigkeiten stecken, sind nicht die mit der falschen Sprache, sondern die, die eine Sprache zu ihrer gesamten Identität gemacht und darunter aufgehört haben zu lernen. Date die Sprachen, aber heirate die Fundamente.