Hoe AI-agents de rollen in je team verschuiven

Voor wie? Cross-functionele teams — developers, QA, product owners, team leads — die AI-agents introduceren of al gebruiken, en merken dat de taakverdeling onduidelijker wordt naarmate agents meer kunnen.

Kort: Agents nemen taken over die mensen uitvoerden. De menselijke rol verdwijnt daardoor niet — hij verschuift naar specificeren, beoordelen en superviseren. Die verschuiving vraagt andere vaardigheden en andere teamafspraken, en ze ontstaat niet vanzelf. In de workshop Teams & AI werken we dit concreet door met jullie eigen rollen als uitgangspunt.

Een developer vraagt een AI-agent om een feature te implementeren. De agent levert iets op. De developer kijkt of het klopt, past het aan en merged. Drie maanden later is de agent zo sterk verbeterd dat hij ook edge cases zelfstandig afhandelt. De developer reviewt nog, maar minder intensief. Een halfjaar later worden de meeste pull requests zonder grondige review gemerged, want de agent maakt zelden fouten.

Totdat hij er één maakt die niemand zag aankomen — en niemand precies begrijpt waarom.

Dat scenario is niet onvermijdelijk. Maar het ontstaat als teams de rolverschuiving laten plaatsvinden in plaats van hem in te richten.

Wat er concreet verandert per rol

Developer. Vóór AI-agents: schrijft code, debugt, implementeert. Met AI-agents: schrijft specificaties, beoordeelt gegenereerde code, bouwt evaluatie-infrastructuur, en debugt productie-afwijkingen. Prompting en evaluatie worden deel van het vak. Begrijpen wanneer een agent faalt is een eigen discipline geworden.

QA en tester. Vóór AI-agents: schrijft testcases, voert regressietests uit. Met AI-agents: beoordeelt of evalsets correct zijn, valideert gegenereerde tests, houdt toezicht op LLM-beoordelingspipelines. De kernvraag verandert: van “slaagt de test?” naar “dekt de test het gedrag dat ertoe doet?”

Product owner. Vóór AI-agents: schrijft user stories, prioriteert de backlog. Met AI-agents: definieert acceptatiecriteria voor agent-gedrag, beslist welke taken agents autonoom mogen doen, formuleert stopcriteria en escalatieprotocollen. Dit zijn nieuwe vragen in een bestaande rol.

Manager en team lead. Vóór AI-agents: bewaakt voortgang, lost blokkades op. Met AI-agents: bewaakt de grens tussen automatisering en menselijke beslissingen, heronderzoekt de rolverdeling naarmate agents sterker worden, plant capaciteit met zowel menselijke als agent-rollen. De team lead bepaalt waar die grens ligt; niet de agent.

Conductor of orchestrator: twee manieren van sturen

De developer-rol herkent zich in wat Addy Osmani als een spectrum beschrijft. Bij “conductor” sturen jullie één agent synchroon — elke stap keuren jullie goed voordat de volgende begint. Bij “orchestrator” verdelen jullie taken over meerdere agents en reviewen jullie achteraf. Kent Beck: “The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.” Osmani waarschuwt: “the code review loop is going to need work if all this code is not to be slop.” Dit is exact de reviewdiscipline die centraal staat.

Drie vragen die jullie expliciet moeten beantwoorden

1. Welke taken mogen agents autonoom uitvoeren?

Definieer dit expliciet als een levend beleid, niet eenmalig. Begin conservatief: agents assisteren, mensen beslissen. Breid autonomie uit naarmate vertrouwen en evaluatie-infrastructuur groeien. De fout is niet beginnen met autonomie; het is autonomie uitbreiden zonder dat de bewakingsinfrastructuur meegroeit.

2. Wie is eigenaar van de agent?

Een agent in productie is een systeem dat onderhoud nodig heeft, gedrag vertoont dat bewaakt moet worden, en fouten maakt die iemand moet oplossen. Zonder duidelijk eigenaarschap valt niemand terug op de agent als het misgaat. Eigenaarschap betekent niet dat één persoon alles oplost — het betekent dat er één persoon is die het overzicht heeft en de eerste verantwoordelijkheid draagt.

3. Hoe blijft het team competent naast de agent?

Als een agent het grootste deel van een taaktype uitvoert, verliezen teamleden vaardigheden snel. Dit is geen reden om agents niet in te zetten; het is reden om kennisoverdracht expliciet in het teamplan op te nemen. Een team dat volledig afhankelijk wordt van een agent zonder die te begrijpen, heeft een kwetsbaarheid ingebouwd.

De kloof die ontstaat zonder training

De rolverschuiving vraagt training in de nieuwe taken: specificeren, beoordelen, superviseren; niet alleen in tool-gebruik.

Dit is essentieel verschil: een developer die een agent-interface leert is anders dan een die goede specificaties leert schrijven. Een QA-engineer die evalsets opzet leert iets anders dan een die testframeworks gebruikt.

Zonder training ontstaat een kloof: agents doen meer, kwaliteitsborging daalt — niet door gebrek aan inspanning, maar doordat noodzakelijke vaardigheden niet zijn meegegroeid.

Het is niet de agent die de kwaliteit bepaalt. Het is de kwaliteit van de specificaties en de beoordeling die jullie leveren.

Bewust kiezen wat je overdraagt

De rolverschuiving betekent niet dat developers, testers of product owners overbodig worden. Werkzaamheden verschuiven; ze verdwijnen niet. Het is een keuze: welke taken overdragen aan agents, welke behouden?

Die keuze is niet eenmalig. Naarmate agents sterker worden, verschuiven de grenzen opnieuw. Teams die actief die grens bewaken bouwen andere competentie op dan teams die de grens laten opschuiven zonder expliciete beslissing.

Het verschil zit niet in de agent. Het zit in of jullie als team bepalen waar de grens ligt.

De rolverschuiving voor jullie specifieke team werken we door in de workshop Teams & AI. Wat dat concreet vraagt voor developers, QA en product owners ontdekken jullie daar.