Gepubliceerd op 26 augustus 2026 · Bijgewerkt op 3 september 2026 · 34 min leestijd

Hoe AI-bedrijven het moeilijker maken om te stoppen met werken

Een tijdlang probeerde ik verstandig om te gaan met mijn Codex-tegoed. Ik had een wekelijkse limiet en behandelde die daarom als een budget. Als de volgende reset nog zeven dagen op zich liet wachten, kon ik ongeveer 14,3% per dag gebruiken. Na twee dagen zou ik ongeveer 28,6% moeten hebben verbruikt. Gebruikte ik veel meer, dan kon mijn tegoed voor het einde van de week opraken. Gebruikte ik minder, dan hield ik later ruimte over voor een groter project.

Toen begon OpenAI de limieten voortijdig te resetten. Soms kondigde Thibault Sottiaux, die bij OpenAI aan Codex en ChatGPT werkt, een reset aan op X. Soms opende ik Codex en bleek het zonder enige waarschuwing te zijn gebeurd. Mijn resterende tegoed stond weer op 100% en het aftellen van zeven dagen was opnieuw begonnen. Eerst leek dat een cadeau. Meer gebruik voor hetzelfde abonnement. Maar de reset wiste ook uit wat ik had bewaard. Als hij na twee dagen kwam en ik pas 10% had gebruikt, had ik binnen mijn oorspronkelijke dagbudget nog 18,6 procentpunt kunnen besteden. Iemand die het grootste deel van het tegoed al had opgebruikt, kreeg net als ik opnieuw 100%. Die persoon had meer uit de vorige periode gehaald door eerder te verbruiken. Bewaren was de riskante strategie geworden.

Ik stopte met het bewaren van mijn tegoed voor werk dat ik misschien later in de week wilde doen. Ik begon het zo snel mogelijk te gebruiken, omdat er ieder moment weer een reset kon komen. Na een reset werd die druk nog sterker. Ook dit nieuwe tegoed kon verdwijnen. Er waren dagen waarop ik mijn hele weeklimiet op één dag opmaakte, deels omdat ik hoopte dat OpenAI hem de volgende ochtend opnieuw zou resetten. Niemand droeg me op dat te doen. Codex knipperde niet als een gokautomaat en beloofde geen jackpot. OpenAI gaf me extra capaciteit, vaak na een storing of om een nieuwe versie of mijlpaal in het gebruik te vieren. Toch veranderde het patroon mijn gedrag. Een onvoorspelbare beloning leerde me dat terughoudendheid waarde op tafel kon laten liggen, terwijl onmiddellijk verbruik me beschermde tegen het mislopen van de volgende reset.

Het vreemdste was dat ik dit gedrag altijd productief kon laten klinken. Ik verspilde geen tokens. Ik testte een model, verbeterde een project, leerde een nieuwe werkwijze of hield een technologie bij die mijn beroep misschien ingrijpend zou veranderen. Zodra een project geen nieuwe prompt meer rechtvaardigde, kon ik aan een ander beginnen. Er was altijd wel iets nuttigs dat ik de agent kon laten doen. De resultaten waren onzeker genoeg om de lus gaande te houden. Een prompt kon een uitstekende oplossing opleveren, een overtuigende puinhoop of iets dat zo dichtbij kwam dat één correctie het vast zou afmaken. Een mislukte poging gaf geen uitsluitsel, omdat de volgende anders kon uitpakken. Een onafgemaakte taak gaf me een reden om door te gaan en ongebruikt tegoed gaf me een reden om een nieuwe taak te verzinnen.

Hier beginnen codeeragents te lijken op systemen die we al kennen uit gokken, gamificatie en het ontwerp waarmee sociale media betrokkenheid stimuleren. De vergelijking houdt niet in dat een prompt letterlijk een weddenschap is, dat software schrijven hetzelfde is als achter een gokautomaat zitten of dat het gebruik van een agent neerkomt op een klinische verslaving. Het gaat om de structuur rond de activiteit: onzekere beloningen, ondoorzichtige kosten, vervallende budgetten, onverwachte resets, bijna voltooid werk, status, het ontbreken van een natuurlijk eindpunt en de aanhoudende suggestie dat nog één poging redelijk is. Bij programmeren is die structuur moeilijker te herkennen, omdat de mogelijke beloning echt werk is. Een late avond kan een functionaliteit of een hulpmiddel opleveren dat ik oprecht wilde maken. Productiviteit geeft het gedrag een moreel excuus. Iemand kan slaap en vrije tijd inruilen voor nog een poging en ondertussen geloven dat de software tijd bespaart. Ik wil begrijpen wat er gebeurt wanneer een hulpmiddel dat belooft ons tijd terug te geven wordt gebouwd en verkocht via systemen die het redelijk laten voelen om die tijd te verbruiken.

Een budget dat niet te begroten valt

Mijn poging om het weektegoed in zeven gelijke delen op te delen ging ervan uit dat het percentage iets stabiels vertegenwoordigde. Dat deed het niet. Zelfs zonder de onverwachte resets kon het getal op het dashboard me niet vertellen hoeveel werk ik nog kon verzetten.

OpenAI legt uit dat het verbruik van Codex afhangt van het model, de omvang en complexiteit van de taak, of het werk lokaal of in de cloud wordt uitgevoerd, de hoeveelheid context, redeneerwerk, het gebruik van hulpmiddelen, het ophalen van informatie en caching. Twee taken die op elkaar lijken, kunnen verschillende hoeveelheden verbruiken. Alleen de lengte van de prompt biedt geen betrouwbare schatting. Het bedrijf publiceert ruime bandbreedtes voor lokale berichten binnen een venster van vijf uur, maar die verschillen aanzienlijk per model. Lokale berichten en cloudgesprekken delen dat venster bij Plus en Business, en er kunnen aanvullende weeklimieten gelden. De documentatie raadt gebruikers zelfs aan regelmatig het gebruiksdashboard te bekijken om inzicht te krijgen in hun verbruikstempo. (OpenAI, “Codex pricing”)

Anthropic omschrijft zijn limiet als een “gespreksbudget”. Het verbruik van Claude hangt af van de lengte en complexiteit van een gesprek, het gekozen model, de gebruikte functies en de instelling voor denkinspanning. Claude, Claude Code en Claude Desktop putten uit hetzelfde tegoed. Bij het Pro-abonnement wordt de sessielimiet iedere vijf uur gereset en wordt een afzonderlijke weeklimiet gereset op een vast tijdstip dat aan het account is toegewezen. Anthropic kan ook andere limieten toepassen op bepaalde modellen, functies of periodes. (Anthropic, “How do usage and length limits work?”) & (Anthropic, “What is the Pro plan?”)

Deze limieten kunnen een redelijke manier zijn om infrastructuur te verdelen die schaars en duur is om te verkrijgen en te onderhouden. Mijn bezwaar is niet dat er een limiet bestaat. Mijn bezwaar is dat het abonnement de gebruiker verantwoordelijk maakt voor het rantsoeneren van iets waarvan de praktische waarde vooraf niet bekend kan zijn. Een percentage oogt precies. Dertig procent resterend lijkt een feit, maar het is geen dertig procent van een project, dertig procent van een werkdag of dertig procent van een bekend aantal bruikbare antwoorden. Het kan genoeg zijn voor meerdere eenvoudige oplossingen. Het kan verdwijnen in één moeilijke taak met een grote codebase, een lang gesprek en herhaald gebruik van hulpmiddelen. Het dashboard meet het verbruik achteraf, terwijl ik vooraf moet beslissen of een taak dat verbruik waard is.

Wachten kan die afweging nog nadeliger maken. Wanneer ik na een pauze terugkeer naar een gesprek in Claude Code, duurt een antwoord in mijn ervaring soms langer en springt het verbruik veel sterker omhoog dan wanneer ik snel verderga. Mijn hypothese is dat het gesprek, of een deel van de context, uit de promptcache is verdwenen. Het model moet die invoertokens dan opnieuw tegen het volledige tarief verwerken in plaats van het tarief voor gecachte invoer. Het dashboard toont me niet genoeg om vast te stellen of caching de stijging veroorzaakt. Wat ik wel kan waarnemen, is dat een pauze hetzelfde gesprek duurder kan maken om te hervatten. Het abonnement legt feitelijk een boete op pauzeren. Een onderbreking wordt belast, terwijl zonder stoppen doordenderen de goedkopere context bewaart.

Dat wordt bijzonder nadelig op de grens tussen twee vensters van vijf uur. Als mijn tegoed halverwege een taak opraakt, kan ik na de reset niet simpelweg verdergaan met het volledige nieuwe tegoed beschikbaar voor nieuw werk. De agent moet eerst het bestaande gesprek, de code en de geschiedenis van gebruikte hulpmiddelen opnieuw in de context laden. Ik heb gezien dat zo’n eerste verzoek meerdere procentpunten verbruikt en het nieuwe venster vaak vrijwel onmiddellijk naar een verbruik met dubbele cijfers duwt. Als mijn hypothese klopt, gaat een deel van het verse tegoed op aan het reconstrueren van werk waarvoor ik in het vorige venster al had betaald. De limiet geeft me daarmee nog een reden om door te gaan zolang de context warm is, zelfs wanneer stoppen beter zou zijn.

Zo krijgt de gebruiker naast programmeren een tweede baan. Ik moet beslissen welk model een taak verdient, of ik de context moet inkorten, of een verzoek belangrijk genoeg is voor de resterende weekcapaciteit en of een kleiner model meer van het tegoed kan sparen. Ik houd klokken van vijf uur en een week in de gaten terwijl ik ook het softwareprobleem zelf in mijn hoofd probeer te houden. Ik beheer niet langer alleen code. Ik beheer een speelpot aan rekenkracht. Het woord speelpot maakt een prompt juridisch of klinisch nog geen weddenschap. De vergelijking beschrijft hoe het begroten voelt. Ik zet een onzekere hoeveelheid van een beperkte grondstof in voordat ik de kwaliteit ken van wat ik ervoor terugkrijg. Het resultaat kan uren besparen, meer werk veroorzaken dan het wegneemt of zo dichtbij komen dat opgeven als verspilling voelt. Anders dan bij een normale aankoop kan ik vóór mijn beslissing geen duidelijke prijs met een afgebakend product vergelijken.

De limieten delen de tijd ook op manieren in die weinig met het werk zelf te maken hebben. Softwaretaken passen van nature niet in vensters van vijf uur. Een wekelijkse reset weet niet wanneer ik tijd heb voor een eigen project, wanneer ik moet slapen of wanneer de huidige taak een veilig stoppunt heeft bereikt. De klok behoort bij het abonnement in plaats van bij het project, maar ik moet mijn werk eromheen organiseren. De onverwachte resets maakten dit zichtbaar. Ik had een plan gebouwd rond een tegoed waarover ik geen zeggenschap had. Als ik alleen naar de nieuwe 100% keek, pakte het mislukken van dat plan gunstig uit. Toch leerde het me dat zorgvuldig bewaren bestraft kon worden. Diezelfde onzekerheid blijft bij normaal gebruik bestaan. Ik zie welk percentage over is, maar kan het niet vertalen naar nuttig werk. Zelfs een volmaakt voorspelbare meter vertelt me niet of de volgende prompt het probleem oplost of iets achterlaat dat bijna goed is. Door die onzekerheid valt nog één poging zo gemakkelijk te verdedigen.

Waarom nog één prompt redelijk blijft

Stel dat ik een agent vraag een functionaliteit toe te voegen. Hij leest de repository, maakt een plan en wijzigt een dozijn bestanden. De implementatie ziet er aannemelijk uit. Meerdere tests slagen, maar één mislukt. Als ik nu stop, blijf ik zitten met code die ik niet kan gebruiken, terwijl een nieuwe prompt alleen de mislukte test en misschien een korte correctie nodig heeft. De agent lost hem op, maar de volledige testsuite onthult ergens anders een regressie. Ook die lijkt klein. Iedere poging verplaatst het probleem zonder het helemaal op te lossen en geeft me een volkomen zinnige reden voor nog een poging.

Softwareontwikkeling is altijd onzeker geweest. Misschien weet je de precieze oplossing nog niet, maar ervaring geeft een ontwikkelaar meestal enig idee van wat ervoor nodig is. Ik kan een mislukte test onderzoeken, de betreffende code volgen en inschatten of de reparatie één aangepaste voorwaarde of een groter herontwerp vereist. Die inschatting kan fout zijn, maar ze rust op werk dat ik kan zien en een proces dat ik begrijp. Zodra ik de volgende stap aan een agent overdraag, verlies ik een groot deel van die basis voor mijn oordeel. Voordat het antwoord binnenkomt, weet ik niet of de agent het probleem volledig oplost, alleen het zichtbare symptoom verhelpt, een regressie veroorzaakt, meer herschrijft dan nodig is of andere verbeteringen ontdekt die opeens de moeite waard lijken. Ik kan het resterende werk niet inschatten, omdat de volgende prompt kan veranderen wat het resterende werk überhaupt is.

De niet-deterministische werking van het model draagt bij aan deze onzekerheid, maar een andere uitkomst bij een identiek verzoek is niet het hoofdprobleem. De gebruiker kan vóór het genereren de kwaliteit en volledigheid van het resultaat niet kennen. Eén mislukte poging bepaalt niet wat een volgende of iets aangepaste prompt zal opleveren. Onderzoek naar codegeneratie bevestigt beide kanten hiervan. Herhaalde verzoeken kunnen wezenlijk verschillende code produceren en promptstrategieën die testresultaten terugvoeren kunnen de kans op succes over meerdere pogingen verbeteren. (Ouyang et al., “An empirical study of the non-determinism of ChatGPT in code generation”) (Hou en Ji, “Comparing large language models and human programmers for generating programming code”) Opnieuw proberen is daarom vaak een verstandige technische beslissing. Als de eerste poging een vereiste verkeerd begreep, kan ik die verduidelijken. Als een test een concrete fout blootlegt, kan ik die fout aan de agent geven. Dat lijkt op normaal debuggen. Ik bekijk de fout, geef betere informatie en probeer een aangepaste oplossing. Het verschil is dat ik vóór een handmatige correctie kan inschatten hoeveel werk die kost. Voor de corrigerende prompt kan ik geen vergelijkbare inschatting maken. Hij kan de taak binnen enkele minuten afmaken of een groot deel van het resterende tegoed verbruiken en een andere onafgemaakte toestand achterlaten.

De moeilijkheid is bepalen wanneer die redenering niet langer opgaat. Nadat de agent twaalf bestanden heeft aangepast, kan terugdraaien voelen alsof ik de tijd weggooi die aan genereren en beoordelen is besteed. Negen geslaagde tests laten de functionaliteit dichtbij genoeg lijken om te redden. De overgebleven fout geeft me een concrete volgende instructie, waarop ik veel eenvoudiger kan handelen dan op de bredere vraag of de functionaliteit nog steeds de moeite waard is. Als de volgende correctie iets anders breekt, is mijn investering gegroeid, net als de hoeveelheid werk die een nieuwe prompt belooft terug te winnen.

Onderzoek naar gokken noemt doorspelen om eerdere verliezen terug te winnen “chasing”. Die term is niet rechtstreeks op programmeren over te dragen. Een gokker kan een eerdere verloren weddenschap niet repareren, terwijl een nieuwe prompt kapotte code werkelijk kan herstellen. Bij programmeren kan het verlies bestaan uit tijd, tegoed, aandacht of schade aan de repository in plaats van geld. De overeenkomst zit in de manier waarop het doel van doorgaan kan veranderen. Ik kan beginnen met de vraag of de agent de beste manier is om de functionaliteit af te ronden en eindigen met de poging te bewijzen dat de voorgaande pogingen geen verspilling waren. Onderzoek naar het najagen van verliezen kan ons niet vertellen hoe vaak gebruikers van codeeragents die verschuiving maken. Het geeft ons wel een nuttige vraag om over ons eigen gedrag te stellen. (Auer en Griffiths, “An empirical attempt to operationalize chasing losses in gambling”)

Met prompts heeft de gebruiker ook echte invloed op het resultaat. Ik kan een test toevoegen, de taak beperken, van model wisselen, ontbrekende documentatie geven of uitleggen waarom de vorige aanpak mislukte. Die handelingen werken soms, waardoor deze lus overtuigender is dan een eenvoudig kansspel. Het betekent ook dat ik iedere mislukking kan verklaren als een tekortkoming in mijn werkwijze. Misschien was de prompt onduidelijk, het contextbestand onvolledig of de instelling voor denkinspanning te laag. Iedere diagnose levert weer een aanpassing op om te proberen. Gokonderzoekers gebruiken “illusion of control” voor situaties waarin betrokkenheid en keuze ervoor zorgen dat mensen hun invloed op door toeval bepaalde uitkomsten overschatten. Codeeragents zijn geen kansspelen, want deskundigheid en terugkoppeling doen er aantoonbaar toe. Het relevante risico is dat ik geloof dat een betere instructie de volgende uitkomst voorspelbaar heeft gemaakt, terwijl ze alleen de kansen heeft veranderd. (Clark, “Decision-making during gambling”)

Gedeeltelijke vooruitgang maakt dit moeilijker te herkennen. Een grote diff, een zelfverzekerd voltooiingsbericht en een grotendeels groene testrun bewijzen allemaal dat er iets is gebeurd. Ze laten niet zien of ik na het beoordelen van de code, het repareren van regressies en het controleren van de oorspronkelijke opdracht werkelijk tijd heb bespaard. Activiteit is gemakkelijker zichtbaar dan netto vooruitgang. Zelfs een slechte poging kan genoeg bruikbaar ogend werk achterlaten om opgeven voorbarig te laten voelen. Er bestaat geen universeel aantal mislukte prompts waarna volhouden onredelijk wordt. Moeilijke software heeft altijd iteratie vereist en nooit opnieuw proberen zou veel tenietdoen van wat deze hulpmiddelen bruikbaar maakt. Het probleem is dat ik moet beslissen of ik doorga voordat ik weet wat een nieuwe poging kost of hoeveel werk die wegneemt. De agent biedt geen natuurlijke scheidslijn tussen het debuggen van de functionaliteit en het debuggen van de agent. Hij veroorzaakt het onafgemaakte werk, legt uit waarom het bijna klaar is en biedt de volgende handeling aan die het misschien afmaakt. Zolang een andere uitkomst mogelijk blijft, kan stoppen altijd als de minder redelijke keuze worden voorgesteld.

Een eindeloze voorraad nuttig werk

De lus eindigt niet wanneer ik eindelijk een taak afrond. Codeeragents veranderen ook aan welke taken ik bereid ben te beginnen. Voordat ik ze gebruikte, moest een klein eigen idee opwegen tegen het vooruitzicht dat ik een avond kwijt was aan het opzetten van een repository, het kiezen van afhankelijkheden, het bouwen van de eerste interface en het schrijven van genoeg code om te ontdekken of het idee goed was. Die inspanning werkte als filter. Veel ideeën waren interessant, maar niet interessant genoeg om de uren op te eisen die nodig waren om ze werkelijkheid te maken. Een agent verzwakt dat filter. Ik kan een idee beschrijven en een repository, een ruwe interface en een werkende eerste versie ontvangen voordat ik heb besloten hoeveel het project voor me betekent. Dat is een van de waardevolste eigenschappen van codeeragents. Mensen kunnen er ideeën mee testen die anders buiten hun bereik zouden blijven. Het verandert ook de beslissing waarvoor ik sta. Ik beslis niet langer of een idee het verdient om eraan te beginnen. Ik kijk naar iets dat bestaat, werkt en dichtbij genoeg lijkt om te verbeteren.

Onderzoek naar het nastreven van doelen noemt zo’n voorsprong “endowed progress”, meegegeven vooruitgang. In een reeks onderzoeken vergrootte vooruitgang die voortkwam uit de situatie in plaats van uit de eigen inspanning de toewijding van mensen die nog aan het begin van een doel stonden, omdat de voorsprong voltooiing haalbaarder liet lijken. Een gegenereerd prototype is geen klantenkaart en ook geen van de andere doelen uit dat onderzoek. We hebben nog geen bewijs dat ontwikkelaars er op dezelfde manier op reageren. De vergelijking wijst wel op een belangrijke verandering. De agent kan genoeg vroege vooruitgang leveren om “ik zou dit kunnen bouwen” te veranderen in “ik moet dit afmaken”. (Zhang en Huang, “How endowed versus earned progress affects consumer goal commitment and motivation”)

Een prototype brengt vervolgens zijn eigen werk voort. De gegenereerde applicatie heeft tests, toegankelijkheidscontroles, een implementatieomgeving, documentatie en beslissingen nodig over alle functies die pas zichtbaar werden toen ik haar kon gebruiken. Een deel van dat werk kan veeleisender zijn dan het maken van de eerste versie. De agent heeft me de inspanning bespaard om het prototype te bereiken, maar me ook voorbij het punt gebracht waarop het kosteloos voelt om het idee te laten vallen. Een repository verwijderen die al gedeeltelijk werkt, voelt anders dan de editor nooit openen.

Onafgemaakt werk blijft niet noodzakelijk bij de computer. Een meta-analyse uit 2026 vond een verband tussen onafgemaakte werktaken en meer gedachten aan het werk in de vrije tijd, vooral affectief piekeren. Een eerder dagboekonderzoek koppelde onafgemaakte taken op vrijdag via piekeren aan slechtere slaap in het weekend. Geen van beide onderzoeken ging over codeeragents of over de vraag of die meer onafgemaakt werk creëren. Ze helpen wel verklaren waarom mislukte tests, openstaande beoordelingen en halfgebouwde functionaliteiten die agents achterlaten mentaal actief kunnen blijven nadat de laptop dichtgaat. (Wendsche, Weigelt en Syrek, “Unfinished work tasks and work-related thoughts during off-job time”) (Syrek et al., “Zeigarnik’s sleepless nights”)

Meerdere agents parallel laten draaien vermenigvuldigt dit probleem. De ene machine kan een fout onderzoeken terwijl een andere een functionaliteit schrijft en een derde tests bijwerkt. Ik moet nog steeds begrijpen wat iedere agent heeft veranderd, beoordelen of de aannames klopten en beslissen wat er daarna gebeurt. De agents kunnen sneller werk veroorzaken dan ik het kan beoordelen. Typen is niet langer het knelpunt. Mijn aandacht is dat wel, en ieder bespaard implementatie-uur kan terugkomen als meerdere concurrerende verzoeken om mijn oordeel.

De agent kan zelfs in een verder afgerond gesprek het volgende werkpunt veroorzaken. Ik merk dit bij het Opus 5-model van Anthropic, dat de gewoonte heeft ontwikkeld om antwoorden af te sluiten met een zin als “One thing worth flagging”. De gevraagde taak kan klaar zijn, maar vlak voordat ik kan vertrekken introduceert het model een nieuw aandachtspunt. In mijn ervaring staan die opmerkingen meestal los van mijn vraag of zijn ze niet nuttig genoeg om iets mee te doen. Toch moet ik ze lezen en beoordelen, omdat het aanvullende punt soms wel belangrijk kan zijn. Misschien wijst het op een regressie, een beveiligingsprobleem of een verkeerde aanname. Die mogelijkheid verandert een onbelangrijke terzijde in onafgemaakt werk. Het negeren kan onzorgvuldig voelen, terwijl een vervolgvraag het gesprek en de gebruiksmeter gaande houdt. In hetzelfde antwoord heeft het model mijn vraag beantwoord en de reden voor mijn volgende vraag geleverd.

Dit lijkt meer op een eindeloze tijdlijn dan op een conventioneel hulpmiddel. Een tijdlijn op sociale media bereikt geen laatste bericht om de gebruiker vervolgens te vertellen dat het klaar is. Er verschijnt steeds een volgend bericht en de gebruiker moet zelf kiezen wanneer een onafgemaakte stroom genoeg is geweest. Codeeragents kunnen hetzelfde stopsignaal wegnemen, maar het volgende punt presenteert zich als mogelijk nuttig werk in plaats van vermaak. Een model kan altijd nog een test voorstellen, een aangrenzend probleem aanwijzen, een refactor aanbieden of vragen of het verder moet gaan. Zulke voorstellen zijn niet automatisch manipulatief. Soms merkt de agent iets belangrijks op en juist die incidentele waarde maakt zijn suggesties moeilijk te negeren. Een consequent nutteloze toegift zou snel onzichtbaar worden. Een toegift die af en toe nuttig is, leert me de volgende ook te onderzoeken.

Zo kan een hulpmiddel tijd besparen zonder me meer vrije tijd te geven. Het verlagen van de kosten van één taak maakt ruimte voor een andere waaraan ik eerder niet zou zijn begonnen. Een afgeronde functionaliteit onthult een verbetering en het antwoord dat de voltooiing meldt kan er nog een aanwijzen. Er is altijd nuttig werk beschikbaar, omdat de agent zowel het resultaat als het werk eromheen helpt produceren. De capaciteitswinst is echt, maar dat geldt ook voor de uitbreiding van wat ik nu denk aan te kunnen. Zodra dit de normale werkwijze wordt, begint de grotere werkvoorraad te lijken op capaciteit die gebruikt hoort te worden. AI-bedrijven en de cultuur rond hun producten leren gebruikers ook hoe bekwaam en ambitieus gebruik eruit hoort te zien.

De serieuze gebruiker vertraagt nooit

Ik hoorde “not gonna make it”, meestal afgekort tot NGMI, al lang voordat mensen de uitdrukking op softwareontwikkeling gingen toepassen. De uitdrukking liet risico nemen op inzicht lijken en voorzichtigheid op een persoonlijk gebrek. Als de beloofde toekomst zonder jou aanbrak, impliceerde de leus dat je overtuiging miste en verdiende achter te blijven. Ik herken diezelfde beweging nu in gesprekken over door AI gedreven werkwijzen. Uitstappen of bewust voor een rustiger tempo kiezen geldt niet langer als een persoonlijke voorkeur. Het wordt behandeld als professionele veroudering.

AI-bedrijven hoeven de uitdrukking zelf niet te gebruiken. Ze leveren de voorbeelden waaruit de cultuur haar opbouwt. Anthropic omschrijft Claude Code binnen zijn productontwikkelingsteam als de “first stop” voor iedere programmeertaak, toont ontwerpers die autonome lussen opzetten waarin voortdurend code wordt geschreven en getest, en viert mensen buiten de softwareontwikkeling die applicaties en interne hulpmiddelen bouwen. Toen het bedrijf in mei 2026 de vijf-uurslimieten van Claude Code verdubbelde, zei het dat de veranderingen bedoeld waren voor zijn “most dedicated customers”. (Anthropic, “How Anthropic teams use Claude Code”) (Anthropic, “Higher usage limits for Claude”) Dit zijn echte mogelijkheden en vaak nuttige werkwijzen. Ze geven intensief gebruik ook een flatterende identiteit. De serieuze gebruiker laat meer agents draaien, delegeert meer soorten werk en zet een groter deel van de dag om in productie. Sociale media veranderen dat beeld in advies om een power user te worden en in waarschuwingen dat iedereen die zijn werk niet rond agents organiseert achteropraakt. Sommigen maken het NGMI-argument expliciet en voorspellen dat softwareontwikkelaars die geen codeerassistenten gebruiken het onderspit zullen delven wanneer ontwikkelaars met LLM-ondersteuning de prestatieverwachtingen binnen bedrijven veranderen.

Ik denk niet dat die waarschuwing volledig onjuist is. Een LLM loopt niet een sollicitatiegesprek binnen om mijn baan over te nemen, maar iemand die er een gebruikt concurreert al met mij. Die persoon kan een opdracht sneller afronden, minder vragen, meer projecten onderhouden of productiever lijken doordat er veel meer zichtbaar werk kan worden gegenereerd. Ik gebruik deze hulpmiddelen deels omdat ik ze leuk vind en deels omdat ze negeren een professioneel risico zou zijn. Wat ik verwerp, is de conclusie dat ik deze druk zelf moet oplossen door onbeperkte persoonlijke adoptie. De bedrijven achter codeeragents leveren meer dan een neutrale machine. Zij kiezen de abonnementsperiodes, gebruiksmeters, meldingen en standaardinstellingen waarmee ik het product ervaar. Ze publiceren voorbeelden van autonome lussen en parallelle agents, vieren hun intensiefste gebruikers en presenteren bredere adoptie als de richting waarin professionele softwareontwikkeling zich beweegt. Het product en het verhaal eromheen wijzen dezelfde kant op. Een bekwame gebruiker houdt meer agents aan het werk en vindt meer werk om ze te geven.

Daarvoor is geen geheim plan nodig om me betrokken te houden. Een systeem kan gedrag belonen zonder dat de ontwerpers precies dat effect hebben nagestreefd. Ik kan waarnemen dat bewaard tegoed zijn waarde verliest, de prijs van een volgende prompt moeilijk is in te schatten, onafgemaakt werk me bij mijn bureau vandaan volgt en intensief gebruik professionele status krijgt. Die effecten horen bij de beoordeling van het product zoals het bestaat. De providers kunnen ze onderzoeken, het ontwerp aanpassen en besluiten welk gedrag ze eenvoudiger willen maken. Zulke effecten zullen waarschijnlijk als eerste zichtbaar worden bij vroege gebruikers, omdat zij de producten intensiever gebruiken en een groter deel van hun werk eromheen organiseren. Als het probleem nooit buiten die groep komt doordat hun feedback tot een beter product leidt, is dat een succes en geen bewijs dat de waarschuwing misplaatst was.

Die wetenschap neemt de druk niet weg. Ik kan nog steeds een avond besteden aan het testen van een nieuw model, het verbeteren van instructies voor agents of het leren begeleiden van meerdere taken tegelijk en dat professionele zelfverdediging noemen. Het werk kan me werkelijk beter maken in mijn vak en juist daardoor is de grens zo moeilijk te trekken. NGMI levert de sociale druk, de agent levert onzekere maar soms opmerkelijke resultaten en het abonnement levert een tegoed dat zijn waarde verliest als ik het niet gebruik. Samen veranderen ze een structureel probleem in een persoonlijke routine van bijblijven. Een agent gebruiken en zijn limieten volledig opgebruiken zijn duidelijk verschillende keuzes, maar ze beginnen te voelen als punten op dezelfde schaal van toewijding. Wanneer ik een limiet bereik, kan stoppen meer kosten dan alleen een onafgemaakte taak. Het kan voelen alsof ik ervoor kies achterop te raken.

De limiet verandert alleen het werk

Op mijn werk wissel ik voortdurend tussen Claude Code en Codex. Niet omdat ik ieder model zorgvuldig heb gekoppeld aan het soort taak waarin het uitblinkt, maar omdat beide limieten hebben en ik de ene alvast wil gebruiken voordat de andere opraakt. Als ik een te groot deel van de ochtend met Claude Code werk, kan ik zijn limiet bereiken terwijl mijn Codex-tegoed onaangeroerd blijft. Gebruik ik Codex te intensief, dan bewaar ik Claude-capaciteit die misschien verloopt zonder iets op te leveren. Ik verdeel mijn werk om beide abonnementen productief te houden en niet afhankelijk te worden van één klok. De keuze voor een hulpmiddel is daardoor niet langer alleen een technische beslissing. Het is ook het verdelen van twee voorraden vervallende rekenkracht. Die berekening volgt me door de dag. Ik kijk naar de resterende percentages, bedenk welke reset het eerst komt en beslis welke aanbieder ik voor de huidige taak gebruik. Die aandacht gaat niet naar de software. De agents zouden mechanisch werk moeten wegnemen zodat ik me op mijn oordeel kan richten, maar hun limieten voegen een beheerprobleem toe dat niets zegt over de juistheid van de code. Ik ben verantwoordelijk geworden voor het bezighouden van twee machines zonder een van beide op het verkeerde moment onbeschikbaar te laten worden.

Soms oordeel ik verkeerd of let ik simpelweg niet goed genoeg op de meter. Dan bereik ik een limiet terwijl de agent midden in een taak zit. Hij heeft meerdere bestanden aangepast of een plan half uitgevoerd achtergelaten. Zelf verdergaan is niet zo eenvoudig als het laatst gewijzigde bestand openen. Ik moet begrijpen wat de agent van plan was, inspecteren wat er is veranderd en bepalen of de half afgeronde aanpak nog steeds klopt. Onderzoek naar onderbroken programmeerwerk beschrijft een deel van die herstelinspanning. In een verkennend onderzoek naar 10.000 programmeersessies navigeerden ontwikkelaars door de code en zochten ze andere context over hun taak voordat ze weer begonnen met bewerken. Slechts tien procent van de geobserveerde sessies keerde binnen een minuut terug naar het schrijven van code. (Parnin en Rugaber, “Resumption strategies for interrupted programming tasks”) Het onderzoek bekeek ontwikkelaars die hun eigen onderbroken werk hervatten, niet mensen die het van een agent overnamen. Het kan de belasting van die overdracht niet meten. Het toont wel dat het herbouwen van taakcontext tijd kost, zelfs wanneer de ontwikkelaar het oorspronkelijke werk zelf heeft gedaan.

Vaak kies ik ervoor die prijs niet te betalen. In plaats daarvan stap ik over op werk dat bij de onderbreking past. Ik beoordeel code die een agent al heeft voltooid, test een functionaliteit, bekijk een ander project of formuleer feedback die ik de agent kan geven zodra het tegoed opnieuw beschikbaar is. Ik blijf bezig en het werk is nuttig. Daardoor is de verstoring gemakkelijk weg te wuiven, maar ik bepaal de volgorde van het werk niet langer op basis van wat het project nodig heeft of waar mijn aandacht het scherpst is. Het resetschema heeft besloten dat de implementatie nu pauzeert en de review begint. Wanneer de capaciteit terugkeert, moet ik weer terugschakelen, de taak opnieuw inladen en verdergaan vanaf het punt waar de machine stopte. De limiet heeft me geen pauze gegeven. Ze heeft mijn werk herordend.

Handmatig doorgaan begint ook vreemd genoeg als verspilling te voelen. Waarom zou ik zelf code schrijven wanneer de toverdoos dat na de reset kan doen? Weggooien wat de agent heeft gemaakt voelt erger, omdat ik er al tegoed aan heb besteed. Als ik had geweten dat de taak hier zou stoppen, zo houd ik mezelf voor, had ik die tokens aan iets anders besteed. Dit is een andere variant van het probleem van verliezen najagen. De eerdere uitgave laat het behouden van de huidige poging belangrijker voelen dan opnieuw bepalen hoe de taak moet worden voltooid. Het verschil met gokken blijft belangrijk, omdat gegenereerde code werkelijke waarde kan hebben. Juist die waarde zorgt ervoor dat wachten op de agent, van aanbieder wisselen of de rest van de dag herinrichten redelijk lijkt. Een gebruikslimiet zou een pauze kunnen creëren waarin ik heroverweeg of ik wil doorwerken. In de praktijk houdt ze de lus gaande, maar niet op mijn voorwaarden. Ik kan de taak verplaatsen, naar een andere taak gaan of werk voorbereiden voor het moment waarop het tegoed terugkeert. Elke keuze is productief genoeg om te verdedigen, terwijl geen ervan de controle over de dag aan mij teruggeeft. Het venster van vijf uur hoeft me geen extra tegoeden te verkopen om mijn gedrag te beïnvloeden. Het heeft al bepaald wanneer één soort werk stopt, wanneer een ander begint en wanneer de onafgemaakte taak weer beschikbaar is.

Productieve dwang heeft geen waarschuwingslabel

Voordat ik mijn bureau verlaat, controleer ik vaak of iedere agent draait en iets te doen heeft. Een stilstaande machine voelt als verspilde tijd waarin vooruitgang geboekt had kunnen worden. Die gewoonte klinkt efficiënt, omdat ze dat soms ook is. Ik kan terugkomen bij afgerond onderzoek, een voorgestelde oplossing of tests die zonder mij zijn uitgevoerd. Maar vertrekken vormt daardoor geen duidelijk einde meer van de werksessie. Voor ik wegga, creëer ik meerdere redenen om terug te keren. Iedere agent kan klaar zijn, mislukken of om een beslissing vragen, en ik weet dat mijn afwezigheid nu verhindert dat hij doorgaat. Een tijdlang had ik zelfs de app op mijn telefoon om agents buiten mijn computer te begeleiden. Ik merkte snel wat dat met mijn aandacht deed en verwijderde hem. De telefoon veranderde ieder moment in een mogelijke “productieve” sessie. Ik kon controleren of een agent klaar was, de uitleg lezen en een volgende prompt sturen zonder bewust te besluiten achter mijn computer te werken. Het verwijderen van de app bracht enige frictie terug, maar nam de aantrekkingskracht niet weg. Ik ben nog steeds naar mijn computer teruggelopen om te kijken hoe het ging en snel een vervolgvraag te sturen. Dat duurt maar een minuut en is daardoor eenvoudig goed te praten. Vervolgens blijft de taak actief in mijn hoofd, is er weer een resultaat onderweg en wordt die minuut een verlenging van de werkdag.

Ik ben ook doorgegaan op momenten waarop ik anders zou zijn gestopt, vooral tijdens de periode met veelvuldige Codex-resets. De mogelijkheid dat er opnieuw tegoed verscheen, liet ongebruikte capaciteit tijdelijk voelen. Ik kon mezelf vertellen dat ik na deze taak zou stoppen, maar het afronden ervan maakte de agent vrij voor een volgende, terwijl een onverwachte reset me kon belonen als ik het vorige tegoed snel had verbruikt. Vanuit de sessie zag niets hiervan eruit als verloren tijd. Ik produceerde software, leerde wat de modellen konden en haalde meer waarde uit een abonnement waarvoor ik al had betaald. Het werk zelf leverde de rechtvaardiging om ermee door te gaan. Daardoor is schadelijk gebruik van agents moeilijk te herkennen. Iemand die herhaaldelijk een gokapp controleert, neemt in de ogen van de maatschappij een risico. Een ontwikkelaar die herhaaldelijk agents controleert, houdt toezicht op werk. Wakker blijven wordt toewijding, meerdere onzekere taken uitvoeren wordt orkestratie en een tegoed opmaken wordt waar voor je geld krijgen. De code kan nuttig zijn, waardoor dit meer is dan een smoes. Nut vertelt me alleen niet of ik nog zou moeten werken, of ik de uitvoer nog zorgvuldig kan beoordelen en wat de sessie heeft verdrongen. Een functionaliteit die om middernacht af is, blijft een afgeronde functionaliteit, zelfs als de prijs slaap, aandacht of tijd met iemand anders was.

Andere ontwikkelaars beschrijven sterkere versies van dezelfde aantrekkingskracht. Armin Ronacher schrijft dat hij, nadat Claude hem had gegrepen, twee maanden buitensporig veel promptte, te weinig sliep en hulpmiddelen bouwde waarvoor hij uiteindelijk weinig nut had. (Armin Ronacher, “Agent psychosis: Are we going insane?”) Steve Yegge beschrijft hoe hij vier of vijf agents tegelijk beheert en moeite heeft zijn laptop voor twee uur ’s nachts dicht te doen. Hij noemt agentisch programmeren “verslavend” en vergelijkt de onvoorspelbare resultaten met de wisselende bekrachtiging van een gokautomaat. (Steve Yegge, “The Brute Squad”) Simon Willison noemt meerdere codeeragents tegelijk gebruiken effectief maar “mentally exhausting”. (Simon Willison, “Vibe engineering”) Addy Osmani beschrijft vijf of tien gelijktijdige sessies die sneller werk produceren dan een ontwikkelaar de bijbehorende mentale modellen kan onderhouden. (Addy Osmani, “Human judgment doesn’t leave the software factory. It relocates.”) Dit zijn persoonlijke ervaringen, geen bewijs voor hoe vaak het gedrag voorkomt. Ze laten zien dat het patroon dat ik ervoer niet alleen van mij is. De kosten van nog een implementatie kunnen sneller dalen dan de kosten om te begrijpen of die überhaupt had moeten bestaan.

Onderzoek naar werktijd geeft ons minder dramatische woorden voor dezelfde schade. Werkintensivering betekent dat meer activiteit in de werkdag wordt geperst. Werkextensivering betekent dat werk zich verspreidt naar tijden en plaatsen die er eerder buiten vielen. Een onderzoek onder IT-medewerkers vond beide patronen in een sector waar technische betrokkenheid en ogenschijnlijke autonomie mensen kunnen aanmoedigen langer te werken en persoonlijk verantwoordelijk te worden voor het bijhouden van hun vaardigheden. (Howcroft en Taylor, “Experiences of working time intensification and extensification”) Het onderzoek stamt van voor het wijdverbreide gebruik van codeeragents en kan daarom niet aantonen dat agents een van beide patronen veroorzaken. Het geeft wel namen aan wat ik ervoer. Meerdere agents vulden mijn dag met meer uitvoer om te beoordelen, terwijl toegang op afstand het toezicht tot voorbij mijn bureau droeg. De telefoonapp maakte dit zichtbaar, omdat hij een grens verwijderde die ik nog belangrijk genoeg vond om te herstellen.

Een agent op de achtergrond eist niet voortdurend aandacht, maar houdt werk beschikbaar. Een melding of de gedachte dat een tegoed is gereset kan me terugbrengen zonder dat iemand een opdracht geeft. Gamificatie gebruikt spelelementen in systemen die geen spel zijn om deelname te beïnvloeden, al hangen de effecten af van de gebruikers en de context. (Hamari, Koivisto en Sarsa, “Does Gamification Work?”) Agentisch programmeren geeft een sterkere reden om terug te keren dan een badge of reeks. Wanneer ik kijk, kan er een echte oplossing klaarstaan. Daardoor is iedere terugkeer te verdedigen, zelfs als het totale patroon er een is waarvoor ik vooraf niet zou hebben gekozen.

Technische vaardigheid verandert wat een agent produceert, gegenereerd werk kan waarde behouden en intensief gebruik wijst op zichzelf niet op verslaving. Mijn zorg is de zeggenschap over mijn aandacht en over het moment waarop werk plaatsmaakt voor de rest van het leven. Productdashboards verantwoorden nauwkeurig de grondstof die de aanbieder levert. Ze tonen percentages, resettijden, tegoeden en abonnementslimieten. Ze verantwoorden niet de grondstof die de gebruiker levert. Ze tonen niet hoelang ik mentaal betrokken ben gebleven, hoe vaak ik terugkeerde nadat ik wilde stoppen, hoeveel onafgemaakte agents om aandacht strijden of dat bespaarde implementatietijd rust werd of alleen meer werk. Het systeem kan efficiënt lijken terwijl het de kosten verplaatst naar plekken die de meter nooit registreert. Een hulpmiddel dat wordt verkocht om tijd te besparen, hoort succes niet alleen af te meten aan hoeveel machinecapaciteit ik wist te verbruiken.

Maak stoppen een geldige uitkomst

Ik begon dit artikel met een periode waarin ik mijn Codex-tegoed zo snel mogelijk probeerde te gebruiken, omdat OpenAI het misschien opnieuw zou resetten. Een weeklimiet in één dag opmaken klinkt van buitenaf absurd. Binnen het systeem kon bewaarde capaciteit verdwijnen en verbruikte capaciteit worden vervangen. Iedere onafgemaakte taak bood een aannemelijke volgende stap, terwijl wisselen tussen Claude Code en Codex het werk gaande hield wanneer een van beide producten een pauze oplegde. Ik reageerde op de prikkels en uitwegen die de producten voor me neerlegden.

Dat ontslaat me niet van iedere keuze die ik maakte, maar het verandert wel waar de kritiek thuishoort. Gebruikers voorhouden dat ze meer discipline moeten tonen is onvoldoende wanneer het product bewaren als verspilling laat voelen, doorgaan als productief en stoppen als achteropraken. Ik hoef niet te weten of ieder effect bedoeld was voordat ik de aanbieder verantwoordelijk kan houden voor het systeem dat hij beheert. De bedrijven beslissen hoe tegoeden verlopen, wat er gebeurt bij onverwachte capaciteitsverhogingen, hoe nadrukkelijk klokken en percentages worden getoond, hoe efficiënt onderbroken werk kan worden hervat en hoe agressief autonoom werk als de nieuwe norm wordt gepresenteerd. Een venster van vijf uur is een ontwerpkeuze. Een weektegoed dat niet kan worden meegenomen is een ontwerpkeuze. De zwaarste gebruikers de meest toegewijde noemen is een keuze. Geen ervan dwingt iemand persoonlijk om door te gaan, maar samen bepalen ze welk gedrag het product beloont en welk gedrag het duur maakt. Zodra die effecten zichtbaar zijn, wordt niets doen ook een keuze.

Limieten kunnen nog steeds nodig zijn. Rekenkracht is duur, gedeelde infrastructuur moet worden verdeeld en een abonnement kan geen onbeperkte toegang tot een schaarse grondstof beloven. Het alternatief is geen product zonder grenzen, maar een product waarvan de grenzen de gebruiker niet tot een voltijdhandelaar in onzekere capaciteit maken. Ongebruikt weektegoed kan binnen een grens worden meegenomen en onverwachte capaciteitsverhogingen kunnen bovenop het bewaarde tegoed komen in plaats van de waarde van bewaren uit te wissen. De interface kan de waarschijnlijke kosten van een taak schatten, de gebruiker vooraf een maximum laten instellen en een duidelijk controlepunt maken zodra dat maximum wordt bereikt. Hervatten na een reset hoort niet een opvallend deel van het nieuwe tegoed te verbruiken om alleen de vorige sessie te reconstrueren. Een dashboard kan naast de percentages en klokken van de aanbieder tonen hoelang iemand bezig is en hoeveel agents onafgemaakt zijn. Stille uren kunnen de werktijden respecteren die de gebruiker kiest. Het product kan wachten, capaciteit bewaren en een sessie beëindigen als normale uitkomsten presenteren in plaats van als lege ruimte voor nog een prompt.

Het verwijderen van de telefoonapp liet me zien dat een kleine hoeveelheid frictie helpt. Ik moest het effect eerst zelf opmerken, besluiten dat ik het niet prettig vond en die grens zelf opleggen. Het product had begeleiding op afstand eenvoudig gemaakt. Het onderscheid tussen werk en de rest van mijn dag herstellen was mijn eigen aanpassing. Dat patroon kennen we uit veel technologie. Een bedrijf verwijdert frictie om een capabeler product te maken, terwijl de gebruiker die weer moet toevoegen om een grens te beschermen die het product niet meet. Codeeragents verdienen extra aandacht omdat betrokkenheid zo sterk op prestatie lijkt. De functionaliteit kan werken. De tests kunnen slagen. Het abonnement kan uitstekende waarde hebben geleverd. Toch kan ik meer aandacht, avond of slaap hebben besteed dan ik van plan was. Succes bij de taak en schade voor de gebruiker kunnen in dezelfde sessie bestaan.

AI-bedrijven beloven ons tijd terug te geven. Volgens OpenAI helpt Codex gebruikers sneller code te schrijven, beoordelen en uit te brengen. (OpenAI, “Codex”) Die belofte hoort enige verantwoordelijkheid te omvatten voor de systemen die ons onmiddellijk uitnodigen de bespaarde tijd opnieuw uit te geven. Bedrijven kunnen niet voor iedere ontwikkelaar bepalen wanneer de laptop dicht moet, en dat zouden ze ook niet moeten doen. Ze kunnen wel stoppen met het ontwerpen van abonnementen waarin ongebruikte capaciteit op verlies lijkt, onzekere vooruitgang een nieuwe poging eeuwig redelijk maakt en de zichtbaarste maatstaf voor succes is hoe volledig we hebben verbruikt wat ze ons verkochten. Een product dat is ontworpen om tijd te besparen, hoort stoppen als een geslaagde uitkomst te behandelen.

Meer lezen

• Ontwerpen moeten hun gebruikers respecteren
• De verborgen kosten van AI-gemak
• Het ja-en probleem met kunstmatige intelligentie