Chris Lattner begon in 2000 aan LLVM. 25 jaar later zegt zijn aanpak nog steeds iets essentieels over vibe coding, technische schuld en software die lang meegaat.
Een paar dagen geleden luisterde ik naar een gesprek tussen Jeremy Howard (fast.ai) en Chris Lattner, de bedenker van LLVM, Swift en Mojo. Een uur rustig, nuchter gesprek. Geen slides, geen hype. Twee engineers die zich niet laten meeslepen door de algemene paniek.
Ik luisterde het in één keer uit. Dat gebeurt bijna nooit.
Wat Lattner zegt, raakt me namelijk direct. Niet als een verre conferentie over “de toekomst van softwareontwikkeling”, maar als een spiegel voor 18 jaar ontwerpkeuzes, refactorings en apps die ik heb onderhouden, opgegeven of helemaal opnieuw geschreven.
De centrale vraag is simpel. Bijna vanzelfsprekend.
Hoe bouw je een systeem dat langer dan zes maanden meegaat?
Het antwoord is allesbehalve simpel.
LLVM: de compiler waar niemand om vroeg
Kerst 2000. Chris Lattner is promovendus en begint in zijn eentje aan LLVM. Niet om één specifiek probleem op te lossen. Niet om een opdracht uit te voeren. Hij wil een fundamentele vraag beantwoorden: wat hoort een compilerinfrastructuur in de kern te zijn?
Vijfentwintig jaar later is LLVM overal. Rust, Swift en Julia: complete programmeertalen zijn erop gebouwd. Clang, de C-, C++- en Objective-C-compiler die Lattner zelf maakte, is de officiële frontend. Sinds 2013 draait die in Xcode, achter elke build van elke iOS-app.
Dat is geen geluk. Dat is architectuur.
Om te begrijpen waarom het zo goed standhoudt, moet je één belangrijk ontwerpidee van LLVM kennen: de tussentijdse representatie, of LLVM-IR.
Het idee is elegant. In plaats van C++ (of Swift of Rust) rechtstreeks naar machinecode te compileren — waarvoor je alles voor elke processor en architectuur opnieuw zou moeten schrijven — voegt LLVM een universele tussenstap toe. Elke taal wordt eerst naar LLVM-IR vertaald. Daarna zet LLVM die IR om in geoptimaliseerde machinecode voor het doel: een iPhone, een Mac met Apple Silicon of een Linux-server.
Zie het als een tussentaal. Je spreekt Frans, Engels of Spaans; dat maakt niet uit. Alles gaat eerst door het Esperanto en wordt vandaar naar de eindbestemming vertaald.
Deze pipeline in drie stappen — broncode → IR → machinecode — maakte het mogelijk om Rust te bouwen zonder een volledige compiler te herschrijven, Swift vanaf dag één op de iPhone te laten draaien en LLVM jarenlang in productie in Xcode te gebruiken. Sluit vooraan een nieuwe taal aan, achteraan een nieuwe processor. De kern blijft hetzelfde.
Dat is denken vanuit de eerste principes. Geen oplossing voor alleen vandaag, maar een fundament voor talen die nog niet zijn uitgevonden.
“Systemen die onder hun eigen gewicht bezwijken, hebben vanaf het begin een gebrekkige architectuur. Systemen die blijven bestaan, danken dat aan iemand die de tijd nam om te begrijpen wat die bouwde — en waarom.” — Chris Lattner
Ik herken die manier van denken. Dat is precies het verschil tussen een iOS-app die twee jaar meegaat en een app die je na zes maanden opnieuw vanaf nul schrijft. Het gaat niet om codekwaliteit in syntactische zin, maar om de kwaliteit van het denken dat eraan voorafging.
Architectuur zie je niet, maar ze bepaalt alles.
Vibe coding: een symptoom van deze tijd
De boodschap is tegenwoordig duidelijk: ship snel, ship vaak, gebruik AI om tien keer sneller te gaan. CEO’s scheppen er publiekelijk over op dat hun teams dagelijks 10.000 regels AI-geschreven code produceren.
10.000 regels per dag.
Lattner noemt dat een nutteloze maatstaf. Erger nog: een gevaarlijke.
“Ik ben geen CEO die opschept over het aantal regels dat AI genereert. Ik zie dat als een risico, niet als een voordeel. De vragen zijn: wordt het product beter? Begrijpen mensen wat ze bouwen?”
Vibe coding — een agentloop starten en hopen dat er iets bruikbaars uitkomt — is gokken vermomd als productiviteit. Howard verwoordde het precies zo: “Het is alsof je aan een gokautomaat trekt. Je verliest, je trekt opnieuw. Je verliest, je trekt opnieuw.”
Het verhaal waarvan ik koud werd
Lattner vertelt over een concreet geval. Een senior engineer meldt een bug, er wordt een agentloop gestart en die levert een PR op. De PR slaagt voor de tests. De bug is “verdwenen”.
Maar dat was niet zo. Alleen het symptoom was gemaskeerd. Onder de oppervlakte had de codebase een tijdbom opgenomen: code op de verkeerde plek, die het verkeerde deed en op het punt stond drie nieuwe, subtielere bugs te veroorzaken.
De code was samengevoegd zonder dat iemand echt begreep wat die deed.
Dat is geen probleem met de tooling. Het is een cultuurprobleem. Een cultuur die heeft geleerd symptomen te laten verdwijnen in plaats van oorzaken te begrijpen.
Wat dit betekent voor iOS-ontwikkelaars
Ik bouw sinds 2007 iOS-apps. Ik heb paradigma’s zien komen en gaan: Objective-C, ARC, Swift, SwiftUI, MVC/MVVM/TCA. Ik heb complete apps herschreven en andere jarenlang onderhouden.
Eén ding kan ik je vertellen: technische schuld slaapt nooit.
Ze wacht. Ze stapelt zich op. En ze wordt wakker op het slechtst mogelijke moment: wanneer je een deadline hebt, wanneer Apple een nieuwe iOS-versie uitbrengt, wanneer een gebruiker een bug meldt die je niet meer begrijpt omdat degene die de code schreef er niet meer is. Of jij was het zelf, drie jaar geleden, en je weet niet meer waarom je het zo hebt gedaan.
AI heeft die werkelijkheid niet veranderd. AI heeft haar versneld.
Voor Onyria heb ik bewust gekozen: AI als versneller, niet als architect. De structurele beslissingen — hoe gebruikerscredits worden beheerd, hoe API-aanroepen naar Reve worden georkestreerd, hoe data met SwiftData tussen apparaten synchroniseert zonder externe server — neem ik zelf. AI kan me helpen boilerplate te schrijven, alternatieven te verkennen en randgevallen te vinden. Maar AI kan de beperkingen van het Apple-ecosysteem niet voor mij begrijpen.
Dat zijn 18 jaar ervaring die spreken. En dat automatiseer je niet.
De tweedeling
Howard stelt een diagnose die bij me bleef hangen:
“Er komen twee groepen. Mensen met aangeleerde hulpeloosheid, die zonder AI niet meer goed weten wat ze doen. En die kleinere groep waar iedereen zich over afvraagt: ‘Hoe weet die persoon dat allemaal? Wat een uitzonderlijke ontwikkelaar.’”
We zien het al gebeuren. App Store-reviews duren langer omdat het aantal inzendingen explodeert, maar de kwaliteit niet. Apple scherpt de richtlijnen (4.1, 4.2, 4.3) aan tegen kloonapps die met prompts zijn gegenereerd. De lat gaat omhoog.
Voor ontwikkelaars die echt begrijpen wat ze bouwen, is dat goed nieuws. Het ecosysteem wordt opgeschoond. Vakmanschap wordt een echt concurrentievoordeel, niet alleen een theoretisch voordeel.
Lattner stelt iedere engineer een directe vraag:
“Waar sta jij wanneer de hype gaat liggen — en dat gebeurt altijd? Ben je gegroeid? Of heb je twee jaar aan hendels getrokken in de hoop dat AI je vanzelf beter zou maken?”
Hoe ik AI echt gebruik
Lattner gebruikt AI. Hij heeft het over 10 tot 20 procent meer productiviteit. Maar hij houdt vast aan wat hij een korte iteratiecyclus noemt: aanpassen, compileren, uitvoeren, debuggen. Op elk moment weet hij wat zijn code doet.
Dat is precies mijn aanpak.
AI helpt me om:
- een API te verkennen die ik nog niet ken;
- boilerplate te genereren die ik niet met de hand wil schrijven;
- mijn architectuur kritisch te bekijken voordat ik ervoor kies;
- randgevallen te vinden die ik misschien over het hoofd zag.
Wat AI niet voor me doet:
- de architectuur bepalen;
- zakelijke beperkingen begrijpen;
- de samenhang op lange termijn bewaken;
- beoordelen of de uitkomst in de grotere context klopt.
Het verschil is dat tussen gereedschap en een kruk. Gereedschap versterkt wat je al kunt. Een kruk compenseert wat je niet kunt — en houdt je tegen om het te leren.
Wat ik meeneem
Lattners interview is geen anti-AI-manifest. Het herinnert eraan dat de fundamenten niet achterhaald zijn.
Architectuur. Begrip. Vakmanschap.
Dezelfde principes zorgen ervoor dat LLVM 25 jaar na de eerste ontwikkeling nog draait. En dat een goed ontworpen iOS-app overeind blijft, kan meegroeien en platformveranderingen doorstaat.
AI is een bijzonder hulpmiddel. Maar hulpmiddelen hebben beoordelingsvermogen nooit vervangen.
Dat vermogen bouw je in de loopgraven op: door bugs drie dagen te onderzoeken, pijnlijke refactorings tot het einde door te voeren en verantwoordelijkheid te nemen voor architectuurkeuzes.
Je waarde als ontwikkelaar wordt niet bepaald door wat AI genereert, maar door wat jij begrijpt van wat het genereert.
Het volledige interview staat opfast.ai. Een aanrader. Hier is de video.