Het einde van het programmeren

Vorige week is Bun 1.4 uitgebracht. Deze versie bevat de herschrijving van Bun van Zig naar Rust, wat schijnbaar meer dan een miljoen nieuwe regels Rust-code bevat. Hoewel dit in de programmeergemeenschap zorgde voor ophef over de taalwissel, denk ik dat het belangrijkste aspect van deze release is hoe de herschrijving is uitgevoerd en de schaal ervan. De details hiervan, samen met mijn eigen ervaringen en de aanstaande vooruitgang in AI, doen mij geloven dat we zijn aangekomen bij het einde van programmeren zoals we dat kennen.

Wat ik hiermee bedoel, is dat ik denk dat de handeling van het handmatig schrijven van code, waarbij andere mensen deze reviewen om bruikbare, werkende software te creëren, op weg is naar uitsterven. Of, in ieder geval, het zal worden overspoeld door een absolute vloedgolf aan bruikbare, werkende software die door agents wordt gemaakt, waarbij mensen alleen het eindresultaat beoordelen en niet de code zelf. We zullen meer software hebben dan ooit tevoren, maar het grootste deel van de code zal niet zijn geschreven of zelfs maar gelezen door mensen.

Om eerlijk te zijn, er zal ook een berg 'slop' ontstaan: buggy, nutteloze, verschrikkelijke en aanstootgevende software die niet voldoet aan het esthetische gevoel, het doel of de stijl van een programmeur. Maar er zal ook goed ontworpen, werkende software zijn die echte problemen oplost, zonder dat deze in detail door menselijke ogen is beoordeeld.

Deze explosie aan software is al te zien in deze grafiek uit het bericht van GitHub over hun storing op 17 augustus:

Sinds vorig jaar is er een steile exponentiële stijging in de hoeveelheid code die wordt geproduceerd. Mijn theorie is dat het grootste deel hiervan afkomstig is van zijprojecten, interne projecten binnen bedrijven (skunk works), of individuele gebruikers. Zaken die als niet-kritiek worden beschouwd. In de meeste bedrijven is er nog steeds aanzienlijke organisatorische frictie om individuele ontwikkelaars twee keer zoveel te laten releasen wanneer het gaat om producten die de business drijven, laat staan tien of honderd keer zoveel.

Bijna alle code in die grafieken is geproduceerd door modellen die momenteel niet tot de absolute top (de 'frontier') behoren. Het is geproduceerd door de frontier-modellen van enkele maanden geleden, wat betekent: niet door Fable 5 en niet door GPT 5.6 Sol.

Anthropic- en OpenAI-ontwikkelaars leven in de nabije toekomst

Bij het lezen van de details van de Bun Rust-herschrijving vallen enkele zaken op: het werd aangestuurd door één ontwikkelaar, Jarred Sumner, die werkte met een pre-release versie van Fable 5 en een schijnbaar onbeperkt token-budget. Hij creëerde het werkende framework waarin agents parallel konden werken om de Zig-codebase te vertalen naar Rust.

In de loop van 11 dagen produceerden meerdere agents 6.778 commits en verbruikten ze zoveel tokens dat dit bij reguliere API-prijzen ongeveer $165.000 zou hebben gekost.

Ik herinner me dat de ophef rond deze herschrijving eind mei begon, ruim voordat het bovenstaande blogbericht werd geschreven. Het werd pas bekend via een merge van de herschrijving, die een wijziging liet zien van +1.009.257 en -4.024 regels. Ik was verbijsterd door de schaal en speculeerde dat dit met Mythos was bereikt:

"Ik ben ook doodnieuwsgierig of dit is gedaan met onbeperkte Mythos-tokens. Is dit de nabije toekomst voor de rest van ons? Of is dit het nu en deden ze het met Opus 4.7-tokens? Mijn gok is het eerste. Dus het is een preview van wat later dit jaar mogelijk is." — @pauldix, 14 mei 2026

Mijn ervaring op dat moment was dat ik niet dacht dat zoiets mogelijk was met Opus 4.7; het moest dus de nog niet uitgebrachte Mythos zijn die een herschrijving zoals deze, die ook daadwerkelijk werkte, mogelijk maakte.

Het feit dat AI een miljoen regels code schreef en dit vervolgens in de loop van de volgende maanden verfijnde om een betrouwbaar stuk software te produceren dat nu op miljoenen machines van ontwikkelaars draait, is absoluut verbijsterend. Men kan zeggen: "nou, dat is niet zo indrukwekkend omdat ze een referentiepunt (een orakel) hadden om mee te vergelijken, dus was het simpel om van de ene taal naar de andere over te stappen", maar ik denk dat dat de prestatie tekortdoet. Als je een verificatiesysteem kunt bouwen en de juiste richting kunt geven, kan AI een zeer complex en geavanceerd stuk software produceren en dit blijven verfijnen tot het simpelweg werkt.

Als je let op wat Anthropic- en OpenAI-ontwikkelaars de afgelopen maanden op X hebben gezegd, verschipen ze each tientallen of honderden PR's (pull requests) per week en hebben ze hun focus verlegd naar een hoger niveau in de stack. Dit is logisch, want het is voor een ontwikkelaar niet echt mogelijk om elke week honderden PR's aan code nauwgezet te reviewen en tegelijkertijd eigen werk te produceren.

Als we hun publieke uitspraken voor waar aannemen, voeren ze geen nauwkeurige review meer uit van elke regel code die wordt verzonden. Ze besteden hun tijd aan het bouwen van systemen, prompts en verificatietools om AI's software op grote schaal en met hoge snelheid te laten produceren. Althans, dat is hoe ik het interpreteer wanneer ze spreken over 'loops'.

Toch opereren zij in een wereld waarin ze onbeperkte toegang hebben tot Fable en Astra (het volgende model van OpenAI). Zij leven in een nabije toekomst die wij 'gewone stervelingen' waarschijnlijk pas over een jaar zullen ervaren. Hun ervaring met het gebruik van AI voor softwareontwikkeling is niet dezelfde als die van ons, die in het veld wachten tot onze wekelijkse Fable-toewijzing is gereset.

De release van Bun 1.4 geeft een glimp van wat mogelijk is als je Fable-niveau intelligentie koppelt aan bijna onbeperkte tokens: softwarelevering op schaal, die werkt, zoals bewezen is door miljoenen werkende implementaties.

Ervaringsverslag uit de praktijk

Ik heb twee recente anekdotes uit mijn eigen ervaring. Mijn gevoel is dat Fable kwalitatief anders is dan vorige modellen, vergelijkbaar met hoe mensen merkten dat Opus 4.5, uitgebracht eind november, anders was. Het is een drempel overgegaan waarbij meer kan worden geproduceerd met instructies op een hoger niveau en minder supervisie. Ik kan vereisten, architectuur en instructies geven voor een feature die ik wil ontwikkelen, en het model is in staat om over meerdere werkuren een volledig functionerende eerste versie te maken zonder verdere interactie van mijn kant.

Mijn twee voorbeelden zijn zaken die nog niet in InfluxDB zijn opgenomen, maar nieuwe mogelijkheden die ik in een fork had gebouwd. Ik koos deze om te zien wat mogelijk was met het nieuwe model.

Het eerste is de Iceberg-integratie, waardoor data in InfluxDB toegankelijk wordt via Iceberg REST, of op een externe S3-bucket en Glue-catalogus. Dit is een complexe feature die het volgende vereist:

• API & CLI om de feature in te schakelen.
• Implementatie van de Iceberg REST API.
• Diepe koppelingen met de compactor om Iceberg-manifesten en Parquet-data in de externe opslag te creëren.
• Creatie van Iceberg-manifesten of requests naar Glue.
• S3 API geïmplementeerd in InfluxDB voor niet-export scenario's.

Dit gaat om duizenden regels implementatie- en testcode. Ik schetste het ruwe architectuurontwerp en de vereisten, en stuurde Fable vervolgens aan om het werk te doen via sub-agents, het triggeren van code reviews en het superviseren van het proces. Veertien uur later had het een werkende versie geproduceerd. Daarna instrueerde ik het om alles end-to-end te verifiëren met een draaiende InfluxDB-cluster en met DuckDB en PyIceberg als externe clients. Het loste enkele bugs op en verifieerde dat alles werkte.

Het tweede voorbeeld is de creatie van een edge data replicatiesysteem voor InfluxDB. Dit bestaat uit meerdere individuele InfluxDB-nodes die als satellieten fungeren en periodiek gecomprimeerde data repliceren naar een centraal InfluxDB-cluster. Het definieert:

• API om in te stellen wat er gerepliceerd wordt en met welke frequentie.
• CLI voor toegang tot bovenstaande.
• Updates voor de compactor, die wordt gebruikt om data te filteren, aggregeren en gecomprimeerde data te creëren voor replicatie, inclusief tracking om te weten wat is verzonden en wat resteert.
• API voor de edge-node om catalogusinformatie te raadplegen voor het replicatie-payload.
• API voor het ontvangen van gecomprimeerde blokken data in de pipeline.
• Metrics en systeemtabellen om inzicht te krijgen in de gehele opzet.

Ik legde de architectuur uit en gaf voorbeelden van hoe de gebruikerservaring eruit moest zien. Ik werkte samen met Fable om een ontwerp te produceren en instrueerde het vervolgens om het werk uit te voeren, terwijl ik als supervisor optrad. Na 28 uur was er een grotendeels functionerende implementatie.

Vervolgens instrueerde ik het om dit te implementeren binnen onze testinfrastructuur in AWS, de metrics en logs te observeren en bugs op te lossen terwijl het proces vorderde. Na een paar korte iteraties kwam het tot een end-to-end werkende implementatie, die enkele maanden later nog steeds draait. Later liet ik het zelfs een UI bouwen die de replicatieacties tussen nodes toont met datasnelheden, gewoon omdat het kon.

Natuurlijk is geen van deze zaken momenteel uitgebracht of ondersteund, en ik zou het niet 'productie-klaar' noemen. Je zou kunnen zeggen wat velen zeggen over AI: dat het helpt om een prototype sneller te bouwen. Maar dat is in dit geval onvoldoende erkenning.

Het prototype is werkende software. En de verbetering en het testen van dat prototype wordt verder mogelijk gemaakt door meer verbeter-loops met de AI. Het wordt beter door meer testen en verificatie, niet door menselijke code reviews, maar door gebruik en testen.

Ik heb dit alles gedaan met een wekelijkse Fable-toewijzing en mijn abonnement (ik moest een week wachten tussen sessies). Wat ik niet heb kunnen doen, is dit in de cloud zetten in een verbeter-loop met onbeperkte Fable-credits. We kunnen ons de honderdduizenden dollars aan maandelijkse kosten niet veroorloven die ik waarschijnlijk zou maken als ik de top frontier-agent 24/7 mijn wil zou laten uitvoeren.

Jarred produceerde de Rust-herschrijving in 11 dagen, maar had daarna maandenlang agents aan continue verbeteringen laten werken voordat het als een officieel ondersteunde release werd uitgebracht. Het prototype is het begin, maar de agent helpt je ook om het geïtereerde, verbeterde en gehardeerde productie-klare product te leveren.

De nabije toekomst voor de programmerende 'gewone stervelingen'

Vorig jaar op dit moment hadden we Opus 4.1 en GPT-5. Nu kun je betere intelligentie kopen voor een fractie van de prijs. We kregen Opus 4.5 en GPT 5.2 eind november en begin december vorig jaar. Dit zijn de twee modellen waardoor elke CTO tijdens hun wintervakantie in paniek raakte over hoe het mogelijk was om simpelweg naar believen features en software te creëren.

Ik verwacht dat we dit jaar nog één of twee grote releases van OpenAI en Anthropic zullen krijgen. Mijn beste gok is dat we in september Astra van OpenAI krijgen, en dat deze van de Mythos/Fable-klasse zal zijn en waarschijnlijk krachtiger dan Fable 5.

Ik verwacht dat de Fable- en Astra-equivalenten van de drempeloverschrijdende Opus 4.5- en GPT 5.2-releases eind dit jaar of begin volgend jaar komen.

Dat niveau van modelintelligentie en capaciteit zal in staat zijn om elke feature die je kunt bedenken voor je software te creëren. En het zal werken. En het kan het voor je testen en verifiëren. Het zal dit doen zo snel als jij de code wilt ontvangen. De enige vraag zal zijn: wat wil je releasen? En wat wil je ondersteunen?

Tegen het einde van volgend jaar zal dit niveau van intelligentie goedkoop genoeg zijn dat de meesten van ons er fulltime mee kunnen werken, zoals Jarred kon werken met de pre-release Fable om Bun 1.4 te produceren.

In nog een jaar of twee zullen we brede toegang krijgen tot systemen die tokens kunnen produceren met een snelheid van 10x tot 100x, tegen een fractie van de kosten. Zie de Cerebras C4-aankondiging en de OpenAI Jalapeño-resultaten. Bredere, goedkopere toegang tot frontier-intelligentie met ongelooflijke snelheden is onderweg.

Door organisatorische traagheid zal er waarschijnlijk nog een decennium lang sprake zijn van mensen die handmatig code schrijven en hun collega's elke regel laten reviewen. Veel, zo niet de meeste, bedrijven zullen software blijven ontwikkelen zoals ze dat altijd hebben gedaan.

Maar de meest productieve softwaremakers zullen dat doen zonder te programmeren in traditionele zin. Ze zullen AI's aansturen, harnesses creëren, softwarefabrieken bouwen, en QA- en verificatiesystemen opzetten die werkende software sneller leveren dan we ooit hebben gezien.

En we zullen op het punt zijn beland waar er meer draaiende productiesoftware is geschreven door AI dan door mensen. Dat zal het einde van het programmeren zijn.