Chris Lattner begann 2000 mit LLVM. 25 Jahre später prägt sein Ansatz noch immer Rust, Swift und Julia – und zeigt, was Vibe-Coding, technische Schulden und nachhaltige Softwareentwicklung miteinander zu tun haben.
Vor ein paar Tagen habe ich ein Gespräch zwischen Jeremy Howard (fast.ai) und Chris Lattner gehört – dem Schöpfer von LLVM, Swift und Mojo. Eine Stunde ruhige, bodenständige Unterhaltung. Keine Folien, kein Hype. Nur zwei Ingenieure, die sich der allgemeinen Panik nicht hingeben.
Ich habe das ganze Gespräch am Stück gehört. Das passiert selten.
Denn was Lattner sagt, hat mich direkt getroffen. Nicht wie eine ferne Konferenz über „die Zukunft der Softwareentwicklung“. Eher wie ein Spiegel vor 18 Jahren Designentscheidungen, Refactorings und Apps, die ich gepflegt, aufgegeben oder von Grund auf neu geschrieben habe.
Die zentrale Frage ist einfach. Fast banal.
Wie baut man ein System, das länger als sechs Monate hält?
Die Antwort ist alles andere als einfach.
LLVM: der Compiler, den niemand bestellt hat
Weihnachten 2000. Chris Lattner, damals Doktorand, beginnt allein mit LLVM. Nicht, um ein bestimmtes Problem zu lösen. Nicht, um einen Auftrag abzuarbeiten. Sondern um eine grundlegende Frage zu beantworten: Was sollte eine Compiler-Infrastruktur im Kern eigentlich sein?
25 Jahre später ist LLVM überall. Rust, Swift und Julia – ganze Programmiersprachen wurden darauf aufgebaut. Clang, der von Lattner selbst entwickelte C-, C++- und Objective-C-Compiler, ist das offizielle Frontend. Seit 2013 steckt er in Xcode und damit hinter jedem Build jeder iOS-App.
Das ist kein Glück. Das ist Architektur.
Um zu verstehen, warum das so gut trägt, muss man ein zentrales Konzept im LLVM-Design kennen: die Zwischendarstellung, kurz LLVM-IR.
Die Idee ist elegant. Statt C++ (oder Swift oder Rust) direkt in Maschinencode zu übersetzen – was für jeden Prozessor und jede Architektur eine eigene Umsetzung erfordern würde –, führt LLVM einen universellen Zwischenschritt ein. Jede Sprache wird zunächst in LLVM-IR übersetzt. Anschließend wandelt LLVM diese IR in optimierten Maschinencode für das jeweilige Ziel um: ein iPhone, ein Mac mit Apple Silicon oder ein Linux-Server.
Man kann sich das wie eine Brückensprache vorstellen. Du sprichst Französisch, Englisch oder Spanisch – egal. Alles läuft erst über Esperanto und wird von dort ins Ziel übersetzt.
Diese dreistufige Pipeline – Quellcode → IR → Maschinencode – machte es möglich, Rust zu entwickeln, ohne einen kompletten Compiler neu schreiben zu müssen, Swift vom ersten Tag an auf dem iPhone auszuführen und LLVM jahrelang produktiv in Xcode einzusetzen. Vorne eine neue Sprache anschließen. Hinten einen neuen Prozessor. Der Kern bleibt unangetastet.
Das ist Denken von den Grundprinzipien aus. Keine Lösung nur für heute, sondern ein Fundament für Sprachen, die noch gar nicht erfunden wurden.
„Systeme, die unter ihrem eigenen Gewicht zusammenbrechen, haben eine Architektur, die von Anfang an falsch war. Systeme, die Bestand haben, verdanken das jemandem, der sich die Zeit genommen hat zu verstehen, was er baut – und warum.“ — Chris Lattner
Diese Denkweise kommt mir bekannt vor. Genau sie unterscheidet eine iOS-App, die zwei Jahre hält, von einer, die man nach sechs Monaten von Grund auf neu schreibt. Es geht nicht um Codequalität im syntaktischen Sinn. Es geht um die Qualität des Denkens, das dem Code vorausging.
Architektur ist unsichtbar – und entscheidet doch über alles.
Vibe-Coding: ein Symptom unserer Zeit
Die Ansage ist heute eindeutig: schnell veröffentlichen, oft veröffentlichen, mit KI zehnmal schneller werden. CEOs prahlen öffentlich damit, dass ihre Teams täglich 10.000 Zeilen KI-generierten Code produzieren.
10.000 Zeilen am Tag.
Lattner nennt das eine nutzlose Kennzahl. Schlimmer noch: eine gefährliche.
„Ich bin kein CEO, der mit der Anzahl KI-generierter Codezeilen prahlt. Für mich ist das eine Belastung, kein Vorteil. Entscheidend ist: Wird das Produkt besser? Verstehen die Leute, was sie bauen?“
Vibe-Coding – einen Agenten-Kreislauf starten und hoffen, dass etwas Brauchbares dabei herauskommt – ist Glücksspiel im Gewand der Produktivität. Howard beschreibt es treffend: „Es ist, als würde man an einem Spielautomaten den Hebel ziehen. Man verliert und zieht wieder. Man verliert und zieht wieder.“
Die Geschichte, die mich erschüttert hat
Lattner erzählt einen konkreten Fall. Ein erfahrener Ingenieur meldet einen Fehler; ein Agenten-Kreislauf wird gestartet und erzeugt einen Pull Request. Der PR besteht die Tests. Der Fehler ist „verschwunden“.
Nur war er nicht weg. Das Symptom wurde verdeckt. Unter der Oberfläche nahm die Codebasis eine Zeitbombe auf: Code am falschen Ort, mit der falschen Aufgabe, kurz davor, drei neue Fehler zu verursachen, die subtiler waren als der erste.
Der Code wurde zusammengeführt, ohne dass jemand wirklich verstand, was er tat.
Das ist kein Werkzeugproblem. Es ist ein Kulturproblem. Eine Kultur, die gelernt hat, Symptome verschwinden zu lassen, statt ihre Ursachen zu verstehen.
Was das für iOS-Entwickler bedeutet
Ich entwickle seit 2007 iOS-Apps. Ich habe Paradigmen kommen und gehen sehen: Objective-C, ARC, Swift, SwiftUI, MVC/MVVM/TCA. Ich habe komplette Apps neu geschrieben und andere jahrelang gepflegt.
Eines kann ich sagen: Technische Schulden schlafen nie.
Sie warten. Sie wachsen. Und sie wachen im denkbar ungünstigsten Moment auf: wenn eine Deadline ansteht, Apple eine neue iOS-Version veröffentlicht oder ein Nutzer einen Fehler meldet, den du nicht mehr verstehst, weil die Person, die den Code geschrieben hat, nicht mehr da ist. Oder du warst es selbst, vor drei Jahren, und erinnerst dich nicht mehr an die Gründe.
KI hat daran nichts geändert. Sie hat es beschleunigt.
Bei Onyria habe ich mich bewusst entschieden: KI als Beschleuniger, nicht als Architekt. Die strukturellen Entscheidungen – wie Nutzer-Credits verwaltet werden, wie Aufrufe an die Reve-API koordiniert werden, wie Daten per SwiftData ohne externen Server zwischen Geräten synchronisiert werden – treffe ich selbst. KI kann mir beim Boilerplate helfen, Alternativen erkunden und Randfälle finden. Aber sie kann die Einschränkungen des Apple-Ökosystems nicht für mich verstehen.
Das sind 18 Jahre Erfahrung. Und die lässt sich nicht automatisieren.
Die Spaltung
Howard stellt eine Diagnose, die mich nicht losgelassen hat:
„Es wird zwei Gruppen geben. Die einen haben erlernte Hilflosigkeit entwickelt – sie wissen ohne KI nicht mehr wirklich, was sie tun. Und dann gibt es die kleinere Gruppe, bei der sich alle fragen werden: ‚Woher weiß diese Person das alles? Sie ist unglaublich.‘“
Das sehen wir bereits. Die Prüfzeiten im App Store werden länger, weil die Zahl der Einreichungen explodiert – nicht aber die Qualität. Apple verschärft seine Richtlinien (4.1, 4.2, 4.3) gegen per Prompt erzeugte Klon-Apps. Die Messlatte steigt.
Für Entwickler, die wirklich verstehen, was sie bauen, sind das gute Nachrichten. Das Ökosystem sortiert sich neu. Kompetenz wird zu einem echten Wettbewerbsvorteil, nicht nur zu einem theoretischen.
Lattners Frage an jeden Ingenieur ist direkt:
„Wo stehst du, wenn sich der Hype gelegt hat – und das tut er immer? Bist du gewachsen? Oder hast du zwei Jahre lang Hebel gezogen und gehofft, die KI würde dich von allein besser machen?“
Wie ich KI tatsächlich nutze
Lattner nutzt KI. Er spricht von einem Produktivitätsgewinn von 10 bis 20 Prozent. Gleichzeitig hält er an einer engen Iterationsschleife fest: bearbeiten, kompilieren, ausführen, debuggen. Zu jedem Zeitpunkt weiß er, was sein Code tut.
Genau so arbeite ich auch.
KI hilft mir dabei:
- eine API zu erkunden, die ich noch nicht kenne;
- Boilerplate zu erzeugen, die ich nicht von Hand schreiben möchte;
- meine Architektur zu hinterfragen, bevor ich mich festlege;
- Randfälle zu entdecken, die mir entgangen sein könnten.
Was sie mir nicht abnimmt:
- die Architektur zu bestimmen;
- geschäftliche Anforderungen zu verstehen;
- langfristig für Konsistenz zu sorgen;
- zu beurteilen, ob das Ergebnis im größeren Zusammenhang Sinn ergibt.
Der Unterschied ist der zwischen Werkzeug und Krücke. Ein Werkzeug verstärkt, was du bereits kannst. Eine Krücke gleicht aus, was du nicht kannst – und hält dich vom Lernen ab.
Was ich daraus mitnehme
Lattners Interview ist kein Anti-KI-Manifest. Es erinnert daran, dass die Grundlagen nicht veraltet sind.
Architektur. Verständnis. Handwerk.
Dieselben Prinzipien sorgten dafür, dass LLVM 25 Jahre nach seiner Entstehung noch läuft. Und sie sorgen dafür, dass eine gut entworfene iOS-App Bestand hat, sich weiterentwickelt und Plattformwechsel übersteht.
KI ist ein bemerkenswertes Werkzeug. Doch Werkzeuge haben Urteilsvermögen noch nie ersetzt.
Urteilsvermögen entsteht in den Schützengräben: bei Fehlern, deren Verständnis drei Tage gedauert hat; bei schmerzhaften Refactorings, die man bis zum Ende durchgezogen hat; bei Architekturentscheidungen, für die man über Jahre Verantwortung getragen hat.
Deinen Wert als Entwickler bestimmt nicht, was die KI erzeugt. Sondern was du von dem verstehst, was sie erzeugt.
Das vollständige Interview gibt es auf fast.ai. Sehr empfehlenswert. Hier ist das Video.