Je agents zijn niet je knelpunt, maar je samenwerking

Solo met AI bouwen kende ik al. In de maanden voor de hackathon had ik een paar producten in elkaar gezet: sommige stap voor stap, andere volledig agentic. Een boekhoudprogramma. Een energiemonitor die een handvol losse apps vervangt. Dat werkt, en het went sneller dan je denkt. Je krijgt er een bepaald ritme in: jij zet de richting uit, de agent doet het werk, jij corrigeert.

De hackathon van vorige week was iets anders. Niet één mens met zijn agents, maar een heel team van mensen dat ieder óók een stel agents had. Groter, complexer, en met veel minder tijd. De organisator zat trouwens aan de andere kant van de wereld — dat wij fysiek bij elkaar zaten was prettig, geen voorwaarde. Ons project: een digitale gym-manager, zodat medewerkers van andere bedrijven in ons pand onze sportruimte kunnen gebruiken.

En daar liep het meteen tegen iets aan waar de meeste teams die AI opschalen tegenaan gaan lopen. Niet tegen de techniek. Tegen de samenwerking.

Iedereen kan nu alles?

We begonnen met de klassieke rollen: een Product Owner, een designer, een senior developer, een junior. Vertrouwd terrein. Alleen had elk van ons daarnaast een verzameling agents die in principe álles kunnen — backend, frontend, design, tekst. De rolverdeling die vroeger volgde uit wie wát kon, klopte opeens niet meer. Als iedereen alles kan (of zijn agents dat kunnen), hoe knip je het werk dan op in bruikbare stukken?

Dat bleek de moeilijkste vraag van de dag. We kozen twee aanvalsrichtingen. Twee mensen bouwden langs de flow: onboarding en het genereren van een persoonlijk workoutschema. De andere twee probeerden het framework neer te zetten, backend én frontend. De integratie is niet gelukt: te weinig tijd, en twee helften die niet op elkaar aansloten. Continuous integration — vroeg en vaak samenvoegen — is precies de praktijk die dit had moeten opvangen. Alleen hadden we die niet ingericht, en met agents die in een uur produceren waar vroeger een dag over ging, wreekt zo’n verzuim zich sneller dan ooit.

Bekende afloop, zul je denken. Maar de reden waaróm is nieuw.

De typesnelheid was onze rem — en die is weg

Vroeger had een team een natuurlijke rem: typesnelheid. Niemand produceerde sneller code dan hij kon typen, en die snelheid gaf precies genoeg tijd om bij te blijven, af te stemmen, elkaar in te halen. Pairen werkte omdat twee mensen ongeveer even hard gingen.

Die rem is verdwenen. Toen twee developers met verschillende ervaring probeerden te pairen, liep het niet. De één laat zijn agents in hoog tempo los; de ander wil liever overzicht houden op wat er precies ontstaat. Dat is geen verschil in kunde maar in behoefte: de een neemt genoegen met “het werkt”, de ander wil begrijpen wát er werkt. De agents produceren alleen sneller dan je dat samen kunt bespreken. En wat de ervaren developer deed, laat zich nauwelijks navertellen: zijn sturing is intuïtie geworden die op jaren ervaring drijft. Er is geen gedeeld ritme meer waarin je vanzelf synchroniseert. De één loopt in zevenmijlslaarzen, de ander zet liever kleinere stappen.

Andere teams zagen hetzelfde. En de teams die het wél redden, hadden allemaal iets gemeen: ze hadden een nieuw synchronisatiepunt geïntroduceerd voordat ze losgingen.

Rollen vervagen, domeinen niet

Het meest verrassende zat in de rollen. We hadden verwacht dat de grenzen zouden vervagen — en dat deden ze, maar niet zoals gedacht.

Onze designer begon in Claude Design en werkte van daaruit richting code. De Product Owner leverde geen specificatie op papier, maar een specificatie in code: een draaiende microservice die toonde wat hij bedoelde. Geen van beiden had daar de technische kennis voor die vroeger nodig was — en toch stond er iets levends. Het gebrek aan kennis hield hen niet meer tegen. Dat is de winst.

En meteen de valkuil. Want die code vertrouwen ze zelf ook niet — en de senioren al helemaal niet. “Leuk voor de demo, maar dit brengen we nooit zomaar naar productie” was een terugkerende verzuchting. Dat is geen technisch gemopper: het legt bloot dat snelheid en vertrouwen twee verschillende dingen zijn geworden. De developers weten beter waar de risico’s zitten, waar een aanname wringt, waar het straks omvalt. De afstand tussen “het werkt in de demo” en “het is te vertrouwen” is niet kleiner geworden — hij is verschoven naar mensen die hem niet altijd kunnen zien. En hij dicht zich niet met nóg een agent, maar met meer mens-in-de-lus: iemand die beoordeelt, aftekent, verantwoordelijkheid neemt. Wat er precies nodig is om zo’n demo wél naar productie te krijgen, is een verhaal apart — daar kom ik in een volgende blog op terug.

En de instapdrempel? Die ging niet omlaag, maar omhoog — en dat is het ongemakkelijke deel. We hopen dat AI het werk toegankelijker maakt, dat wie minder ervaring heeft sneller meekomt. Wat je ziet als het tempo stijgt, is het omgekeerde: wie het overzicht nog moet opbouwen, raakt juist verder achterop naarmate de agents harder lopen. Dat is geen kwestie van kunde maar van tempo — het systeem heeft de aanloop weggehaald die minder ervaren mensen nodig hebben om erin te groeien. De drempel verschuift van “kun je het bouwen” naar “kun je het bijhouden en beoordelen” — en dat tweede is moeilijker, niet makkelijker. Onder druk kroop bovendien iedereen terug in zijn eigen domein en zijn eigen taal. Dát is niet veranderd: de tools zijn nieuw, de reflex is oud.

Wat de teams deden die wél iets werkends opleverden

Niet elk team liep vast. En het verschil zat niet in betere modellen of snellere agents. Het zat in de manier waarop ze het werk organiseerden.

Eén team dook eerst op het kritieke pad: ze kregen de end-to-end flow werkend als kale MVP, en bouwden daarna pas uit. Een ander team definieerde eerst een fatsoenlijke interface tussen de onderdelen, en splitste pas daarná in twee subteams — zodat de twee helften gegarandeerd op elkaar aansloten. Precies waar ons team mee worstelde. Weer een ander team koos voor mob programming: samen om één scherm, één stroom, geen divergentie. Dat team leverde iets werkends op, zelfs met bewust goedkopere AI-modellen — maar dat is stof voor een volgende blog.

Zelf hield ik mijn deel klein en beheersbaar. Ik werkte met één agent — mijn tokens waren ook bijna op — koos voor een microservice en stubte die eerst in Python. Daarna voegde ik stap voor stap elementen toe. Mijn aandacht ging naar de inhoud: klopt wat we bouwen. Zo blijf je de baas van je agent — je laat hem niet in één sprong een heel systeem bedenken, want dan maakt hij het onherroepelijk te ingewikkeld.

De senior developer deed vrijwel het tegenovergestelde. Hij stuurde een heel peloton agents tegelijk aan en lette niet op de inhoud maar op de systeemdynamiek: lopen ze niet uit elkaar, ontstaat er geen wildgroei, blijft het geheel beheersbaar. Twee totaal verschillende manieren om de baas te blijven — de één door de scope klein te houden, de ander door het zwerm-gedrag te bewaken. Wat ze delen is waar de menselijke toegevoegde waarde zat: niet in het typen, maar in het beoordelen. Klopt de richting, is de scope nog te overzien, bouwen we niet iets wat straks niemand kan onderhouden.

Vijf dingen die we leerden

1. Het werk opknippen is de moeilijkste vraag van de dag. Als iedereen alles kan — of zijn agents dat kunnen — is de vraag niet wie het kan bouwen, maar hoe je het opknipt in bruikbare stukken die later op elkaar aansluiten.
2. De typesnelheid was onze rem én ons synchronisatiepunt — en die is weg. Er is geen gedeeld ritme meer waarin je vanzelf synchroniseert; afstemming moet je nu expliciet organiseren.
3. Rollen vervagen, domeinen niet. Product Owner en designer leveren werkende code, maar die code vertrouwen ze zelf ook niet. De risico-inschatting blijft mensenwerk.
4. De instapdrempel gaat omhoog, niet omlaag. Hij verschuift van “kun je het bouwen” naar “kun je het bijhouden en beoordelen” — en dat tweede is moeilijker, niet makkelijker.
5. De baas blijven kan op meer dan één manier — de scope klein houden óf het zwerm-gedrag bewaken — maar altijd door te beoordelen, nooit door te typen.

Samenwerken is nu het echte werk

Als ik alles terugbreng tot één inzicht: je agents zijn niet je knelpunt. Je samenwerking is het.

Het bouwen kunnen de agents aan. Wat ze niet aankunnen is het afstemmen: wie doet welk stuk, waar raken de stukken elkaar, wanneer stop je en vraag je een mens om hulp. Dat waren vroeger impliciete afspraken die je nauwelijks hoefde uit te spreken, omdat de typesnelheid je vanzelf synchroon hield. Nu moet je ze expliciet maken. Wat vroeger vanzelf ging, moet je nu organiseren.

Concreet betekent dat een paar dingen, en ze zijn minder spannend dan de techniek eronder:

1. Intentie vóór implementatie. Spreek af wát je bouwt en waar de grenzen liggen voordat een agent één regel schrijft. Een korte, gedeelde spec is de nieuwe interface tussen mensen én tussen mens en machine.
2. Gedeelde regels. Leg vast welke afspraken gelden — architectuurgrenzen, wat je wel en niet mag installeren, hoe je code oplevert — zodat je ze niet in elke prompt hoeft te herhalen. Een soort handboek voor je agents.
3. Een backlog die het werk in koppelbare stukken hakt. Niet “bouw de app”, maar afgebakende brokken met een duidelijke rand, zodat twee helften later op elkaar aansluiten.
4. Escaleren boven improviseren. Een verdwaalde junior stelt een vraag. Een verdwaalde agent verzint iets. Spreek af dat een agent stopt en het bij een mens neerlegt zodra hij vastloopt, in plaats van creatief om het probleem heen te bouwen.

In de praktijk hoeft dat niet zwaar te zijn. Leg de rol en grenzen van je agents vast — bijvoorbeeld in een AGENTS.md. Bepaal de intentie van een taak vóór er code komt en zet die ergens neer waar iedereen erbij kan, bijvoorbeeld in een map /specs. En verzamel de regels waaraan de code moet voldoen op één plek, bijvoorbeeld een map /policies. Een paar markdown-bestanden zijn vaak genoeg. Noem het gerust overhead. Maar het is precies het synchronisatiepunt dat we kwijtraakten toen de typesnelheid wegviel. Geen bureaucratie — de nieuwe rem.

En reduceer het niet tot documenten. Het punt van een spec is niet het bestand, het is het gesprek dat het afdwingt: even samen bepalen wát je bouwt voordat vier agents vier kanten op rennen. Datzelfde geldt voor de rituelen die we al hadden. Pairen en mob programming golden lang als duur — twee of drie mensen op één taak. Nu de typesnelheid als synchronisatiepunt is weggevallen, worden ze juist goedkoop: het is misschien wel de simpelste manier om mensen weer op één ritme te krijgen, en om de senior zijn intuïtie hardop te laten delen met wie minder ervaring heeft. Niet proces om het proces — het gesprek om de afstemming.

Waar het op neerkomt

Het blijft mensenwerk. AI opschalen in een team is niet “de mensen bij elkaar zetten en de sprint starten”. De agents nemen het typen over, maar daarmee komt het echte werk juist bovendrijven: richting kiezen, scope klein houden, afstemmen, beoordelen wat je durft te vertrouwen. Dat is en blijft menselijk.

Het goede nieuws: een team kan dit prima zelf ontdekken. Je hoeft er geen duur raamwerk voor in te kopen — al staat er op het moment van schrijven alweer eentje klaar. SAFe bracht net “AI-Native SAFe” uit, aangekondigd als hét operating model voor de AI-native organisatie, inclusief de belofte van “return on AI”. Misschien heb je dat ooit nodig. Maar begin er niet mee.

Begin met drie vragen:

1. Wat is ons synchronisatiepunt nu de typesnelheid is weggevallen? Als het antwoord “geen idee” is, wordt integratie je grootste risico.
2. Waar zit onze menselijke toegevoegde waarde nog? Als iedereen alles kan bouwen, wordt beoordelen — richting, scope, risico — het schaarse goed. Organiseer je daarop?
3. Verhoogt onze manier van werken de instapdrempel in plaats van hem te verlagen? Als tempo de maat wordt, verlies je precies de mensen die je morgen nodig hebt.

En doe daarna het goedkoopste en meest onderschatte wat er is: bouw één dag samen met je agents, en houd er een eerlijke retro op. Die dag leert je meer over je eigen team dan welk diagram ook.

‍