Vroeger ging in een dev-team het meeste vanzelf: seniors bewaakten de kwaliteit via reviews, juniors leerden door zelf te bouwen en doordat anderen meekeken, de collega die als eerste iets nieuws uitprobeerde kreeg daarvoor volop ruimte in de demo en de gedeelde basis werd besproken en aangepast in de retro. Zodra je met agents gaat werken, verandert dat: die mechanismen gaan niet meer automatisch. Dezelfde vier verantwoordelijkheden moeten dan expliciet belegd worden, als petten: architectuurcoach, leerling, champion en tuinman. Petten, geen functies: één persoon kan er meer dragen. En eigenaarschap is geen vijfde pet: iedere epic, story en codewijziging houdt een menselijke eigenaar.

Voor wie? De tech lead of squad lead die de rolverdeling in een team dat met AI bouwt opnieuw wil beleggen.

De senior verzuipt in reviews van AI-code en komt zelf nauwelijks meer aan bouwen toe. De junior levert meer code dan ooit, maar leert er minder van. En de context-files waar iedereen op leunt, onderhoudt niemand. Drie verschillende klachten, één oorzaak: de rollen in het team zijn stilzwijgend verschoven zonder dat iemand ze opnieuw heeft belegd.

Drie developers bij een whiteboard met vier petten-icoontjes en gele stickies: twee met een naam, twee met een vraagteken
Vier petten. Het team beslist wie welke draagt.

Zodra je met agents gaat werken, verschuift het werk van schrijven naar sturen en beoordelen. Die verschuiving moet je organiseren. De vier verantwoordelijkheden die vroeger stilzwijgend belegd waren, vragen dan een expliciete eigenaar.

Welke rollen heb je al en wat verandert eraan?

Vroeger waren deze vier verantwoordelijkheden belegd zonder dat iemand ze zo noemde. Ze schaalden mee met handwerk. Zodra agents meebouwen, houdt dat op:

Verantwoordelijkheid Vroeger (handwerk) Met AI-agents De pet
Kwaliteit bewaken Seniors, per PR in de review Er komt meer code binnen dan reviewers per regel kunnen nalezen Architectuurcoach: kaders vooraf, review op uitzonderingen en risico
Het vak leren Juniors bouwden zelf, anderen keken mee De agent bouwt mee; de junior levert meer op en leert minder als niemand ingrijpt Leerling, met mentoring als expliciete seniortaak
Werkwijze ontwikkelen De collega die als eerste iets nieuws uitprobeerde, met ruimte in de demo Tooling en mogelijkheden veranderen sneller dan die ene collega bijhoudt; proefprojecten en gedeelde werkafspraken hebben een eigenaar nodig Champion: collega die voordoet en tijd krijgt om te experimenteren met nieuwe tools en ideeën rondom agentic coding
Gedeelde basis onderhouden In de retro besproken en aangepast; opruimen wat je tegenkomt Context-files en patronen zijn nu ook instructies voor de agent; verwaarlozing verspreidt zich als onkruid Tuinman: bewaakt kaders, richtlijnen en samenhang

Herken je de punten in de linkerkolom (vroeger/handwerk)? Dan heb je de petten al, alleen zonder eigenaar. De vraag is wie ze nu stilzwijgend draagt en of dat straks nog past.

Wie bewaakt de kwaliteit en wie leert het vak nog?

De eerste twee petten zitten het dichtst op de code zelf.

  • De senior als architectuurcoach: een senior die de hele dag alleen nog andermans AI-code nakijkt, haakt af. Terecht. De kunst zit in het herdefiniëren van de rol: van senior codeur naar de coach die de kaders bepaalt, uitzonderingen en risicovolle beslissingen beoordeelt en anderen helpt zelfstandig goede keuzes te maken. Nadrukkelijk geen poortwachter die alle AI-output zelf goedkeurt: dan wordt de senior het knelpunt en de enige eigenaar van andermans werk. Niemand kent de codebase beter; zo geeft de rol grip, in plaats van het gevoel dat AI hem overneemt.
  • De junior als leerling: AI versnelt het coderen, maar kan het leren vertragen wanneer een junior oplossingen accepteert zonder ze zelf te reconstrueren, uit te leggen of te testen. Zonder vlieguren in zelf coderen ontwikkelt hij de intuïtie niet die een kritische review vraagt en wordt hij een doorgeefluik van AI-output; de verification debt groeit dan met elke PR. Met een mentor erbij helpt AI juist bij het leren: laat de junior eerst zelf nadenken en laat de AI uitleggen in plaats van genereren. Die mentoring is mensenwerk. AI kan uitleg geven, maar niet betrouwbaar vaststellen of iemand het begrijpt; het mentoren van de junior hoort daarom expliciet bij de seniorrol. DORA waarschuwt hier ook voor: als AI het uitvoerende werk overneemt, missen juniors de kans om ongeschreven kennis op te bouwen die je alleen leert door samen te bouwen [1].

Concrete aanpak voor juniors: laat ze vóór ze AI inzetten zelf het gewenste gedrag, de randgevallen en de verwachte testuitkomsten formuleren en dan pas met AI de tests en de code schrijven (TDD-stijl). Doe je dat niet, dan genereert de AI de code én de tests vanuit dezelfde verkeerde aanname. De junior bepaalt wát er getest wordt; dat is het verschil tussen begrijpen en accepteren.

Waarom breekt het leerlingmodel?

Leren zat vroeger in de worsteling: zelf debuggen, documentatie lezen, een oplossing reconstrueren tot je snapte waarom het werkte. Precies die worsteling automatiseert een agent weg. De code komt binnen, werkt en de vraag “waarom klopt dit?” wordt nooit gesteld.

Dat is geen aanname meer. In een gerandomiseerd experiment van Anthropic leerden developers een voor hen nieuwe library, de ene groep met AI-hulp, de andere zonder. De AI-groep scoorde daarna gemiddeld 50% op een begripstoets, tegenover 67% zonder AI, met het grootste gat bij debugvragen: herkennen wanneer code fout is en waarom [2]. Het interessantste zat onder die gemiddelden. Wie AI gebruikte om concepten uit te leggen en het eigen begrip te toetsen, scoorde 65 tot 86%; wie het werk delegeerde, 24 tot 39%. Het leereffect hangt dus af van hóé je de AI gebruikt.

Tegelijk verdwijnt de mens die dat gebruik stuurt. In het AI Impact Report 2025 van LeadDev zegt 38% van de respondenten dat AI-tools de directe mentoring van juniors door seniors hebben verminderd [3]. De agent neemt het werk over waar de senior vroeger over de schouder meekeek en daarmee verdwijnt ook het gesprek dat daarbij hoorde.

Daarom hoort mentoring expliciet bij de seniorpet: iemand moet ervoor zorgen dat de junior AI gebruikt om te begrijpen in plaats van om over te slaan. Eerst zelf het gedrag en de randgevallen formuleren, dan pas genereren: dat is precies het patroon dat in het onderzoek de hoge scores opleverde.

Wie jaagt de werkwijze aan en wie houdt de boel op orde?

De andere twee petten gaan over de werkwijze zelf: die laten groeien en schoon houden.

  • De champion: de collega die het meest enthousiast is over AI en het voordoet. Niet de enige die AI gebruikt. Wel degene die proefprojecten draait, betere werkafspraken deelt en collega’s meeneemt. Geen trainer en geen manager, gewoon een collega die vertrouwd wordt en er tijd voor krijgt. Dit is een vaste deeltaak, geen aparte functie.
  • De tuinman: AI introduceert patronen die niet bij je architectuur passen. Zonder iemand die dat signaleert, verspreidt het zich als onkruid door je codebase. De tuinman voorkomt dat door de kaders en richtlijnen bij te houden. Bestaande vervuiling opruimen is teamwerk in de sprint. Net als je CI-pipeline: niemand heeft dat als fulltimebaan, maar als niemand het doet, loopt alles vast. Wissel het uitvoerende onderhoud gerust, maar laat één persoon of een klein groepje de samenhang bewaken: wisselt de hele verantwoordelijkheid steeds, dan weet uiteindelijk niemand meer waarom een contextregel bestaat.

Wat gebeurt er met context-files zonder tuinman?

Twee onderzoeken laten het van twee kanten zien. Een analyse van 466 AGENTS.md-bestanden op GitHub vond dat de helft na de eerste commit nooit meer is aangepast en nog eens bijna een kwart precies één keer [4]. De code ontwikkelt zich door, de instructies voor de agent blijven staan zoals ze op dag één zijn bedacht. De auteur noemt het “slow-motion context rot”: context die langzaam wegrot.

Een bredere empirische studie naar 2.303 context-files uit 1.925 repositories (CLAUDE.md, AGENTS.md en copilot-instructions.md) vond juist dat een meerderheid wél actief wordt bijgewerkt, maar vrijwel alleen door toevoegen: per commit komen er mediaan zo’n 57 woorden bij en verdwijnt er bijna niets [5]. De bestanden groeien dus en niemand haalt eruit wat niet meer klopt. Dezelfde studie zag dat bijna alle bestanden gaan over bouwen, testen en architectuur; maar 14,5% gaat over security of performance: precies de kaders waar een agent zonder instructie het vaakst de mist in gaat.

Verwaarlozing en ongecontroleerde groei zijn twee kanten van hetzelfde gat: er is geen eigenaar. Dat is de tuinman. Degene die bewaakt dat de context-files kloppen met de code van vandaag, die snoeit wat verouderd is en die de kaders toevoegt die het team stilzwijgend aanneemt.

Het zijn petten, geen functies. Maar onbelegd raken ze snel verwaarloosd.

Wie is eigenaar van wat de AI maakt?

Welke tool je gebruikt doet er minder toe dan wie welke verantwoordelijkheid neemt zodra de code uit een model komt rollen. Toch is eigenaarschap geen vijfde pet: het wordt per werkitem belegd.

  • Epic: de product- of domeineigenaar bewaakt het gewenste resultaat, de scope en de risico's.
  • Story: een developer is verantwoordelijk voor de oplossing en de acceptatiecriteria.
  • Pull request: de menselijke eigenaar die de code heeft gemaakt of heeft laten maken, kan de AI-output uitleggen en aantonen dat de wijziging correct en veilig genoeg is. Een agent kan dat niet: de sessie waarin hij de code schreef is voorbij en daarmee ook zijn context. Staat er een agent als auteur op de PR, dan ligt die rol bij de developer die hem aanstuurde.
  • Na release: de verantwoordelijkheid ligt bij het team dat de service beheert.

Eigenaarschap is geen aparte pet. Iedere epic, story en codewijziging krijgt een menselijke eigenaar. Wie AI-output accepteert, blijft verantwoordelijk voor het doel, de verificatie en het gedrag na release. AI verandert wie de code schrijft, niet wie ervoor instaat.

Waarom dat eigenaarschap de grootste blokkade bij agentic coding is, werk ik uit in wie is verantwoordelijk voor de code van een AI-agent?

Wat als een pet onbelegd blijft?

Eén persoon kan meerdere petten dragen, in een klein team is dat eerder regel dan uitzondering. Blijft een pet onbelegd, dan merk je dat snel:

  • Zonder architectuurcoach wordt de senior het knelpunt: elke AI-PR wacht op dezelfde reviewer.
  • Zonder mentoring van de leerling groeit de verification debt: juniors zetten AI-output door die niemand doorgrondt.
  • Zonder champion veroudert de werkwijze: iedereen gebruikt de tools nog zoals bij de eerste kennismaking.
  • Zonder tuinman vervuilt de codebase: verouderde context-files en afwijkende patronen verspreiden zich.

De leerling is de pet die het snelst wordt overgeslagen en wat dat op termijn betekent voor hoe juniors het vak nog leren als agents meebouwen, verdient een eigen gesprek.

In veel artikelen over agentic engineering duiken intussen nieuwe functietitels op: AI Orchestrator, AI Guardian [6]. Voor een grote organisatie kan dat werken. Voor een klein of middelgroot team is het een omweg: een nieuwe functie vraagt een vacature, een budget en een plek in het organogram, terwijl de verantwoordelijkheid vandaag al in het team ligt. Een pet kun je morgen beleggen, bij iemand die er al zit, voor een deel van de week. Daarom spreek ik bewust over petten en niet over functies: het maakt de verschuiving klein genoeg om mee te beginnen.

De vraag is dus niet alleen wie de AI aanstuurt, maar ook wie de richting bewaakt, wie het team laat leren, wie de gedeelde basis onderhoudt en wie voor iedere wijziging persoonlijk verantwoordelijkheid neemt.

Deze vier petten horen bij de rest van je AI-adoptie, van de eerste Vonk tot de Borging per sprint, uitgewerkt in het AI-adoptie werkmodel.

Bronnen
  1. DORA: State of AI-assisted Software Development (najaar 2025) ↩
  2. Anthropic: How AI assistance impacts the formation of coding skills (februari 2026) ↩
  3. LeadDev: AI Impact Report 2025, aangehaald in “Do junior devs still have a path to senior roles in an AI age?” ↩
  4. Jitpal Kocher (Wire): What 466 AGENTS.md files teach about context engineering (mei 2026) ↩
  5. Chatlatanagulchai et al.: Agent READMEs, an empirical study of context files for agentic coding (arXiv, november 2025) ↩
  6. DEV Community: Agentic coding in 2026, how engineering teams restructure around AI agents ↩