We moeten ambitieuzer zijn met de software die we bouwen

Er is begrijpelijkerwijs veel scepsis over projecten als pgrust, omdat er zoveel laagwaardige, door AI gegenereerde projecten zijn. Als ik Malis niet kende en er niet in zou duiken, zou ik aannemen dat pgrust gewoon een ander 'vibeslop'-project is dat nooit zal werken. Maar ik ken Malis goed genoeg om zijn werk te vertrouwen. Als je er dieper in kijkt, zie je dat hij bij het testen van pgrust zo grondig te werk gaat dat hij zelfs echte bugs in Postgres ontdekt. Voorbeelden hiervan zijn:

• Een numerieke bug die ervoor kan zorgen dat geldige SP-GiST-operaties mislukken.
• Een format-cache-bug die onjuiste resultaten uit JSONPath kan veroorzaken.
• Een pgcrypto-bug die latere operaties kan laten falen.
• Meerdere bugs op het gebied van geheugensafety in de dictionary loader.
• Een bug met betrekking tot 'money overflow'.

Dit betekent niet dat pgrust volledig vrij is van bugs, maar het geeft wel aan dat er aanzienlijk veel getest wordt. Zelfs als pgrust zelf nooit succesvol wordt, zal de poging Postgres op een duurzame manier hebben verbeterd. De belangrijkste troef van pgrust is overigens de performance; mocht het project falen, is het mogelijk dat sommige van de gedemonstreerde optimalisaties hun weg vinden naar Postgres of Clickhouse.

De realiteit van moderne softwarebouw

Als consument van software zie je overal trage programma's waarvan de maker claimt dat ze snel zijn op basis van twijfelachtige benchmarks. Laagwaardige software die simpelweg niet werkt, is algemener dan ooit.

Maar voor een bouwer van software maakt het niet uit dat de meeste projecten 'vibeslop' zijn. Je kunt dingen bouwen zoals pgrust, of andere projecten die in het verleden te groot waren om haalbaar te zijn. Als je een redelijk werk levert wat betreft testen en benchmarking, kan de kwaliteit uiteindelijk goed genoeg zijn voor echt gebruik.

Wat mij fascineert, is hoe de mogelijkheden zijn gevorderd, waardoor we veel meer kunnen doen. Toen ik hoorde dat OpenAI Cerebras zou gebruiken voor hun SOTA-modellen (en niet alleen voor snelle, maar laagwaardige modellen), keek ik naar waar de tijd op mijn computer naartoe zou gaan als ik een SOTA-model zou gebruiken dat 10 tot 100 keer sneller is. Enkele zaken die toen een bottleneck vormden (en die erger zouden worden met een sneller model) waren:

• Ripgrep
• Het compileren van Rust
• Syscall- en filesystem-overhead

Op het niveau van een "het werkt voor mij"-project zijn dit zaken die serieus verbeterd kunnen worden. Hoewel ik weinig vrije tijd heb, heb ik het volgende gebouwd:

1. Een regex-engine die kan worden aangepast om sneller te zijn dan andere general-purpose regex-libraries voor specifieke workloads.
2. Een ripgrep-fork die de native code-compiler van de regex-engine gebruikt en sneller is voor mijn codex-ripgrep workloads (hoewel een tekstindex de betere oplossing is, was dit een "just for fun"-project).
3. Een versie van Rust die de builds voor mijn projecten versnelde (een enorme verbetering voor cold builds, matig voor warm builds).

Voor syscalls en filesystem-overhead hielp de overstap van Mac naar Linux al aanzienlijk. Met moderne schijven is er geen reden meer om de *nix filesystem API te gebruiken. Vroeger zou het bouwen van een developer toolchain die direct I/O gebruikt in plaats van normale filesystem-operaties een absurde onderneming zijn geweest, maar dat is nu volledig haalbaar.

Voor iemand als ik, die niets weet van regexes, string-matching-algoritmen, compilers of interpreters, zou deze set projecten een jaar of langer hebben gekost om tot een "werkt voor mij"-kwaliteit te komen. In plaats daarvan kostte het me slechts een handvol uren. Natuurlijk zou het veel meer werk kosten om deze tools tot een niveau te tillen dat geschikt is voor een open-source project, maar de versnelling van het proces is ongelooflijk.

Het doorbreken van het pre-agentische kostenmodel

Mijn interpretatie van Malis' uitspraak is dat mensen simpelweg niet beseffen dat deze zaken nu makkelijk zijn. Ik zie mensen dagelijks klagen dat Rust-compilatie traag is en de ontwikkelsnelheid beperkt. Je kunt simpelweg een Rust-interpreter schrijven of de compilatie direct versnellen.

Deze problemen blijven bestaan omdat mensen impliciet vasthouden aan een 'pre-agentisch' kostenmodel. Tien jaar geleden was de persoon die een nieuwe compiler implementeerde omdat de huidige te traag was, vaak hetzelfde type persoon dat een nieuwe 3D-game-engine begon te bouwen wanneer hij een indie-game wilde maken: het type persoon dat nooit iets echt afmaakt en publiceert. De meeste productieve programmeurs die ik ken, hebben nog steeds een aversie tegen dit soort projecten, ook al is het nu volkomen redelijk om dit te implementeren.

Een ander voorbeeld is Azul AI, dat supermenselijk is in 'matched time controls'. Met GPT-5.1/5.2 en nul voorkennis over AI, kostte het me ongeveer 5 uur om iets supermenselijks te maken, en ongeveer 20 uur om wat op dat moment de sterkste AI leek te zijn. Gabriel Cangussu bouwde onlangs een AI die mijn AI verplettert, en het kostte hem aanzienlijk minder tijd.

Een belangrijk verschil is dat modellen zoals Fable 5.1 en Opus 5.5 een veel beter begrip hebben van bordspel-AI's. Toen ik GPT-5.1/5.2 gebruikte, waren bijna alle suggesties fout en moest ik veel sturen. Als ik het model een codebase of een paper liet lezen om technieken te implementeren, faalde het. Wanneer het model zo ver verwijderd is van het juiste resultaat, is het tijdrovend om te controleren of het model het goed heeft gedaan, omdat je zelf genoeg over het onderwerp moet leren om de claims te kunnen verifiëren. Met de nieuwste modellen is dit proces echter enorm versneld.

Verificatie en de paradox van productiviteit

Ik heb een test gedaan met GPT-5.6 Sol waarbij zstd werd geïmplementeerd op medium en xhigh settings. Toen ik deze evaluaties herhaalde met GPT-6 Astra, was het model zo goed dat ik andere evaluaties moest zoeken. GPT-6 Astra slaagt er in meer dan 99% van de tijd in om alle geregistreerde tests voor zstd te passeren, zelfs onder beperkende omstandigheden zoals het gebruik van TDD (en dit deed het goedkoper, voor ongeveer $1).

Uiteindelijk ben ik overgestapt naar de IMAP RFC, die 5.6 Sol niet effectief kon implementeren, en Pandoc. Het implementeren van Pandoc is een flinke opgave, omdat het veel verschillende formaten moet kunnen lezen en schrijven.

Inputformaten Pandoc: {html, docx, xlsx, pptx, csv, markdown, gfm, commonmark, commonmarkx, markdownstrict, markdownmmd, markdownphpextra, markdown_github, rtf, epub, odt, tsv, latex, ipynb, mediawiki, rst, asciidoc, bibtex, biblatex, org, typst, jira, docbook, endnotexml, ris, opml, dokuwiki, textile, man, mdoc, jats, csljson, fb2, pod, vimwiki, djot, creole, tikiwiki, twiki, t2t, haddock, muse, json, xml, native}

Outputformaten Pandoc: {pdf, html, html4, docx, plain, pptx, markdown, gfm, commonmark, commonmarkx, markdownstrict, markdownmmd, markdownphpextra, markdowngithub, rtf, epub, epub2, odt, latex, ipynb, mediawiki, rst, asciidoc, asciidoclegacy, bibtex, biblatex, org, typst, bbcode, bbcodephpbb, bbcodesteam, bbcodexenforo, bbcodefluxbb, bbcodehubzilla, jira, docbook, docbook4, revealjs, beamer, opml, dokuwiki, textile, man, texinfo, context, jats, jatspublishing, jats_articleauthoring, tei, icml, opendocument, csljson, fb2, ansi, chunkedhtml, djot, xwiki, zimwiki, vimdoc, haddock, markua, muse, ms, slidy, s5, dzslides, slideous, json, xml, native}

Wanneer mensen zeggen dat "software is opgelost" omdat de nieuwe modellen alles in één keer goed doen, merk ik dat dit niet waar is. Het is waar dat modellen meer zaken kunnen 'one-shotten', maar dat betekent simpelweg dat ik aan ambitieuzere projecten begin waar modellen nog steeds worstelen. De kloof tussen wat een model effectief kan verifiëren zonder veel begeleiding en wat het kan implementeren, wordt juist groter.

Tegenperspectief: Moeten we minder ambitieus zijn?

Yossi Kreinin plaatste hier een kritische kanttekening bij. Hij stelt dat de meeste mensen juist minder ambitieus zouden moeten zijn met AI-software, anders riskeren ze een totale mislukking. Veel problemen lenen zich niet goed voor "agentische loops" omdat er geen duidelijke pass/fail-criteria zijn. Mensen hebben vaak moeite met het redeneren over grote 'black boxes' die ze wel kunnen beperken, maar waarvan ze de innerlijke werking niet begrijpen.

Yossi waarschuwt ook voor het versnellen van flows met AI zonder diepe kennis. Je voegt dan vaak rommelige code toe die overfit is voor de specifieke testcase, maar niet generaliseert of onderhoudbaar is. Als een manager mensen pusht om willekeurige delen van software "snel" te maken met AI zonder dat zij begrijpen hoe het systeem gedekomposeerd moet worden, is dat een gevaarlijke situatie.

Mijn reactie hierop is dat dit analoog is aan de discussie over productiviteitsstijgingen van 100x of 1000x. Sommige dingen worden extreem versneld, andere helemaal niet. Als je precies hetzelfde doet als vijf jaar geleden, maar dan met AI, is de winst beperkt (Amdahl's law). Maar als je kiest wat je versnelt, kun je zaken aanpakken die voorheen te duur waren.

Specifieke voorbeelden en niche-tooling

Er zijn veel voorbeelden van "werkt voor mij"-tooling die vroeger economisch onhaalbaar waren.

Voorbeeld: De Neovim Lua-functie van Peter Geoghegan Peter liet Fable een custom Neovim Lua-functie implementeren die code formateert volgens zeer specifieke voorkeuren. Hij gebruikt een fork van bsd_indent genaamd pgindent. Omdat pgindent alleen hele C-bestanden kan formatteren en niet specifieke reeksen regels, gebruikt de functie tree-sitter om intelligent het juiste subset van de code te bepalen en terug te kopiëren naar de buffer. Daarnaast genereert de functie dynamisch extra typedefs via clangd om te voorkomen dat de formatting onjuist is door een verouderd typedef-bestand. Peter kent geen Lua en heeft een vaag begrip van hoe het werkt, maar de tool functioneert perfect.

Voorbeeld: Niche games Ik heb games laten bouwen die ik zelf wilde spelen, maar die commercieel niet interessant zijn. Zo wilde ik een spel spelen dat gevechten implementeert zoals beschreven in de Star Wolf-boeken van David Gerrold (een soort onderzeebootgevechten). Dit is een extreem niche genre dat de meeste mensen saai vinden. Ik zou nooit 20 uur besteden aan het handmatig implementeren hiervan om het vervolgens twee uur te spelen, maar met een AI-agent kostte het me 5 minuten.

De toekomst van programmeren en AI-labs

Ik ben sceptisch over de "saaspocalypse", maar ik geloof wel dat LLM's veel nuttige software schrijven die op elke andere manier krankzinnig oneconomisch zou zijn om te bouwen. Er is een subset van software die voor een mens simpelweg te tedious is om te onderhouden in verhouding tot de waarde die het oplevert.

Tegelijkertijd is het waarschijnlijk dat AI-labs veel van deze tools snel irrelevant maken. Bijvoorbeeld: ik heb een tool die Codex herstart wanneer hij een memory leak vindt. OpenAI zal dit waarschijnlijk oplossen, waardoor mijn tool waardeloos wordt. Ook mijn Rust-interpreter is niet optimaal omdat ik niet het token-budget heb om een compatibele fork van de Rust-compiler te onderhouden, maar OpenAI kan dat wel.

Toch zijn programmeervaardigheden nu relevanter dan ooit. Er is een paradox gaande: het hebben van de vaardigheden die modellen juist vervangen, maakt je effectiever in het gebruik van die modellen. Zoals Max Bittker stelt: modellen zijn erg goed in het maken van 'vervalsingen', en de expertise die nodig is om een vervalsing te onderscheiden van het echte werk, neemt toe naarmate de modellen verbeteren.

Slotbeschouwing over ambitie

In deze context betekent "ambitieus" simpelweg: meer doen dan voorheen mogelijk was. Of het nu gaat om het bouwen van een groot project dat voorheen onhaalbaar was, of het maken van een super-gespecialiseerde tool die voorheen de tijd niet waard was; beide komen voort uit het feit dat het produceren van software veel gemakkelijker is geworden.

De snelheid van verandering is zo groot dat veel mensen niet beseffen wat er nu mogelijk is. Er is een informatiegradiënt waarbij slechts enkelen buiten de AI-labs echt weten hoe de meest productieve mensen de modellen vandaag de dag gebruiken. We moeten die kans grijpen en ambitieuzer zijn.