Sneller is niet hetzelfde als beter

Een Scrum Masters blik op AI, burnout en de vraag die niemand stelt in de retrospective

Een developer in mijn team somt in twintig minuten twintig dingen op die hij met AI heeft aangepakt deze week. Code review, documentatie, een refactor, drie bugfixes, een architectuurvoorstel. Hij praat snel, enthousiast, een beetje gejaagd. Pas later die week zie ik de andere kant: hij weet niet meer welke code hij zelf heeft geschreven en welke door een model is gegenereerd. Hij twijfelt of de tests die hij heeft “geschreven” wel kloppen, want hij heeft ze nooit echt gelezen. En de rekening van zijn AI-abonnement is deze maand verdrievoudigd.

Op het eerste gezicht is dit een productiviteitsverhaal. Twintig dingen in een week, wie wil dat niet. Maar onder die oppervlakte zit iets anders: een mens die sneller beweegt dan hij kan verwerken, en daar een prijs voor betaalt die nergens in een sprint review terugkomt.

Ik ben Scrum Master. Mijn werk is niet om te zeggen of AI goed of slecht is. Mijn werk is om te zien wat er met mensen gebeurt als de manier van werken verandert, en daar iets bruikbaars mee te doen. En wat ik zie, wordt nu ook onderbouwd door onderzoek.

Het onderzoek dat de stilte doorbreekt

Een team van Oregon State University publiceerde recent een studie onder 442 professionele developers, gepresenteerd op ICSE 2026, een van de grootste software engineering-conferenties ter wereld. De onderzoeksvraag was simpel en tegelijk ongemakkelijk: wat doet de adoptie van generatieve AI met burnout onder developers?

Ze gebruikten het Job Demands-Resources model, een raamwerk dat al decennia wordt gebruikt om burnout te begrijpen. De kern: burnout ontstaat wanneer de eisen die werk aan je stelt (workload, druk vanuit de organisatie) niet in balans zijn met de hulpbronnen die je hebt om daarmee om te gaan (autonomie, leermogelijkheden, steun).

De uitkomst is helder. Werkdruk en organisatorische druk die voortkomen uit AI-adoptie hangen significant samen met burnout. Autonomie en leermiddelen werken juist beschermend. En hoe iemand AI ervaart, positief of negatief, beïnvloedt hoeveel stress die persoon voelt bij hetzelfde gebruik.

Een paar uitspraken van deelnemers blijven hangen. Eén ontwikkelaar omschreef het gevoel als rijden met een auto die voor 100 mijl per uur is gebouwd terwijl zijn brein optimaal werkt op 60. Een ander zei het scherper: AI is wel behulpzaam, maar niet zo behulpzaam dat het echt verschil maakt, en toch wordt er nu meer van hem verwacht. Het resultaat: hij is meer tijd kwijt aan zijn werk dan voor AI, niet minder. De belofte was dat AI hem zou ontlasten. Wat hij ervaart is dat dezelfde output nu een hogere prijs heeft, of dat er simpelweg meer van hem wordt gevraagd binnen dezelfde tijd.

Dit weerlegt niet dat AI productief kan zijn. GitHub rapporteerde taken die 56% sneller werden afgerond. Maar diezelfde onderzoekslijn laat ook zien dat 67% van de developers meer tijd kwijt is aan het debuggen van AI-gegenereerde code, en dat een grootschalig onderzoek onder 39.000 developers een dalende leverperformance vond ondanks stijgend AI-gebruik. De winst wordt ergens anders weer opgegeten.

De verborgen rekening

Wat het onderzoek concreet maakt, is waar die kosten precies zitten.

Validatie kost tijd. Iedere AI-suggestie moet beoordeeld worden, en die beoordeling vraagt evenveel of meer concentratie dan het zelf schrijven van code. Een deelnemer noemde het een “mini peer review die mijn gedachtegang breekt”, telkens wanneer AI iets voorstelt tijdens het programmeren.

Context switching neemt toe. Prompten, controleren, corrigeren, opnieuw prompten. Elke stap is een kleine onderbreking van de flow die nodig is om complex werk goed te doen. En er is nog een laag die minder zichtbaar is: terwijl een agent aan het werk is, wachten mensen zelden stil. Ze starten alvast een andere prompt, pakken een ander taakje op, schakelen naar een derde ding. Drie of vier lopende threads tegelijk voelt productief, maar elke overgang kost opnieuw aandacht om terug te vinden waar je was en waarom. Die rekening wordt zelden meegenomen wanneer iemand “productiviteit” meet.

En dan is er de sociale druk. “Ik moet wel mee, want collega’s vertrouwen al op AI-output,” zei een respondent. Niet omdat het werk dat vraagt, maar omdat het gevoel van achterblijven onverdraaglijk is geworden.

Dit patroon is breder dan software alleen. We leven in een tijd waarin een filmpje van dertig seconden al te lang voelt. Aandacht is schaars geworden, en de belofte van AI, alles sneller, alles direct, voedt diezelfde honger naar snelle bevrediging in plaats van haar te temperen. Developers zitten niet in een uitzondering. Ze zitten midden in de trend.

Het onderzoek laat ook zien dat dit niet voor iedereen gelijk uitpakt. Senior developers en mensen in grotere organisaties hebben vaker toegang tot training en hebben meer autonomie om zelf te bepalen hoe ze AI inzetten. Junior developers krijgen vaker een tool in handen gedrukt zonder begeleiding, met als risico dat ze sneller naar copy-paste grijpen en trager fundamentele vaardigheden opbouwen. “Ik vrees dat junioren veel langer nodig hebben om op het niveau te komen van developers met tien jaar ervaring,” zei een van de deelnemers.

Niet iedereen heeft dezelfde mentale tolerantie voor deze verandering, en dat is geen zwakte. Dat is gewoon waar.

Wat een Scrum Master hier wel kan doen

Ik heb geen pasklare oplossing, en ik wantrouw iedereen die die wel claimt te hebben. Wat ik wel kan doen, is op drie niveaus tegelijk werken: in het team, als waarnemer, en naar boven toe in de organisatie. Het onderzoek wijst namelijk niet naar één hefboom, maar naar een samenspel van factoren, en dat vraagt om een breder antwoord dan alleen “betere vragen stellen in de retro.”

• Bespreekbaar maken, structureel, niet incidenteel. Stress en beginnende burnout-signalen worden vaak pas besproken als het al misgaat. Dat is te laat. In de retrospective kan dat concreter: niet alleen “wat ging goed, wat ging minder,” maar ook hoe het voelde om deze week met AI te werken, als hulp of als last. Wat heeft een AI-taak werkelijk gekost aan tijd, energie en focus, los van wat het opleverde. Belangrijker nog dan de vraag is de toon: dit moet een vast, terugkerend onderwerp worden, zonder oordeel, zodat iemand niet pas aan de bel hoeft te trekken wanneer het al een probleem is geworden.
• Bewust vertraging inbouwen. Als de cultuur is dat alles met AI nu sneller moet, dan is vertraging een vorm van weerstand bieden, en dat is een taak die bij de Scrum Master past. Dat kan heel praktisch: een team-afspraak dat niet elke taak met AI hoeft, dat er ruimte blijft voor diep, ongestoord werk zonder tool. Of een grens aan hoeveel agent-taken iemand tegelijk laat lopen, juist om de verborgen context-switching kosten te beperken die hierboven beschreven staan. Snelheid is geen doel op zich, het is een middel, en een team mag daar zelf de regelaar van zijn.
• Twijfel normaliseren. Het is geen technofobie om AI-output niet te vertrouwen. Het is vakmanschap. Een team waarin het oké is om hardop te zeggen “ik vertrouw deze output niet” zonder dat dat als traagheid of weerstand wordt gelezen, bouwt precies de autonomie op die het onderzoek als beschermfactor identificeert. Autonomie betekent ook de vrijheid om AI links te laten liggen voor een taak.
• Signaleren voordat het een probleem wordt. Mensen die structureel overuren draaien “omdat het nu zo makkelijk gaat” zijn een patroon, geen incident. Als Scrum Master zit ik dicht genoeg op het team om dat vroeg te zien, en de verantwoordelijkheid is om dat te agenderen voordat het uitmondt in verzuim.
• En het gesprek naar boven voeren. Dit is misschien het punt dat het makkelijkst wordt vergeten, en het onderzoek maakt juist duidelijk hoe belangrijk het is: organisatorische druk is een net zo sterke voorspeller van burnout als workload zelf. Het is niet omdat AI nu beschikbaar is, dat de verwachtingen oneindig kunnen stijgen. Een Scrum Master die alleen naar binnen toe het team beschermt maar niet naar boven toe de verwachtingen bijstelt, doet maar het halve werk. Dat gesprek met management voeren, met dit soort onderzoek in de hand in plaats van een onderbuikgevoel, geeft dat gesprek gewicht. Het is geen klacht, het is een patroon met 442 datapunten.

Transparantie loopt door dit alles heen. Het delen van onderzoek zoals dit, en van concrete voorbeelden zoals die developer met zijn twintig dingen in twintig minuten, laat zien dat dit geen individueel falen is. Het is een systemisch patroon, en systemische patronen verdienen systemische aandacht, niet stille zelfverwijten.

Sneller zonder dat het ten koste gaat van het team

AI gaat het werk van developers blijvend veranderen. Dat is geen vraag meer. De vraag is of we die verandering bewust vormgeven, of dat we toekijken hoe organisatorische druk en onbegrensde verwachtingen die verandering voor ons invullen.

Sneller is niet hetzelfde als beter. Meer output is niet hetzelfde als meer waarde. En een team dat opbrandt terwijl de velocity stijgt, heeft geen probleem opgelost. Het heeft het probleem alleen verplaatst naar een plek waar het langer duurt voordat iemand het ziet.

Als Scrum Master is mijn taak niet om AI tegen te houden. Mijn taak is om ervoor te zorgen dat de mensen in mijn team niet stilletjes verdwijnen achter de schermen van hun eigen productiviteit.