Het artikel stelt dat de huidige waardering van frontier AI-labs gebaseerd is op een onrealistisch narratief van volledige autonomie. De auteur beargumenteert dat LLM's in de praktijk nog steeds arbeidsintensief toezicht nodig hebben omdat ze vatbaar zijn voor reward hacking en slecht generaliseren buiten hun trainingsdata.
De kern van het probleem is dat het voorkomen van fouten rigoureuze specificaties vereist. In de meeste domeinen is het schrijven van dergelijke specificaties duurder en complexer dan de feitelijke implementatie. Hoewel successen in de zuivere wiskunde (zoals Navier-Stokes via Lean) spectaculair lijken, zijn dit uitzonderingen omdat daar reeds rigoureuze kaders bestaan. Menselijke review als alternatief schaalt niet en is zelf ook foutgevoelig.
De auteur concludeert dat LLM's voor de meeste bedrijven zullen fungeren als een 'briljante maar onbetrouwbare stagiair'. Alleen bedrijven die goedkoop kunnen falen, zeer nauwe taken hebben, of reeds investeren in extreme validatie (zoals chipontwerp) kunnen autonome AI effectief inzetten. Bovendien suggereert de auteur dat een 'zwerm' van goedkope, open modellen praktischer is dan het vertrouwen op enkele dure frontier-modellen.
Waarom ik nog steeds bearish ben op LLM's na Navier-Stokes
Ik begin met een aantal stellingen waar de lezer over kan nadenken:
De waardering van de frontier labs is gebaseerd op het narratief dat zij een volledig geautomatiseerde, directe vervanging hebben geproduceerd (of in de zeer nabije toekomst zullen produceren) voor de meeste kenniswerkers. De huidige frontier-modellen vereisen echter arbeidsintensief toezicht en vangrails, zelfs bij de eenvoudigste taken.
Wie zich laat misleiden door de spectaculaire demonstraties van kracht (Navier-Stokes, FreeBSD RCE's, het HuggingFace-incident) en de retoriek van de labs, en daardoor gelooft dat er sprake is van betekenisvolle autonomie, hoeft alleen maar te kijken naar softwarebedrijven die nog steeds software-engineers uit het onderste kwartiel in dienst hebben en aannemen. Deze engineers zouden op de huidige benchmarks waarschijnlijk veel lager scoren dan de modellen die zij superviseren.
Modellen generaliseren alleen goed bij taken die zich in een kleine nabijheid bevinden van de specifieke taken waarop ze zijn getraind, en zelfs dan met ernstige kanttekeningen. De frontier-labs hebben een algemeen recept ontwikkeld om modellen bijna elke specifieke taak te leren waarvoor duidelijk gedefinieerde prestatieniveaus bestaan; veel taken zijn gedekt in de trainingsdata. Maar zelfs kleine verstoringen binnen een gedekte klasse van taken leiden tot compleet falen of reward hacking.
Het huidige probleem van reward hacking kan alleen worden opgelost door rigoureuze specificatie door domeinexperts. De tijd van domeinexperts is duur. Rigoureuze specificatie is op zichzelf een vaardigheid die een eigen expertise vereist, los van een specifiek probleemdomein. Zelfs veel bekwame software-engineers zijn hier slecht in. Voor de overgrote meerderheid van de domeinen is de overlap tussen domeinexperts en specificatie-experts lachwekkend klein.
De arbeidskosten van rigoureuze specificatie kunnen aanzienlijk hoger zijn dan die van de directe implementatie van een informele specificatie. De wereld van hardware-engineering biedt hiervoor een uitstekende casus: een typisch CPU-project heeft naar verluidt ongeveer drie keer zoveel specificatie- en validatie-engineers als ontwerp-engineers, en een verhouding van 5:1 is niet ongebruikelijk.
Wat erger is, is dat veel taken zich niet lenen voor een handig 'spec-and-forget'-regime, waarbij je één keer een specificatie schrijft en deze continu implementeert. Rigoureuze formele specificaties evolueren vaak in gesprek met inzichten die worden verkregen tijdens de implementatie volgens de informele specificatie. Voor taken die wel beschikken over hoogwaardige 'one-and-done'-specificaties (denk aan een uitvoerbare ISA-specificatie voor een familie van CPU-architecturen) zijn de kosten van verificatie tegen dergelijke specificaties met de huidige technologie onoverkomelijk. Dit maakt het gebruik van lagere-niveau specificaties noodzakelijk, die zowel duurder om te construeren zijn als veel kwetsbaarder voor wijzigingen in het ontwerp.
Navier-Stokes en uitspraken in de zuivere wiskunde zijn het absolute best-case scenario voor agentisch werk tegen een rigoureuze specificatie. De stelling zelf is al een rigoureuze specificatie. Het is decennia lang gecontroleerd door de wiskundige gemeenschap en de weergave in Lean is een eenvoudige vertaling, gedefinieerd in termen van beproefde wiskundige objecten uit mathlib. De verifieerder, de Lean-theorem prover, is uitgebreid gecontroleerd en specifiek ontworpen om de soorten onjuistheden te vermijden die het kwetsbaar zouden maken voor reward hacks.
Zelfs Lean en vergelijkbare theorem provers zijn niet onkwetsbaar: bugs in de correctheid hebben LLM's in het verleden in staat gesteld om valse bewijzen via de proof kernel te loodsen, en het is niet onwaarschijnlijk dat er meer van dergelijke bugs bestaan. Dit is echter de meest rooskleurige opstelling; de overgrote meerderheid van het menselijke kenniswerk ziet er niet zo uit. (Ik kom later terug op de weinige gebieden van kenniswerk die in dit opzicht wel lijken op zuivere wiskunde).
Het beste alternatief voor rigoureuze specificatie is menselijke review. Menselijke review schaalt echter niet goed naar de volumes aan output die taalmodellen produceren. Om het erger te maken, is zelfs deskundige menselijke review uiterst kwetsbaar voor reward hacking: denk aan de XZ-backdoor en de beruchte UMN-hypocriet-commits die in Linux terechtkwamen. Als menselijke review een kritiek onderdeel blijft van de agentische productielus, wordt het productietempo noodzakelijkerwijs beperkt door factoren zoals de limieten van menselijke tijd en aandacht. Dit is een absolute non-starter voor het scenario van "een datacenter vol genieën", waar CEOs van frontier-labs je willen doen geloven dat we nog maar een paar maanden verwijderd zijn.
De LLM als "briljante maar onbetrouwbare stagiair"
Als we dit alles samenvoegen, lijkt het erop dat LLM's voor de meeste domeinen zullen blijven aanvoelen als een cracked intern: snel en effectief in de handen van een volwassene, maar niet iemand aan wie je de sleutels van de zaak geeft. De meeste bedrijven zullen niet in staat zijn om volledig autonome AI te adopteren, niet vanwege een gebrek aan vaardigheden of een trage technologische adoptie, maar vanwege structurele redenen die inherent lijken aan de huidige architecturen.
Er zijn naar mijn schatting slechts drie klassen bedrijven die het gebruik van volledig autonome LLM's kunnen accepteren:
- Bedrijven die falen goedkoop kunnen accepteren: Bedrijven die anders stagiairs zouden aannemen, bedrijven die betrokken zijn bij snel prototypen, etc.
- Bedrijven die een kleine set nauw gedefinieerde taken nodig hebben met bestaande, duidelijke vangrails: Repetitief fysiek werk in een gecontroleerde omgeving, callcenters en klantenservice-chatwerk, etc.
- Bedrijven die de kosten van rigoureuze specificatie en validatie kunnen accepteren of alnatuurlijk dragen: Chipontwerp, medicijnontwikkeling en andere domeinen waar falen bij implementatie een existentieel risico vormt.
De eerste twee klassen zijn prijsgevoelig en hebben waarschijnlijk geen behoefte aan de sprong in redeneerkwaliteit die je ziet bij de overstap van goedkope naar frontier-modellen. De meeste van deze bedrijven worden het best bediend door open modellen die draaien op goedkope hardware, wellicht zelfs lokaal op de locatie van gebruik.
Voor de eerste en derde klasse lijkt het type 'fuzzy combinatorische zoektocht' dat heeft geleid tot spectaculaire resultaten in de wiskunde en beveiligingsonderzoek gevoeliger te zijn voor de breedte van de agentische zwerm (swarm width) dan voor de individuele redeneercapaciteit. Kijk bijvoorbeeld naar kleine open modellen die de Mythos CVE's reproduceerden die de hypecycle van het voorjaar van 2026 dreef. Als dat inderdaad waar is, is er des te meer reden om goedkope open modellen te gebruiken, omdat deze het mogelijk maken om dezelfde werklast uit te voeren met bredere zwermen.
Bedrijven in de derde klasse maken mogelijk nog steeds gebruik van frontier-modellen, hoewel het niet geheel duidelijk is of hun werk niet ook gedaan zou kunnen worden met goedkope modellen zoals DeepSeek v4.1 Flash. Het eerder genoemde voordeel van zwermbreedte geeft hen bovendien een extra reden om voor goedkopere modellen te kiezen. Een andere interessante eigenschap van deze bedrijven is dat ze over het algemeen zeer geheimzinnig zijn over hun intellectueel eigendom en waarschijnlijk niet enthousiast zijn over het versturen daarvan naar Anthropic of OpenAI, zelfs niet met overeenkomsten om de data niet te gebruiken voor training.
Nu zou men kunnen aanvoeren dat, zelfs als de frontier-labs het verloren zijn, het scenario van een "datacenter vol hersenloze zwermen" net zoveel AI-rekenkracht stimuleert als een scenario van kunstmatige superintelligentie. Het verschil is dat het datacenter vol genieën zelfsturend is en alleen wordt beperkt door de hoeveelheid rekenkracht die het kan consumeren, terwijl de zwermen van 'brainlets' zwaar beperkt zullen worden door hun menselijke orchestratoren. Mijn persoonlijke weddenschap is dat de impact hiervan veel verder zal reiken dan alleen de frontier-labs.
Waarom ik nog steeds bearish ben op LLM's na Navier-Stokes
Ik begin met een aantal stellingen waar de lezer over kan nadenken:
De waardering van de frontier labs is gebaseerd op het narratief dat zij een volledig geautomatiseerde, directe vervanging hebben geproduceerd (of in de zeer nabije toekomst zullen produceren) voor de meeste kenniswerkers. De huidige frontier-modellen vereisen echter arbeidsintensief toezicht en vangrails, zelfs bij de eenvoudigste taken.
Wie zich laat misleiden door de spectaculaire demonstraties van kracht (Navier-Stokes, FreeBSD RCE's, het HuggingFace-incident) en de retoriek van de labs, en daardoor gelooft dat er sprake is van betekenisvolle autonomie, hoeft alleen maar te kijken naar softwarebedrijven die nog steeds software-engineers uit het onderste kwartiel in dienst hebben en aannemen. Deze engineers zouden op de huidige benchmarks waarschijnlijk veel lager scoren dan de modellen die zij superviseren.
Modellen generaliseren alleen goed bij taken die zich in een kleine nabijheid bevinden van de specifieke taken waarop ze zijn getraind, en zelfs dan met ernstige kanttekeningen. De frontier-labs hebben een algemeen recept ontwikkeld om modellen bijna elke specifieke taak te leren waarvoor duidelijk gedefinieerde prestatieniveaus bestaan; veel taken zijn gedekt in de trainingsdata. Maar zelfs kleine verstoringen binnen een gedekte klasse van taken leiden tot compleet falen of reward hacking.
Het huidige probleem van reward hacking kan alleen worden opgelost door rigoureuze specificatie door domeinexperts. De tijd van domeinexperts is duur. Rigoureuze specificatie is op zichzelf een vaardigheid die een eigen expertise vereist, los van een specifiek probleemdomein. Zelfs veel bekwame software-engineers zijn hier slecht in. Voor de overgrote meerderheid van de domeinen is de overlap tussen domeinexperts en specificatie-experts lachwekkend klein.
De arbeidskosten van rigoureuze specificatie kunnen aanzienlijk hoger zijn dan die van de directe implementatie van een informele specificatie. De wereld van hardware-engineering biedt hiervoor een uitstekende casus: een typisch CPU-project heeft naar verluidt ongeveer drie keer zoveel specificatie- en validatie-engineers als ontwerp-engineers, en een verhouding van 5:1 is niet ongebruikelijk.
Wat erger is, is dat veel taken zich niet lenen voor een handig 'spec-and-forget'-regime, waarbij je één keer een specificatie schrijft en deze continu implementeert. Rigoureuze formele specificaties evolueren vaak in gesprek met inzichten die worden verkregen tijdens de implementatie volgens de informele specificatie. Voor taken die wel beschikken over hoogwaardige 'one-and-done'-specificaties (denk aan een uitvoerbare ISA-specificatie voor een familie van CPU-architecturen) zijn de kosten van verificatie tegen dergelijke specificaties met de huidige technologie onoverkomelijk. Dit maakt het gebruik van lagere-niveau specificaties noodzakelijk, die zowel duurder om te construeren zijn als veel kwetsbaarder voor wijzigingen in het ontwerp.
Navier-Stokes en uitspraken in de zuivere wiskunde zijn het absolute best-case scenario voor agentisch werk tegen een rigoureuze specificatie. De stelling zelf is al een rigoureuze specificatie. Het is decennia lang gecontroleerd door de wiskundige gemeenschap en de weergave in Lean is een eenvoudige vertaling, gedefinieerd in termen van beproefde wiskundige objecten uit mathlib. De verifieerder, de Lean-theorem prover, is uitgebreid gecontroleerd en specifiek ontworpen om de soorten onjuistheden te vermijden die het kwetsbaar zouden maken voor reward hacks.
Zelfs Lean en vergelijkbare theorem provers zijn niet onkwetsbaar: bugs in de correctheid hebben LLM's in het verleden in staat gesteld om valse bewijzen via de proof kernel te loodsen, en het is niet onwaarschijnlijk dat er meer van dergelijke bugs bestaan. Dit is echter de meest rooskleurige opstelling; de overgrote meerderheid van het menselijke kenniswerk ziet er niet zo uit. (Ik kom later terug op de weinige gebieden van kenniswerk die in dit opzicht wel lijken op zuivere wiskunde).
Het beste alternatief voor rigoureuze specificatie is menselijke review. Menselijke review schaalt echter niet goed naar de volumes aan output die taalmodellen produceren. Om het erger te maken, is zelfs deskundige menselijke review uiterst kwetsbaar voor reward hacking: denk aan de XZ-backdoor en de beruchte UMN-hypocriet-commits die in Linux terechtkwamen. Als menselijke review een kritiek onderdeel blijft van de agentische productielus, wordt het productietempo noodzakelijkerwijs beperkt door factoren zoals de limieten van menselijke tijd en aandacht. Dit is een absolute non-starter voor het scenario van "een datacenter vol genieën", waar CEOs van frontier-labs je willen doen geloven dat we nog maar een paar maanden verwijderd zijn.
De LLM als "briljante maar onbetrouwbare stagiair"
Als we dit alles samenvoegen, lijkt het erop dat LLM's voor de meeste domeinen zullen blijven aanvoelen als een cracked intern: snel en effectief in de handen van een volwassene, maar niet iemand aan wie je de sleutels van de zaak geeft. De meeste bedrijven zullen niet in staat zijn om volledig autonome AI te adopteren, niet vanwege een gebrek aan vaardigheden of een trage technologische adoptie, maar vanwege structurele redenen die inherent lijken aan de huidige architecturen.
Er zijn naar mijn schatting slechts drie klassen bedrijven die het gebruik van volledig autonome LLM's kunnen accepteren:
- Bedrijven die falen goedkoop kunnen accepteren: Bedrijven die anders stagiairs zouden aannemen, bedrijven die betrokken zijn bij snel prototypen, etc.
- Bedrijven die een kleine set nauw gedefinieerde taken nodig hebben met bestaande, duidelijke vangrails: Repetitief fysiek werk in een gecontroleerde omgeving, callcenters en klantenservice-chatwerk, etc.
- Bedrijven die de kosten van rigoureuze specificatie en validatie kunnen accepteren of alnatuurlijk dragen: Chipontwerp, medicijnontwikkeling en andere domeinen waar falen bij implementatie een existentieel risico vormt.
De eerste twee klassen zijn prijsgevoelig en hebben waarschijnlijk geen behoefte aan de sprong in redeneerkwaliteit die je ziet bij de overstap van goedkope naar frontier-modellen. De meeste van deze bedrijven worden het best bediend door open modellen die draaien op goedkope hardware, wellicht zelfs lokaal op de locatie van gebruik.
Voor de eerste en derde klasse lijkt het type 'fuzzy combinatorische zoektocht' dat heeft geleid tot spectaculaire resultaten in de wiskunde en beveiligingsonderzoek gevoeliger te zijn voor de breedte van de agentische zwerm (swarm width) dan voor de individuele redeneercapaciteit. Kijk bijvoorbeeld naar kleine open modellen die de Mythos CVE's reproduceerden die de hypecycle van het voorjaar van 2026 dreef. Als dat inderdaad waar is, is er des te meer reden om goedkope open modellen te gebruiken, omdat deze het mogelijk maken om dezelfde werklast uit te voeren met bredere zwermen.
Bedrijven in de derde klasse maken mogelijk nog steeds gebruik van frontier-modellen, hoewel het niet geheel duidelijk is of hun werk niet ook gedaan zou kunnen worden met goedkope modellen zoals DeepSeek v4.1 Flash. Het eerder genoemde voordeel van zwermbreedte geeft hen bovendien een extra reden om voor goedkopere modellen te kiezen. Een andere interessante eigenschap van deze bedrijven is dat ze over het algemeen zeer geheimzinnig zijn over hun intellectueel eigendom en waarschijnlijk niet enthousiast zijn over het versturen daarvan naar Anthropic of OpenAI, zelfs niet met overeenkomsten om de data niet te gebruiken voor training.
Nu zou men kunnen aanvoeren dat, zelfs als de frontier-labs het verloren zijn, het scenario van een "datacenter vol hersenloze zwermen" net zoveel AI-rekenkracht stimuleert als een scenario van kunstmatige superintelligentie. Het verschil is dat het datacenter vol genieën zelfsturend is en alleen wordt beperkt door de hoeveelheid rekenkracht die het kan consumeren, terwijl de zwermen van 'brainlets' zwaar beperkt zullen worden door hun menselijke orchestratoren. Mijn persoonlijke weddenschap is dat de impact hiervan veel verder zal reiken dan alleen de frontier-labs.
Groetjes,