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 voor agents, beoordeelt AI-gegenereerde code, bouwt en onderhoudt de infrastructuur waarmee je agent-gedrag evalueert, en debugt afwijkend gedrag in productie. Prompting en evaluatie worden deel van het vak. Begrijpen wanneer een agent faalt — en waarom — is een eigen discipline geworden.

QA en tester. Vóór AI-agents: schrijft testcases, voert regressietests uit. Met AI-agents: beoordeelt of de evalset de juiste scenario’s dekt, valideert AI-gegenereerde tests, en houdt toezicht op pipelines waarbij een LLM de output van een andere LLM beoordeelt. De kernvraag verandert: niet “slaagt de test?” maar “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 die ook agent-gedrag dekken, beslist welke taken agents autonoom mogen uitvoeren en wanneer een mens in de lus moet, en formuleert stopcriteria en escalatieprotocollen als onderdeel van de productvereisten. Dat 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 geautomatiseerde taken en menselijke beslissingen, beoordeelt of de rolverdeling nog klopt naarmate agents meer kunnen, en plant capaciteit waarbij zowel menselijke als agent-capaciteit een rol speelt. De verantwoordelijkheid voor waar die grens ligt, ligt bij de team lead — niet bij de agent.

Drie vragen die jullie expliciet moeten beantwoorden

1. Welke taken mogen agents autonoom uitvoeren?

Definieer dit expliciet — niet als een eenmalige beslissing maar als een levend beleid. Begin conservatief: agents assisteren, mensen beslissen. Breid autonomie uit naarmate vertrouwen en evaluatie-infrastructuur groeien. De fout is niet beginnen met autonomie; de fout is autonomie uitbreiden zonder dat de infrastructuur om het te bewaken 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 80% van een taaktype uitvoert, verliezen teamleden die vaardigheden snel. Dat is geen reden om de agent niet in te zetten — het is wel reden om kennisoverdracht en competentie-onderhoud als expliciete activiteit in het teamplan op te nemen. Een team dat volledig afhankelijk wordt van een agent die ze niet meer begrijpen, heeft een kwetsbaarheid ingebouwd.

De kloof die ontstaat zonder training

De rolverschuiving vraagt training — niet in het gebruik van de tool, maar in de nieuwe taken zelf: specificeren, beoordelen, superviseren.

Dat is een wezenlijk verschil. Een developer die leert hoe hij een specifieke agent-interface bedient, heeft een andere training nodig dan een developer die leert hoe hij een goede specificatie schrijft. Een QA-engineer die leert hoe hij een evalset opzet, leert iets anders dan een QA-engineer die leert hoe hij een bestaand testframwork gebruikt.

Zonder die training ontstaat er een kloof: de agent doet meer, de kwaliteitsborging wordt minder — niet omdat niemand zijn best doet, maar omdat de vaardigheden die kwaliteitsborging vereist, niet zijn meegegroeid met de taken die de agent heeft overgenomen.

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 is geen aankondiging dat developers, testers of product owners overbodig worden. De werkzaamheden verschuiven — ze verdwijnen niet. Het is een uitnodiging om bewust te kiezen welke taken je overdraagt aan agents, en welke je behoudt.

Die keuze is niet eenmalig. Naarmate agents sterker worden, verschuiven de grenzen opnieuw. Teams die die grens actief bewaken en herijken, bouwen een andere soort competentie op dan teams die de grens laten opschuiven zonder dat iemand het expliciet heeft besloten.

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

Hoe ziet de rolverschuiving eruit voor jullie specifieke team — en wat vraagt dat concreet van developers, QA en product owners? Dat werken we door in de workshop Teams & AI.