Hoe AI-coderingsagents op te schalen binnen een ontwikkelteam

Eén ontwikkelaar met een coding agent is een productiviteitsverhaal. Het is makkelijk te vertellen, het demonstreert goed, en het is oprecht waar.

Vijf ontwikkelaars met twintig agents is iets heel anders. Het is een coördinatieprobleem, en coördinatieproblemen worden niet opgelost door het gereedschap dat ze heeft gecreëerd. Dit is het deel waar niemand over schrijft, omdat het pas opduikt na de enthousiasme fase: de individuele winsten zijn echt, ze komen onmiddellijk, en dan ergens rond de derde of vierde ontwikkelaar begint het team zijn nieuwe snelheid te besteden aan het opruimen van zichzelf.

Wat volgt is de volgorde van falen. Geen lijst van best practices in abstracto, maar de volgorde waarin dingen daadwerkelijk breken, omdat ze in de verkeerde volgorde oplossen een kwartaal verspilt.

Wat breekt eerst: gedeelde context

Elke ontwikkelaar die een agent gebruikt, leert deze stilletjes hun eigen versie van de codebase.

De ene persoon vertelt hun agent dat het project serveracties gebruikt en nooit API-routes. Een ander noemt het nooit, dus hun agent schrijft API-routes. Een derde noemt het een keer, in een sessie die drie dagen geleden eindigde. Niemand heeft ongelijk, niemand liegt, en de repository bevat nu drie interpretaties van dezelfde conventie. Je merkt dit in de review wachtrij, wat de verkeerde plek is om het te merken: tegen die tijd bestaat de code al.

De oplossing is saai en het is het meest hefboomrijke ding op deze pagina. Zet de conventies in een bestand, commit het bestand.

CLAUDE.md voor Claude Code, AGENTS.md voor Codex en de meeste andere CLI agents, en in de praktijk houden veel teams één draagbaar contextbestand in plaats van twee die uit elkaar drijven. Het mechanisme is belangrijker dan de bestandsnaam: de instructies leven in de repository, dus ze komen aan met een git pull in plaats van via degene die toevallig in de kamer was.

Wat erin hoort:

• De conventies die een agent niet kan afleiden uit het lezen van de code, vooral die welke de codebase momenteel op sommige plaatsen schendt
• De commando's: hoe de tests, de build, de linter te draaien, en welke daarvan automatisch mogen worden uitgevoerd
• De delen van de repo die gevaarlijk zijn om aan te raken, en waarom
• Wat het team niet wil: de refactor waar niemand om vroeg, de afhankelijkheid die niet mag worden toegevoegd, het patroon waar van wordt gemigreerd

Wat er niet in hoort, en hier worden teams verbrand: alles wat specifiek is voor één machine. Absolute paden, persoonlijke API-tokens, lokale poorten, iemands voorkeurseditor. Op het moment dat een machine-specifieke waarde in een gecommitteerd contextbestand terechtkomt, erft elke andere ontwikkelaar een instelling die voor hen verkeerd is, en agents zijn extreem goed in het trouw volgen van instructies die niet meer van toepassing zijn.

Een nuttige test voordat je een regel toevoegt: als een teamgenoot dit ophaalt, helpt het hen of breekt het hen?

Wat breekt als tweede: twee agents, één bestand

Agents onderhandelen niet. Ze controleren niet of iemand anders midden in een bewerking zit. Twee agents die op dezelfde module zijn gericht, zullen elkaar overschrijven, en geen van beiden zal het vermelden, want vanuit het perspectief van elk van hen is het werk succesvol voltooid.

Solo is dit onzichtbaar. Je draait één agent tegelijk, of je draait er meerdere en ze raken toevallig verschillende dingen. In een team wordt het structureel, en het produceert de ergste klasse van bugs: werk dat stilletjes verdwijnt tussen twee groene testruns.

Twee mechanismen lossen het op, en je wilt beide.

Isolatie. Git worktrees geven elke taak zijn eigen checkout van de repository, zodat parallelle agents fysiek niet kunnen botsen. Dit is de goedkope helft van de oplossing en er is geen reden om het niet te doen.

Eigenaarschap. Isolatie stopt het overschrijven; het stopt niet dat twee mensen hetzelfde probleem twee keer oplossen, in twee takken, op twee incompatibele manieren. Dat wordt opgelost bij de toewijzing, door elke taak te beperken tot een set bestanden en dat in de taak zelf te zeggen. Niet "verbeter de checkout flow" maar "verander de betalingsstap, in deze drie bestanden, raak de winkelwagen niet aan".

De tweede helft is degene die teams overslaan, en het is degene die bepaalt of de merge een formaliteit is of een middag.

Wat breekt als derde: review

Alles over review op teamniveau volgt uit één getal: hoeveel diff er per uur binnenkomt.

Eén ontwikkelaar die elke regel leest werkt prima. Vijf ontwikkelaars die elk vier agents draaien genereren meer diff per dag dan het team kan lezen, en de eerlijke uitkomst is niet zorgvuldige review, het is goedkeuringstheater. Een mens die om 18.00 uur een diff van negenhonderd regels doorbladert, produceert een handtekening zonder kennis te produceren, wat erger is dan niet reviewen, omdat het zekerheid creëert waar die er niet is.

Het beleid dat overleeft is niet "alles reviewen" en het is niet "vertrouw de agents". Het is om de review naar de twee grenzen van het werk te verplaatsen: lees het plan voordat de agent begint, want een verkeerd plan dat perfect wordt uitgevoerd is de duurste faalmodus die beschikbaar is, en lees dan de diff in verhouding tot wat de verandering kan breken. Marketingkopie en CSS krijgen een snelle blik. Auth, betalingen, permissies, persoonlijke gegevens en migraties worden regel voor regel gelezen door een mens, elke keer, ongeacht hoe schoon de diff eruitziet.

Dit verdient zijn eigen gesprek, en we hebben het apart opgeschreven: moet je de code van je AI-agent nog steeds reviewen behandelt de tien objectieve signalen dat een verandering verkeerd ging, en de blast radius-tabel die teams kunnen overnemen zoals die is.

Een teamspecifieke toevoeging. Wanneer meerdere agents een repository delen, heeft review toeschrijving nodig: welke agent, welke taak, welke ontwikkelaar. Zonder dat heeft een diff geen auteur en verandert review in archeologie. Dit is het meest bruikbare ding om in je setup te repareren zodra je drie of vier gelijktijdige agents hebt.

Wat breekt als vierde: kosten, en het gesprek over kosten

Tokenuitgaven stoppen met een persoonlijk detail te zijn op het moment dat het op een teamfactuur verschijnt.

De valkuil is dat de factuur maandelijks en geaggregeerd is, dus het gesprek dat het produceert is ook maandelijks en geaggregeerd, wat betekent dat het een beleid produceert in plaats van een oplossing. Iemand stelt een goedkoper model voor iedereen voor. Iemand anders stelt voor om sessies te beperken. Beide zijn gissingen.

De werkelijke verdeling is bijna nooit uniform. Het is een klein aantal langdurige sessies, op een of twee projecten, met context die de hele dag groeide en nooit werd gereset. Dat is een te corrigeren gedrag, en je kunt het alleen oplossen als je de uitgaven per sessie en per project kunt zien in plaats van per maand. We hebben de mechanica hiervan behandeld in hoe je tokengebruik controleert en hoe je het kunt verminderen zonder te vertragen.

Maak het getal zichtbaar voor de mensen die het genereren, voordat het een managementonderwerp wordt. Een ontwikkelaar die kan zien dat één sessie meer kostte dan hun hele vorige dag, verandert hun gewoonten uit zichzelf, en dat kost het team politiek gezien niets.

Wat er daadwerkelijk verandert in de rituelen van het team

Drie dingen, naar onze ervaring en in wat teams rapporteren.

Standup verschuift van status naar deblokkeren. Wat elke persoon gisteren deed is grotendeels zichtbaar in de branches. Wat vijf minuten waard is, is welke agents vastzitten, en waarop.

Prompts worden gedeelde bezittingen. De instructie die een goed resultaat opleverde voor één ontwikkelaar is meer waard voor het team dan de code die het produceerde, en het is precies het soort ding dat verdampt in een privé terminalgeschiedenis. Teams die een gedeelde promptbibliotheek in de repository bijhouden, stoppen met het elke week opnieuw ontdekken van dezelfde formulering.

Specialisatie verschuift van mensen naar rollen. Zodra agents het schrijven overnemen, is de interessante vraag wie wat reviewt, en teams drijven natuurlijk naar het toewijzen van rollen aan agents op dezelfde manier als ze die aan mensen toewijzen: één voor implementatie, één voor review, één voor tests. Dat is het idee achter Agent Teams, waar een taak wordt overgedragen van een Dev-rol naar een QA-rol met de diff, de risico's en de testhints bijgevoegd, en kwaliteitscontroles worden bepaald door je testsuite in plaats van door de eigen mening van een agent over zijn werk.

De setup die standhoudt

Samengevat, in de volgorde die ertoe doet:

De eerste vier kosten niets behalve overeenstemming. De laatste twee zijn de reden waarom een team uiteindelijk iets boven de terminal wil: niet omdat terminals slecht zijn, maar omdat een terminal één agent tegelijk toont en je geen manier geeft om te antwoorden "wie draait wat, op welk project, op dit moment".

Dat is het probleem waar AgentsRoom voor teams omheen is gebouwd: elke agent over elk project in één overzicht, met zijn rol, zijn status en zijn kosten bijgevoegd, en een mobiele metgezel voor de momenten dat het team niet aan hun bureau zit. Het werkt op dezelfde manier met Claude Code en met Codex, wat belangrijker is dan het klinkt: de meeste teams eindigen met het draaien van beide, en een setup die één provider aanneemt wordt stilletjes het volgende dat breekt.

Begin echter met het contextbestand. Het is gratis, het kost een middag, en het verwijdert meer wrijving dan welke tool je dit kwartaal kunt installeren.