Vrijwel alle AI-bouwtools gaan uit van één persoon achter één scherm. Zodra je met z'n tweeën of drieën aan hetzelfde project werkt, loop je tegen dingen aan die in de tutorials niet voorkomen. Slack bracht deze maand een functie uit waarmee teams gezamenlijk met coderende agents in een kanaal werken, wat aangeeft dat dit een echt probleem is. Hieronder wat er misgaat en hoe je het inricht.
Drie problemen die je in je eentje nooit tegenkomt.
Het eerste is overlap. Twee mensen geven hun agent een opdracht die dezelfde bestanden raakt, en je merkt het pas bij het samenvoegen. Bij handmatig werk gebeurt dat ook, maar dan gaat het om tien regels; een agent raakt in dezelfde tijd twintig bestanden aan. Het samenvoegen kost dan meer tijd dan de opdracht zelf.
Het tweede is dat niemand weet waarom iets er staat. Wie zelf code schrijft, weet welke afweging hij maakte. Bij een agent zit die afweging in een gesprek dat op de machine van één persoon staat. Voor de rest van het team is het resultaat een blok code zonder geschiedenis, en dat maakt beoordelen lastig en aanpassen riskant.
Het derde is dat kwaliteit uiteenloopt. De een geeft zijn agent uitgebreide aanwijzingen over stijl en structuur, de ander niet, en na twee weken staan er twee manieren van werken in hetzelfde project. Dat is geen kwestie van talent maar van ontbrekende afspraken.
Bijna alles hier is organisatie, niet techniek. Dat is goed nieuws, want het kost je een halfuur.
Verdeel het project in gebieden en spreek af wie waar zijn agent op loslaat. Niet omdat iemand anders er niet mag komen, maar zodat twee agents niet tegelijk in dezelfde map werken. Dit lost het overgrote deel van de samenvoegconflicten op en kost niets.
Zet de aanwijzingen voor de agent in een bestand in de repository in plaats van in ieders eigen instellingen: welke stijl, welke bibliotheken, hoe je fouten afhandelt, wat niet mag. Iedereen werkt dan met dezelfde uitgangspunten en nieuwe teamleden zijn meteen bij.
Plak de opdracht die je de agent gaf in de omschrijving van je wijziging. Dat is de goedkoopste vorm van documentatie die bestaat en het geeft de beoordelaar precies wat hij mist: niet alleen wat er staat, maar wat de bedoeling was.
In je eentje kun je meer riskeren dan wanneer anderen op je werk voortbouwen.
De nieuwste generatie tools haalt de agent weg bij één persoon en zet hem in het team.
De verschuiving die deze maand zichtbaar werd, is dat de agent niet meer op iemands laptop draait maar in een gedeelde omgeving waar het team meekijkt. Slack bracht daar een functie voor uit: je geeft een agent in een kanaal een opdracht, collega's zien wat er gebeurt en kunnen bijsturen. De opdracht en het resultaat staan meteen op een plek waar iedereen bij kan.
Het voordeel is dat het tweede probleem hierboven verdwijnt: de redenering staat niet meer op één machine. Het nadeel is dat je nieuwe vragen krijgt over rechten. Een agent in een gedeeld kanaal handelt namens iemand, en wie dat is bepaalt waar hij bij kan. Geef zo'n agent daarom een eigen account met eigen, beperkte rechten in plaats van die van de persoon die hem aanroept.
Werk je met agents die zelfstandig code uitvoeren, houd ze dan sowieso in een afgeschermde omgeving, ook in teamverband; dat staat in een AI-agent in een sandbox draaien. En laat wat eruit komt langs een mens, zeker als het aan beveiliging raakt, om de reden die in AI je beveiligingsfouten laten repareren staat.
Omdat ze zijn ontworpen rond één gebruiker met één context. De opdracht, de redenering en de instellingen zitten bij die persoon, terwijl het resultaat in een gedeeld project belandt. Daardoor ziet de rest van het team wel de code maar niet de afweging, en dat maakt beoordelen en aanpassen moeilijker dan nodig.
Verdeel het project in gebieden en spreek af wie waar zijn agent op loslaat. Het overgrote deel van de samenvoegconflicten ontstaat doordat twee agents tegelijk in dezelfde bestanden werken, en die verdeling kost je vijf minuten overleg per dag.
In een bestand in de repository, niet in de persoonlijke instellingen van elk teamlid. Zet er in welke stijl je aanhoudt, welke bibliotheken je gebruikt, hoe je fouten afhandelt en wat er niet mag. Iedereen werkt dan met dezelfde uitgangspunten, en iemand die erbij komt is meteen bij.
Zet hem in de omschrijving van je wijziging. Dat is de goedkoopste documentatie die er is, en het geeft de beoordelaar wat hij anders mist: niet alleen wat er is veranderd maar wat de bedoeling was. Bij een wijziging van twintig bestanden scheelt dat een half uur uitzoekwerk per beoordeling.
Een nieuwe manier van werken waarbij de agent niet op iemands laptop draait maar in een omgeving waar het hele team meekijkt, bijvoorbeeld een kanaal in je chatprogramma. Slack bracht daar deze maand een functie voor uit. Het voordeel is dat opdracht en resultaat op een gedeelde plek staan in plaats van bij één persoon.
Een eigen account met eigen, beperkte rechten, en niet die van de persoon die hem aanroept. Anders erft de agent alles wat de meest bevoegde collega mag, en dat is bijna nooit wat je bedoelt. Beperk daarnaast wat hij zelfstandig mag afronden zonder dat iemand het heeft gezien.
Door de conventies vast te leggen op een plek waar de agent ze leest, en door bij de beoordeling ook op consistentie te letten in plaats van alleen op werking. Twee stijlen ontstaan niet doordat iemand het fout doet, maar doordat er niets is afgesproken en elke agent zijn eigen voorkeur volgt.
Niet op zichzelf, maar let op wat de rest ermee moet. Wie in een dag oplevert wat een ander in een week beoordeelt, verschuift het knelpunt naar de beoordeling in plaats van het weg te nemen. Snelheid in het bouwen is alleen winst als het beoordelen en onderhouden meekan.
Stuur ons je idee. Wij kijken in een intake mee welke flow je wilt testen en leveren in één werkdag een klikbaar prototype, met de juiste tools voor jouw geval.
Een korte intake volgt na je inschrijving. Daarna stemmen we scope en datum af.
We nemen contact op om de intake in te plannen.
We gebruiken cookies om je ervaring te verbeteren en het gebruik van de site te meten.