AI-coding hype: drie dingen die we in 2026 nog zelf schrijven

Het is dinsdag, standup. Onze backend-lead praat ons door een betalings-reconciliatiebug die maandag vier uur van zijn dag opvrat. Halverwege de tweede alinea stelt iemand de voor de hand liggende 2026-vraag: waarom heeft een agent dit niet gewoon geschreven? Hij kijkt niet op van zijn toetsenbord. Hij zegt: "Omdat ik dan nog steeds aan het debuggen was wat de agent had geschreven."

Dat antwoord is bij ABN een kleine regel geworden. We leveren AI-agents als vak. Veertien van die agents draaien op dit moment in productie bij klanten. En er zijn precies drie plekken in onze eigen codebase waar we de code nog zelf schrijven, omdat een agent meer kost om te begeleiden dan om te vervangen.

Voordat we bij die drie komen, telt de framing.

De parallel met 2014

In 2014 opende elk klantgesprek met het woord "mobile-first." Het was een echte verschuiving. Mobiel verkeer had desktop ingehaald, advertentiebudgetten volgden, en elk bureau dat zijn pijplijn niet ombouwde voor kleine schermen verloor het volgende contract. Wij bouwden om. Iedereen die we respecteerden ook.

We zagen ook een generatie bureaus "mobile-first" verkopen als toverwoord, er een premium voor vragen, en stilletjes dezelfde desktopsites opleveren met een CSS media query erop geplakt. De golf was echt. De hype eromheen was dat niet.

De AI-coding golf in 2026 ziet er identiek uit. De verschuiving is echt. Het infrastructuurwerk om coding agents daadwerkelijk bruikbaar te maken is het meest interessante probleem dat we op dit moment aanraken, en een Hacker News post over harness engineering met Codex haalde deze week niet voor niets de frontpage. We gebruiken deze tools elke dag. Ze zijn het verschil tussen een schatting van vijf dagen en een dag op het meeste greenfield-werk.

Maar net als in 2014 is de golf ongelijk. Er zijn categorieën waar een agent het werk in één hap opeet, en categorieën waar het werk de agent opeet.

Wat er veranderde en wat niet

Mobile-first was een apparaatverschuiving. De gebruiker ging van een 24-inch monitor naar een 5-inch scherm met één duim. Het engineering-probleem was layout en bandbreedte. Zodra je een build pipeline had die een responsive bundle opleverde, was het probleem voor duizenden pagina's tegelijk opgelost.

AI-coding is een waarschijnlijkheidsverschuiving. Het model produceert code die meestal klopt en soms niet, en de foute gevallen zijn niet willekeurig verdeeld. Ze clusteren precies op de plekken waar foutzijn het duurst is. Dat clusteren is wat de rekensom rond zelf schrijven verandert.

Een senior engineer die de pull request van een agent reviewt, moet elke regel lezen alsof dit precies het geval kan zijn waarin de agent vol vertrouwen een function signature verzon, een <= verwisselde voor een <, of een bedrag in centen teruggaf uit een functie waarvan de caller aanneemt dat hij euro's krijgt. De reviewtijd op die PR's is soms langer dan de tijd die het had gekost om de code vanaf nul te schrijven.

Dat zijn de babysit-kosten. Wanneer de babysit-kosten hoger liggen dan de schrijfkosten, schrijf je zelf.

Waar we nog zelf schrijven

Geldberekeningen en payment-idempotency

Alles wat een euro van het ene grootboek naar het andere verplaatst, schrijven we zelf. We laten geen agent de functie genereren die btw berekent op een gedeeltelijke refund, de retry-logica rondom een Stripe webhook, of de afleiding van de idempotency key voor een terugkerende afschrijving.

Twee redenen. Ten eerste is de failure mode asymmetrisch: een refund berekend op 21% in plaats van 9% belandt in een Belastingdienst-audit, niet in een unit test. Ten tweede is het juiste patroon gedocumenteerd en klein. De idempotency-key richtlijn van Stripe past op één pagina, en zodra je de wrapper één keer hebt geschreven, hergebruik je hem. Er valt voor een agent niets te ontdekken dat een mens die de docs leest niet al heeft vastgelegd.

Dezelfde logica geldt voor valuta-berekeningen. Floats zijn een bekende val. We gebruiken overal integer minor units, met één Money type dat weigert verschillende valuta te vergelijken. Een agent genereert vrolijk code die 12.34 teruggeeft terwijl de caller 1234 wilde. De reviewkosten om dat op elke PR op te vangen liggen hoger dan de schrijfkosten.

Database-migraties

Elke productiemigratie schrijven we zelf. Niet de schema diff, die kan een tool genereren, maar het runbook eromheen: welke statements een table lock pakken, welke CREATE INDEX CONCURRENTLY nodig hebben, welke gesplitst moeten worden in een backfill-fase en een constraint-fase, en hoe de rollback eruitziet als de backfill halverwege staat wanneer de deploy gepauzeerd wordt.

Een migratie is een eenrichtingsdeur onder belasting. Een agent die een migratie oplevert die om 11:00 op een woensdag een ACCESS EXCLUSIVE lock pakt op een orders-tabel van 40 miljoen rijen, heeft net een uur omzet weggevaagd. We hebben er genoeg gezien in legacy-reddingen om permanent sceptisch te zijn. De PostgreSQL docs over concurrent index creation zijn duidelijk over de afwegingen, en de kosten van het misgaan worden betaald in klantvertrouwen, niet in test failures.

De agent kan ons helpen het runbook te schetsen en mee te reviewen. Hij schrijft de finale versie niet.

Tijdzone- en schedulingcode

De derde verrast mensen. Alles wat met tijdberekening te maken heeft, schrijven we zelf. Dat omvat reminder-cadansen, cron expressions, zomertijd/wintertijd-overgangen, en de "stuur dit om 09:00 lokaal voor elke gebruiker"-loop die bijna elk product heeft.

Tijdzones zijn geen programmeerprobleem. Het is een politiek probleem uitgedrukt in code. De IANA tz database wordt meerdere keren per jaar geüpdatet omdat overheden de regels wijzigen. Een agent getraind op een snapshot van de wereldwijde source code produceert code die er goed uitziet en slecht veroudert. De bugs komen zes maanden later boven, op één zondag in oktober, in één land, voor gebruikers die geen tickets indienen in jouw taal.

We schrijven deze code zelf, op één plek, met één library, met een testsuite die de tz-data versie vastpint. We laten een agent het niet opnieuw genereren.

Wat de parallel daadwerkelijk voorspelt

De mobile-first golf leverde twee duurzame uitkomsten op. De studio's die het serieus namen, bouwden hun pijplijnen om en bestaan nog. De studio's die het als slogan zagen, niet. Datzelfde geldt voor deze golf. De studio's die echte review-pijplijnen bouwen rond coding agents, met checks, gates en mensen op de gevaarlijke paden, blijven opleveren. De studio's die een chat in de editor plakken en het resultaat opleveren, lopen de komende twaalf maanden tegen een payment-math bug, een migration outage of een zomertijd-ramp aan.

De omgekeerde failure mode is ook echt. Helemaal weigeren om agents te gebruiken is de 2014-variant van alleen voor desktop bouwen. Dat raden we niemand aan.

De eerlijke positie is de saaie. Zet agents in op het werk waar meestal-goed acceptabel is, en schrijf de rest zelf. Toen we dit voorjaar de aanmaningen-agent bouwden voor een Rotterdamse groothandel, was de aanmaningslogica zelf door een agent geschreven en in één middag gereviewd. De grootboek-reconciliatie die beslist welke facturen daadwerkelijk te laat zijn, is door een mens geschreven, omdat die beslissing geld verplaatst. Wil je zien hoe we die grens in klantwerk trekken, lees dan onze pagina over AI-agents.

Een bruikbare audit van vijf minuten voor je eigen codebase: open het bestand dat geld verwerkt, het bestand dat migraties doet, en het bestand dat scheduling regelt. Vraag jezelf af of je een agent vanavond elk van die bestanden onbegeleid zou laten herschrijven, tegen productie. De bestanden waar het antwoord nee is, zijn de bestanden die je in 2027 nog steeds zelf schrijft.