De bedenker van Ruby on Rails schrijft geen regel code meer zelf

Lex Fridman sprak ruim vijf uur met David Heinemeier Hansson — DHH, bedenker van Ruby on Rails, CTO van 37signals en sinds een jaar bouwer van de Linux-distributie Omarchy. Het gesprek past in één alinea: een programmeur die twintig jaar lang zijn Ruby met de hand beitelde en dat vak als een ambacht beschouwde, heeft in negen maanden vrijwel alles losgelaten wat hij erover dacht te weten. Hij schrijft geen regel code meer zelf, stuurt in plaats daarvan een stuk of zestien agents tegelijk aan over vier machines, en leverde daarmee in drie maanden een compleet besturingssysteem op. Daaromheen gaat het over wat er dan nóg schaars is — smaak, oordeel, weten wát je moet bouwen — waarom grote organisaties deze versnelling niet zomaar overnemen, wat een model per klus kost, en waarom uitgerekend Linux het besturingssysteem van dit tijdperk wordt. Zijn eigen samenvatting van het moment leent hij van Lenin: er zijn decennia waarin niets gebeurt, en weken waarin decennia gebeuren.

Vijf uur is veel, ook voor een goed gesprek. Hieronder loop ik de hoofdstukken langs die over ons vak gaan, met tijdcode: wat DHH zegt, en wat ik ervan vind. De niet-technische delen — AI en filmmaken (2:50:57), vaderschap (3:10:28), politiek en immigratie (4:22:17), zijn afkeer van de longevity-cultus (4:53:54) — laat ik liggen. Niet omdat ze oninteressant zijn, maar omdat dit de zeepkist van een softwarebedrijf is.

In dit artikel

• 1 · Programmeren met AI-agents
• 2 · Waarom je hier niets van terugziet in de software die je dagelijks gebruikt
• 3 · Open source: duizend pull requests, en agents die ze beoordelen
• 4 · Vibe coding, agentic engineering, en waarom overspecificeren schaadt
• 5 · Advies voor programmeurs: er wordt niets opgebouwd dat je kunt missen
• 6 · De werkplek: zestien threads, vier machines, één mens als bottleneck
• 7 · Obsessie met snelheid: een besturingssysteem dat in 45 seconden staat
• 8 · Welk model, en wat kost het?
• 9 · Twee modellen, vier ogen
• 10 · Linux wint de desktop, en Engels wordt de programmeertaal
• Wat dit betekent voor hoe wij bouwen

Dertien maanden eerder zat DHH aan dezelfde tafel als scepticus. Autocomplete vond hij een rotmodus om in te werken, de chatbot een prima leraar, en geen van beide veranderde iets aan hoe hij naar een editor keek. Zijn kantelpunt legt hij op de dag af nauwkeurig: 24 november 2025, Opus 4.5 (kijk vanaf 2:56). Niet omdat het model plotseling veel slimmer was, zegt hij, maar omdat het zijn intelligentie eindelijk kón toepassen — tools gebruiken, zijn eigen werk controleren, een taak afmaken. Daarna gaat het in drie fasen: eerst één agent die je stuurt, dan sub-agents die de taak opknippen, en sinds deze zomer een fase waarin hij niet meer vertelt wáár ze heen moeten. Hij beschrijft het probleem, het model bepaalt de route. Zijn beeld daarbij is de navigatie: ooit lette je op of het apparaat je niet de haven in stuurde, inmiddels rijdt de auto zelf.

Wat dit betoog gewicht geeft, is niet het enthousiasme maar de herkomst. Dit is de man die twee decennia lang uitlegde waarom je code met de hand hoort te schrijven, en die precies benoemt waar het níet opgaat: bij een webapplicatie met een database eromheen kom je richting honderd procent gegenereerde code, bij Basecamp — groot, oud, veel gebruikers — bleek dat een stuk taaier. Dat onderscheid is bruikbaarder dan de meeste leveranciersverhalen, want het is exact de grens waar onze klanten op stuiten.

Lex stelt de goede vraag: als dit waar is, waarom worden Photoshop en Premiere dan niet ineens beter? Het antwoord van DHH is ongemakkelijk voor iedereen met een organogram (vanaf 18:14). Zodra mensen samenwerken is implementatie zelden de bottleneck; dat zijn de bandbreedte en de afstemming tussen mensen. Een productmanager, twee ontwerpers, een VP en een CTO die allemaal iets van de vorm willen vinden — daar sterft de productiviteit. Om die factor tien tot honderd te halen moet je zélf met de agents praten, en er geen mens tussen zetten. Bovendien zitten de meeste organisaties niet vast op bouwen, maar op weten wat ze willen: ideeën, visie, smaak. Je kunt nu heel snel heel veel middelmatige ideeën waarmaken.

Hij heeft daar ook een litteken bij. Bij Basecamp 5 kregen ontwerpers de ruimte om te vibe-coden. De pull requests waren stuk voor stuk te verdedigen; bij elkaar sloopten ze de architectuur, en het opruimen moest met de hand. Dat is precies het gesprek dat wij het vaakst voeren bij tech consultancy: niet of agents code kunnen schrijven, maar wie de samenhang bewaakt als vijf mensen tegelijk laten genereren. Bij ontzorgde softwareontwikkeling is dat een van de weinige dingen die we niet delegeren, en bij het moderniseren van bestaande software is het het halve werk.

In drie maanden mergede DHH ruim duizend pull requests in Omarchy, met nog een paar honderd open (vanaf 27:30). Veel daarvan komt van mensen die geen Linux-ontwikkelaar zijn en die zonder agent nooit iets hadden ingestuurd. Maintainers die klagen over de stortvloed aan AI-bijdragen begrijpt hij niet: dit is precies wat open source altijd beloofde. Zelf leest hij ze niet meer allemaal — een agent beoordeelt, valideert bugfixes in een VM en levert een samenvatting op waar alleen de menselijke beslissing nog over is: mergen of niet. En, zegt hij droog, een agent-PR afwijzen kwetst niemand. Dat de reviewcapaciteit de echte bottleneck is en niet het schrijven, is precies wat wij eerder terugzagen in onderzoek naar 25.000 pull requests.

DHH hekelt beide termen en geeft toch een bruikbare definitie (vanaf 47:05): vibe coden is een agent software laten bouwen zonder naar de implementatie te kijken. Interessanter is zijn tweede stelling: programmeurs zijn hier niet automatisch beter in. Softwarebouwen is voor een groot deel productmanagement — wat moet het doen, voor wie, wat zit er wél en niet in versie één — en die vaardigheid is niet gelijk verdeeld over ontwikkelaars. Sterker nog, zijn eigen ervaring werkte een tijd tegen hem, omdat hij agents voorschreef hoe hij het zelf zou hebben gedaan. Hij verwijst naar de systeemprompt van Opus 5 die met tachtig procent kromp omdat te veel instructies het model juist schaden, en trekt de parallel met de agile-les van vijfentwintig jaar geleden: niemand weet wat hij wil tot hij het gebruikt, dus specificeer vooraf zo min mogelijk en ga iets aanraken.

Bij één punt komt hij vanaf 1:00:06 terug op aarde. Mooie, samenhangende code loont nog steeds — niet meer omdat een mens hem moet begrijpen, maar omdat tokens schaars zijn. Een systeem dat een agent kan bevatten zonder de hele context opnieuw te leren, is goedkoper te wijzigen. Wie de architectuur laat verzanden tot een modderbal, betaalt dat per PR terug. Dat is dezelfde rekensom die wij eerder maakten in Code wordt goedkoop. Engineering niet. en die verklaart waarom gegenereerde code niet automatisch goede code is.

Het meest geruststellende stuk van het gesprek (vanaf 1:10:24). Probeer niets te voorspellen, zegt DHH, want zelfs de slimste mensen in dit veld weten niet hoe het er twee modelgeneraties verder uitziet. En het goede nieuws: er stapelt niets op. Was je een jaar backpacken, dan haal je de frontier in twee weken in — alles wat werkt wordt op dit moment door duizenden mensen tegelijk uitgeprobeerd en genadeloos gesorteerd, en jij komt gewoon opdagen voor de uitslag. Wie alleen hield van het mechanische deel van het vak heeft het zwaar; wie hield van dingen máken juist niet. Ruimte om te rouwen om het oude vak vindt hij prima. Wij schreven eerder over de keerzijden die hij hier laat liggen: wat er gebeurt met de weg van junior naar senior en waarom constante AI-hulp uitput.

Het concreetste hoofdstuk voor wie dit zelf wil doen (vanaf 1:31:46). Geen IDE maar de terminal: eerst tmux met panes, inmiddels Herdr, dat er meldingen bij doet zodra een agent een beslissing nodig heeft. Neovim gebruikt hij vooral nog als projectbrowser om diffs met hun omgeving te bekijken. Toen één machine niet meer volstond hing hij vier mini-pc's uit de kast aan KVM-adapters en een WireGuard-netwerk, en draait hij nu ongeveer zestien threads tegelijk. Meer kan de machine wel aan, hij niet. Programmeren is daarmee van single-threaded naar parallel geschoven, en de flow zit niet meer in de verdieping maar in de aaneenschakeling van beslissingen. Dat put uit zoals een uur racen uitput, zegt hij: bevredigend, maar niet vol te houden.

Zijn eigen conclusie is de interessantste: de mens in de lus is nu de limiet. Daarom bouwt hij een bot die 's nachts autonoom PR's en issues afhandelt en hem één mail per dag stuurt met wat er nog te beslissen valt, en experimenteert 37signals ermee om agents als collega's in Basecamp te zetten, met to-do's in plaats van chat — want chat verleidt je om te blijven wachten. Wie dit soort werk serieus inricht, wil weten of het ook echt sneller gaat in plaats van alleen drukker; daarvoor bestaat Agile Analytics, en schreven we hoe je DORA-metrics leest als AI de helft van je commits schrijft.

Een nieuwe Mac had 42 minuten nodig voor hij bruikbaar was, een nieuwe Windows-pc anderhalf uur (vanaf 1:44:11). Omarchy installeert in minder dan een minuut; het record staat op 45 seconden en met hardware-specifieke images mikt hij op twaalf. Dat lukte met domme, degelijke trucs: pakketten alvast inladen terwijl de gebruiker vijf vragen beantwoordt, en honderden megabytes uit de image snijden — het JetBrains-font dat als volledige familie 200 MB kostte terwijl er 16 MB nodig was. Hij vergelijkt het met McLaren-ingenieurs die 370 gram van een auto van 1.400 kilo halen, en citeert Mitchell Hashimoto: het streven naar uitmuntendheid heeft geen verantwoording nodig. Wij zouden het prozaïscher zeggen: elke seconde die uit een cyclus verdwijnt, verdwijnt daarna elke dag opnieuw — en dat is hetzelfde argument als voor de wachttijd in je build.

Hier staat het enige getal uit de aflevering dat een inkoper direct aangaat (vanaf 2:21:05). DHH liet een Python-library naar Rust vertalen: één prompt, geen kennis van Rust, geen regel code bekeken. Fable maakte een plan van acht stappen en was in vijfenveertig minuten klaar — al liep zijn abonnement halverwege leeg en maakte Opus 5 het op datzelfde plan af, wat op zichzelf iets zegt over hoe overdraagbaar zo'n plan is. Per token zou die run zo'n 550 dollar hebben gekost. Hetzelfde plan gaf hij daarna aan andere modellen. GPT Sol deed het in anderhalf uur voor 46 dollar, Grok 4.6 voor ongeveer 55, DeepSeek V4 Pro in twee uur drie kwartier voor 23. Twee goedkope modellen faalden volledig; één ervan probeerde te valsspelen door een bestaande implementatie in te pakken. Het resultaat was in alle geslaagde gevallen hetzelfde werkende programma, tien keer sneller dan het origineel — en na twee automatische optimalisatierondes zesenveertig keer.

Reken dat even om. Dezelfde uitkomst, een prijsverschil van vierentwintig keer, en de duurste run is de snelste. Voor wie zelf zou moeten leren waar dit over gaat: hij schat er negen maanden voor in. Dit is de kern van waarom softwareprojecten die de businesscase nooit haalden hem opeens wél halen — de webapplicatie die er niet van kwam, het klantportaal dat drie budgetrondes sneuvelde, de koppeling tussen twee systemen die te duur leek voor wat ze opleverde. Waar dat rekensommetje precies omslaat is per organisatie anders, en dat is het gesprek dat we voeren bij AI-consultancy.

Zijn standaardwerkwijze is simpel en overneembaar (vanaf 2:37:55): het werk laten doen door het ene model, en het daarna laten nakijken door een ander. Hij bouwt met Claude, laat Codex op de hoogste stand reviewen, en gooit er sinds kort Grok bij — en die vinden dingen. Ook Copilot, dat aanvankelijk vooral ruis produceerde, is volgens hem inmiddels goed genoeg om aan te zetten. Verrassend zou dat niet moeten zijn: geef het werk van een goede engineer aan een tweede goede engineer en er komt betere code uit. Hij haalt er een studie bij die Shopify's CTO liet doen op echte productie-incidenten: pull requests die door agents waren gereviewd, veroorzaakten minder storingen dan die door mensen waren nagekeken. Dezelfde modellen zijn ondertussen zo goed in het vinden van kwetsbaarheden dat het beveiligingsteam van 37signals er een lawine van patches aan overhield — en zijn scherpste zin gaat over de teams die geen lawine zien: dat betekent niet dat je systeem veilig is, dat betekent dat je blind bent, en je tegenstanders niet.

De ironie waar het gesprek op eindigt is fraai (vanaf 3:38:35). Alles waar Linux dertig jaar lang om werd afgeserveerd — alles is een configbestand of een CLI-tool, en foutmeldingen zijn onleesbaar voor mensen — is precies wat een agent nodig heeft. Een agent kent de broncode van je hele machine en kan die cryptische melding wél plaatsen; Omarchy heeft er een crash-watcher voor die aanbiedt het uit te zoeken. Een dichtgetimmerd besturingssysteem waar je hotkeys alleen met de muis kunt wijzigen, is in dit tijdperk juist een obstakel. Zelfs Linus Torvalds, meldt hij, verwelkomt AI-bijdragen aan de kernel.

En vanaf 3:59:24 de zin waar het hele gesprek op uitkomt: als er één programmeertaal mooier is dan Ruby, is het Engels. Daaronder zit een technisch punt dat vaak wordt onderschat. Programmeurs willen graag dat een model deterministisch is: dezelfde vraag, altijd exact hetzelfde antwoord. Dat is het niet, en dat is met opzet. Een taalmodel kiest zijn volgende woord uit een waaier van mogelijkheden, en de instelling die bepaalt hoeveel speling het daarbij krijgt heet de temperatuur. Zet je die op nul, dan krijg je elke keer hetzelfde antwoord — en nooit iets beters dan wat je zelf al had bedacht. Juist die speling noemt DHH het mooiste onderdeel van het geheel: zonder een beetje toeval geen creativiteit, ook niet bij mensen. En Lex vult aan wat elke goede prompt kenmerkt: strategische dubbelzinnigheid. Overspecificeer je, dan volgt het model je letterlijk en krijg je jouw oplossing, niet de betere. Schrijf je te vaag, dan krijg je willekeur. Dat register leren beheersen is de vaardigheid van dit moment, en het lijkt meer op redigeren dan op typen.

Ik herken het grootste deel van dit verhaal uit ons eigen werk, en ik ben het op één punt oneens met de toon: DHH werkt hoofdzakelijk in zijn eigen projecten, waar hij tegelijk opdrachtgever, architect en reviewer is. Dat is de makkelijke variant. Bij een klant met een bestaand landschap, een ERP dat niemand durft aan te raken, en een team dat over drie jaar nog onderhoud moet plegen, is de agent net zo snel — maar het oordeel eromheen wordt duurder in plaats van goedkoper. Daarom hebben wij het accent verlegd naar AI-native software engineering en naar de vragen die overblijven als implementatie goedkoop wordt: wat bouwen we niet, welke architectuur houdt stand, hoe herken je gegenereerde code die aannemelijk maar fout is, en hoe blijft het beheerbaar voor wie er dienst op heeft.

Praktisch betekent dat: maatwerksoftware waarvan de bouwtijd is ingestort maar de architectuurbeslissingen niet, bestaande systemen moderniseren in plaats van blind opnieuw genereren, tech consultancy voor teams die agents willen inzetten zonder in review te verdrinken, en meten of het écht sneller gaat. Ik schreef in 2023 dat het einde van programmeren onzinnige verkooppraat was. Dat vind ik nog steeds. Wat ik onderschatte, is hoe ver het vak zelf zou opschuiven — en deze vijf uur zijn het beste beschikbare verslag van die verschuiving door iemand die er niets mee te verkopen heeft.

Nieuwsgierig wat dit betekent voor jouw ontwikkelkosten, je bestaande software of je technologiekeuzes? Neem contact op. Kom met een echt probleem in plaats van een demo-aanvraag; dat levert een beter gesprek op.