AI-agent backlash: dezelfde discussie als jQuery in 2009

Het is 7 uur 's ochtends in Amsterdam en iemand uit het team heeft een link in Slack gegooid. Ask HN: Why is the HN crowd so anti-AI? Honderdnegen punten, en stijgend. Eronder vierhonderd reacties over hallucinaties, juniors die niet kunnen debuggen en de kosten van tokens. We lezen de eerste tien reacties. Eén van ons typt terug: deze thread heb ik eerder gelezen. In 2009. Toen ging het over jQuery.

De thread uit 2009, regel voor regel

HN voerde van 2008 tot 2010 telkens dezelfde discussie over jQuery. De vorm was altijd hetzelfde. Je hebt geen framework van 90 kilobyte nodig om document.getElementById aan te roepen. Juniors die jQuery gebruiken zullen de DOM nooit begrijpen. De selector engine is een black box. Mensen kopiëren code die ze niet snappen. De abstractie verbergt slechte markup en slecht ontwerp.

Sommige punten klopten. $().each in een strakke loop kon pagina's slopen. Selector chains verstopten quadratische queries. Een hele generatie front-end developers leerde $(this) voordat ze this begrepen. De klachten waren niet paranoïde. Ze klopten, in het klein.

En toch won jQuery, in het groot. Het draaide het grootste deel van het web van 2007 tot ongeveer 2015. De klaagthread heeft de adoptiecurve geen graad doen buigen.

De thread uit 2026, regel voor regel

Open de huidige Ask HN en vervang elke jQuery door AI-agent. De argumenten overleven de substitutie zonder kleerscheuren. Het model is een black box. Vibe coders leren nooit debuggen. Tokens zijn absurd duur. De agent verbergt slechte data en een ongedisciplineerd proces. Mensen leveren code op die ze niet kunnen lezen.

Ook hier klopt een deel. Vorige week stond op dezelfde HN-frontpagina Did Claude increase bugs in rsync?. Dat was geen vibe. Het was een claim over een echte codebase, met een echte bisect erbij. De volgende ochtend hebben we 'm in onze eigen reviewstroom serieus genomen.

De sceptici hebben dus geen ongelijk. Ze doen wat ze in 2009 ook deden. Ze hebben gelijk in het klein en ongelijk over welke black boxes blijven.

Wat de critici van 2009 goed zagen, en wat ze misten

Als je die oude threads nu terugleest, hadden de sceptici één punt dat blijft staan. Gebruik het waar het loont, bouw het saaie pad waar dat niet zo is. De teams die in 2010 goed leverden, waren de teams die jQuery inzetten voor de vier dingen die het echt oploste (event-normalisatie, AJAX, animatie, DOM-traversal) en overal elders bij vanilla bleven. De teams die slecht leverden, gebruikten $() voor getElementById en klaagden vervolgens over paginagewicht.

Dezelfde regel geldt nu. De agents in onze productiestack die hun kosten verdienen, zijn de agents die we hebben gebouwd als gereedschapsriemen, niet als orakels. De agents die we als orakel probeerden te lanceren, zijn teruggegaan naar de werkbank.

Drie plekken waar we nu agents bouwen die de sniff test van 2009 doorstaan

1. Facturen najagen, met een deterministische ruggengraat

De agent bepaalt niet wie er nagebeld wordt. Een SQL query op de facturatie-database bepaalt dat. Status = verzonden, vervaldatum < vandaag min 7 dagen, geen betaling binnen. Dat geeft een lijst terug. De agent leest elke regel, schrijft een mail in de toon van de klant en laat het concept zien voor één-klik akkoord. Er is een kostenplafond per dag. Er is een menselijke poort. Het geheel is auditbaar als een platte log.

Dit is het deel waar een scepticus uit 2009 begrip voor zou hebben. De harde beslissingen staan in code die je kunt lezen. Het zachte werk, de bewoording, is waar het model zijn geld verdient.

select id, client_id, amount, due_date
from invoices
where status = 'sent'
  and due_date < current_date - interval '7 days'
  and paid_at is null
order by due_date asc;

2. Legacy migratie-verkenner, geen migrator

Als er een klant binnenkomt met een Drupal 7 site (end of life sinds januari 2025, en ja, we komen ze nog steeds tegen in het wild) richten we niet zomaar een agent op de codebase met de opdracht om te migreren. We vragen 'm om te lezen. Lijst elke custom module op. Lijst elke hook-implementatie op. Lijst elk content type op en de modules die eraan komen. Output is een platte checklist die een mens regel voor regel in dertig seconden kan verifiëren.

Het migratieplan blijft bij een senior developer. De agent perst het discovery-werk van drie dagen terug naar veertig minuten. Een scepticus uit 2009 zou dit verheerlijkte grep met betere taal noemen, hij zou gelijk hebben, en we zouden het toch leveren.

3. RAG met bronvermelding en een weiger-budget

Antwoorden uit de documentatie van de klant komen terug met bestandspaden en regelnummers erbij. De agent weigert te antwoorden als de retrieval-score onder een drempel zakt. We loggen elke weigering. We behandelen het weigerpercentage als een productmetric, niet als een bug.

De versie uit 2009 hiervan is een zoekmachine die tien links teruggeeft. De versie uit 2026 is een zoekmachine die één zin, drie links en een eerlijk ik weet het niet teruggeeft als het corpus zwijgt. Dat eerlijke ik weet het niet is het deel dat de meeste teams overslaan. Het is ook het deel dat het systeem te vertrouwen maakt.

Het patroon onder alle drie

Geen van deze systemen maakt het model de beslisser. SQL bepaalt wie er nagebeld wordt. Het migratieplan is eigendom van een mens. De weigerdrempel is een getal in een config-bestand. Het model schrijft proza, leest structuur en vraagt om hulp wanneer dat hoort. Het is jQuery in 2026-kleren. Het vangt de cross-browser kuren van natuurlijke taal op, zodat de rest van de stack saai mag blijven.

Lees de HN-thread nog eens met die bril op. De klachten over magie zijn eigenlijk klachten over systemen waar het model autoriteit kreeg die het niet had verdiend. De klachten over kosten zijn eigenlijk klachten over prompts die SQL hadden moeten zijn. De klachten over juniors zijn eigenlijk klachten over een arbeidsmarkt die nog niet doorheeft wat de tool echt is.

Toen we de facturen-agent bouwden voor een Rotterdams accountantskantoor, liepen we precies hier tegenaan: in de eerste versie liet het model bepalen welke klanten nagejaagd werden, en het ging af en toe achter mensen aan die diezelfde ochtend per bankoverschrijving hadden betaald. We verplaatsten die beslissing naar een SQL query op het debiteurenboek en de pijnlijke mails hielden op. Het model schrijft nog steeds de tekst. Het kiest alleen de doelen niet meer.

Het kleinste wat je vandaag kunt doen: open de laatste AI-agent die je hebt uitgerold, vind één plek waar het model iets beslist wat een SQL query ook zou kunnen beslissen, en haal die beslissing uit de prompt en zet 'm in de database. Lees daarna de jQuery-thread van 2009 op HN terug, en merk op dat je 'm al kent.