Een developer genaamd Andrew Vos publiceerde onlangs een plugin genaamd Endless Toil. Het draait naast je coding-agent in real time, scant de code die verwerkt wordt en speelt escalerende menselijke kreunen af op basis van hoe vervloekt het eruitziet. Een mild zootje levert een zacht gekreun op. Een ware gruwel krijgt het volle gejammer. Op het diepste niveau, gelabeld "abyss," produceren je speakers iets tussen existentiële wanhoop en een man die in het donker op een Lego trapt.
Hacker News was enthousiast. Natuurlijk. Het is grappig. Het is herkenbaar. Elke developer heeft weleens een bestand geopend en precies dat geluid gemaakt.
Maar hier is wat niemand leek te vragen: waarom kreunt die agent eigenlijk?
De charme van het tastbaar maken
Alle eer aan Vos. Endless Toil werkt omdat het iets onzichtbaars fysiek maakt. Codekwaliteitsmetrieken zijn abstract. Cyclomatische complexiteitsscores laten je niks voelen. Maar een opgenomen menselijk gekreun getriggerd door een functie van 400 regels met zes levels nesting? Dat landt anders.
We staren al decennia naar rode kronkellijntjes en gele waarschuwingsdriehoekjes. Soms moet het signaal je prefrontale cortex omzeilen en ergens primaler binnenkomen.
De per ongeluk nuttige metriek
Haal de humor weg en wat je overhoudt is een tool die meet hoe moeilijk een AI-agent het heeft met je code.
Dat is geen grapmetriek. Dat is een oprecht nuttig signaal.
Als je agent moeite heeft om door je codebase te navigeren, als hij context verliest, verkeerde suggesties produceert, of drie pogingen nodig heeft voor een wijziging die triviaal zou moeten zijn, dan vertelt dat je iets echts over je architectuur. Niet over de beperkingen van de agent. Over de dichtheid, koppeling en begrijpelijkheid van wat je gebouwd hebt.
Agent-frictie is codekwaliteitsfeedback. Het gekreun is de metriek.
De grote verschuiving
Dit doet er meer toe dan het klinkt. We leven midden in wat Sonars 2026 developer survey "the great toil shift" noemt. De cijfers zijn ontnuchterend:
- 88% van de developers meldt dat AI minstens één negatief effect heeft op technische schuld
- 53% zegt dat AI code genereert die er correct uitziet maar verborgen defecten introduceert
- 96% vertrouwt AI-output niet volledig, maar slechts 48% verifieert het daadwerkelijk
We hebben het vervelende werk niet geëlimineerd. We hebben het verplaatst. Minder frequente AI-gebruikers worstelen met het debuggen van slecht gedocumenteerde code en het begrijpen van legacy systemen. De meest frequente AI-gebruikers? Hun gezwoeg is verschoven naar het beheren van technische schuld en het corrigeren van code die AI genereerde.
De developers die het zwaarst op AI leunen, besteden hun tijd aan opruimen.
De productiviteitsparadox is echt: developers rapporteren een persoonlijke productiviteitsboost van 35% terwijl ze tegelijkertijd code genereren die meer verificatie, meer onderhoud en meer cognitieve overhead vereist om te begrijpen.
Begripschuld
Addy Osmani gaf dit probleem eerder dit jaar een naam: comprehension debt. Het is de groeiende kloof tussen hoeveel code er in je systeem bestaat en hoeveel daarvan enig mens daadwerkelijk begrijpt.
Traditionele technische schuld is code die je bewust slecht schreef. Begripschuld is code die niemand volledig begrijpt, omdat het sneller gegenereerd werd dan iemand kon internaliseren. Ik schreef hier eerder over als de lavalaag: code die snel stroomt en er indrukwekkend uitziet, maar stolt tot rots waar niemand meer aan durft te komen.
Een studie van Anthropic uit januari 2026 plakte er een getal op: developers die AI-assistentie gebruikten scoorden 17% lager op begripsvragen over de code die ze zojuist geschreven hadden. Ze voltooiden de taak in ongeveer dezelfde tijd. Ze produceerden werkende code. Maar ze begrepen minder van wat ze gebouwd hadden. De steilste daling zat in debugvaardigheid. Precies de vaardigheid die je nodig hebt als dingen om 3 uur 's nachts misgaan.
Je agent kreunt niet alleen bij je legacy code. Hij kreunt bij de code die hij vorige week hielp schrijven en die niemand fatsoenlijk reviewde. De briljante papegaai weet niet meer wat hij gisteren zei, maar moet het vandaag wel teruglezen.
Het verificatievacuüm
Hier is het ongemakkelijke patroon:
- Agents genereren code sneller dan mensen het kunnen reviewen
- Mensen vertrouwen de output omdat het er correct uitziet
- De resulterende codebase wordt moeilijker te navigeren voor zowel mensen als agents
- Waardoor agents minder effectief worden, waardoor developers er nog harder op leunen
Het is een feedbackloop en hij trekt steeds strakker aan. De 96%-vertrouwt-niet-maar-slechts-48%-verifieert-kloof uit Sonars data is geen curiositeit. Het is een structureel falen in hoe teams AI-tooling adopteren. We hebben een verificatievacuüm gecreëerd waar gegenereerde code de codebase binnenkomt zonder betekenisvolle controle, om zich vervolgens op te stapelen tot het soort bende waar agents bij kreunen.
Wat je er daadwerkelijk aan doet
Als je één ding meeneemt van Endless Toil naast een lach, laat het dit zijn: behandel agent-frictie als signaal.
- Als je agent worstelt, refactor eerst. Voordat je een AI vraagt features toe te voegen aan een module die hij nauwelijks kan parsen, vereenvoudig de module. De verwarring van de agent laat je zien waar je abstracties lekken.
- Monitor code turnover rate. Volg hoeveel AI-gegenereerde code binnen 30 dagen wordt teruggedraaid of herschreven. Gezonde teams blijven onder de 15%. Als je daarboven zit, ship je niet. Je draait rondjes.
- Dicht de verificatiekloof. Als je geen tijd hebt om AI-output fatsoenlijk te reviewen, heb je geen tijd om AI te gebruiken. Ongereviewed code is geen snelheid. Het zijn toekomstige debugsessies vermomd als productiviteit.
- Maak het onzichtbare zichtbaar. Of het nu de kreunen van Endless Toil zijn, complexiteitsdashboards, of turnover-metrics: vind een manier om de kosten van AI-gegenereerde complexiteit voelbaar te maken, niet alleen meetbaar.
De clou
De grappigste tools vertellen soms de hardste waarheden. Endless Toil landde als grap, maar het inzicht eronder is bloedserieus: het lijden van je agent is een spiegel.
Hij kreunt niet omdat hij zwak is. Hij kreunt omdat je codebase hem iets vertelt dat je IDE, je CI-pipeline en je sprintmetrics allemaal te beleefd waren om hardop te zeggen.
Misschien wordt het tijd om te luisteren.