Vibe coden in het raamwerk van een developer
In mijn eigen repo zegt een agent "zet het live" en staat het er. In een teamrepo werkt dat anders. Dit is hoe ik als product owner side-by-side met developers en een agent werk, en waar het schuurt.
Met vibe coding komt mijn droom als product owner steeds dichterbij. Je gaat van story naar, in sommige deelprojecten, side-by-side coden. Tof. In Claude zeg je gewoon "zet het live" en een paar minuten later staat het er. In een git-repo met structuur, met een ontwikkelteam eromheen, werken die zaken allemaal net even anders.
Dit is hoe ik het doe, in mijn eigen speeltuin bij Next Day Online en in projecten waar ik als product owner naast developers zit.
In het kort
- In je eigen repo mag een agent bouwen, mergen en live zetten. In een teamrepo opent hij een pull request en bepaalt het team de rest.
- Van het git-schema hoef je als product owner twee pijlen te onthouden: tot git push raak je niemand, en git pull komt vóór het bouwen.
- De agent bouwt op een branch, de PR gaat open als draft, een developer reviewt en mergt. Jij schrijft de story en loopt de acceptatiecriteria na.
- Vier afspraken vooraf voorkomen de meeste wrijving: een vast voorvoegsel voor je branches, altijd een draft-PR, geen pakketten of migraties zonder akkoord, en bij een conflict samen oplossen.
Twee werelden
In mijn eigen repo's maakt Claude Code een branch, bouwt, opent een pull request en mergt zelf als het binnen zijn mandaat valt. Main is van mij, dus de regels zijn van mij. Die regels staan in een bestand in de repo: werk op een branch met het voorvoegsel claude, laat typecheck, tests en build slagen, merge zelf en zet live. Na de deploy controleert de agent de route die hij heeft aangeraakt en schrijft hij een logregel met de commit-hash en het PR-nummer. Gaat er toch iets mis, dan rol ik terug via Vercel en heeft niemand er last van gehad behalve ik.
In een teamrepo is main van niemand. Je kunt er niet rechtstreeks op pushen, een PR heeft een reviewer nodig en de tests moeten groen zijn. "Zet het live" bestaat daar niet. Het heet "open een PR", en wat daarna gebeurt, bepaalt het team.
Het schema in vier vakjes
Het plaatje hierboven zag ik lang als iets voor developers. Vier vakjes, acht pijlen, en toch heeft een product owner die het ritme van zijn team wil volgen er iets aan. De vakjes van links naar rechts:
- De werkmap (working directory) is de map op je computer, of in de cloudomgeving van je agent, met de bestanden die je bewerkt. Alles wat een agent typt, landt hier eerst.
- De staging area is de stapel wijzigingen die je klaarzet voor een commit. Met git add kies je welke bestanden meegaan; wat je niet toevoegt, blijft liggen.
- De lokale repo is de geschiedenis op je eigen machine. Git commit maakt daar een vast punt van, met een boodschap erbij die uitlegt wat er veranderde.
- De remote repo is de versie op GitHub die het hele team ziet. Git push brengt jouw commits daarheen, git fetch en git pull halen het werk van anderen op.
De overige pijlen zijn snel verteld. Git merge voegt twee lijnen geschiedenis samen, git checkout wisselt tussen branches of haalt een eerdere versie van een bestand terug, en git clone maakt op een nieuwe machine een complete kopie van de remote. Meer hoef je als product owner niet uit je hoofd te kennen; de agent typt de commando's.
De twee pijlen die voor een product owner tellen
Tot git push raak je niemand. Alles links van die pijl is jouw zandbak, waar een agent mag bouwen en slopen zonder dat een collega het merkt. Een commit die achteraf fout blijkt, gooi je in je lokale repo weg. Pas bij de push wordt het werk van jou en de agent zichtbaar voor de rest.
En git pull moet vóór het bouwen. Begint je agent op een kopie van vorige week, dan botst zijn werk bij de PR met wat een collega gisteren heeft gemerged. Git noemt dat een merge-conflict, en daar kom ik hieronder op terug. Een agent die eerst main binnenhaalt en dan pas begint, voorkomt het grootste deel ervan.
Side-by-side: wie doet wat
Ik schrijf de story met acceptatiecriteria die je kunt afvinken, en lees hem terug alsof ik de agent ben. Staat er "de gebruiker moet dit makkelijk kunnen doen", dan kan niemand daar code van maken. Staat er "de knop Opslaan blijft uitgeschakeld zolang het e-mailveld leeg is", dan wel.
De agent maakt een branch met de naam van het ticket, haalt eerst main binnen en bouwt. Daarna laat ik hem opsommen welke bestanden hij heeft aangeraakt. Vroeg ik om een tekstwijziging en staan er dertig bestanden in de lijst, dan open ik de PR niet. Dan is er iets anders gebeurd dan ik vroeg, en dat zoek ik eerst uit.
De PR gaat open als draft. Een draft staat in GitHub zichtbaar als werk in uitvoering: iedereen kan meekijken, niemand hoeft al te reviewen. Ik loop de acceptatiecriteria na op de preview, daarna vraag ik een developer om review. De developer leest de diff, ik zit ernaast en leg uit waarom ik het vroeg. Komt er "dit werkt, maar zo doen we het hier niet", dan laat ik de agent het ombouwen met die opmerkingen als instructie. Je leert in één review meer over een codebase dan in een maand stories schrijven.
De developer mergt. Nooit ik, nooit de agent.
Waar het schuurt
Een agent die mijn eigen repo's gewend is, probeert ook in een teamrepo te mergen als hij de rechten heeft. Daar zijn twee remmen voor nodig. Branch protection op main, zodat GitHub een merge zonder review en zonder groene tests weigert, en de instructie in de repo dat de agent hier nooit mergt. Allebei, want een regel in een prompt is geen beveiliging.
Bij een merge-conflict biedt de agent aan het op te lossen. Zo'n conflict ontstaat als twee branches dezelfde regels hebben veranderd en git niet kan kiezen welke versie wint. Laat de agent dat niet alleen doen; hij kiest een kant zonder te weten waarom de collega die regel veranderde. Ik stop, pak de collega erbij en we kiezen samen.
Een nieuw pakket of een databasewijziging is in een teamrepo een besluit, dus de agent mag het alleen voorstellen in de PR-beschrijving. Een pakket is een afhankelijkheid die het hele team erbij krijgt, met toekomstige updates en kwetsbaarheden en al. Een migratie verandert de database waar ook andere code op leunt. Zulke keuzes maakt een developer, in de PR, met de argumenten van de agent ernaast.
En een API-sleutel staat in de omgevingsvariabelen van het platform en nergens anders. Eén sleutel in één commit staat voor altijd in de geschiedenis, ook als je hem in de volgende commit weer weghaalt. Dan rest alleen nog de sleutel intrekken en een nieuwe aanmaken.
Wat je als product owner wint
Ik laat dingen zien in plaats van ze te beschrijven. Vroeger kwam ik met een story en een schets, nu met een branch waarin het al werkt. Een developer reageert anders op werkende code dan op een wens. De discussie gaat meteen over hoe het netjes in de codebase past, in plaats van over wat ik eigenlijk bedoelde.
En mijn stories zijn scherper geworden. Als je elke story eerst door een agent laat bouwen, voel je binnen een minuut waar hij vaag was. De agent vraagt door op dezelfde punten waar een developer in de refinement over zou vallen, alleen krijg je dat nu te horen voordat er een mens tijd aan kwijt is.
Vier afspraken voordat je begint
- Jouw branches hebben een vast voorvoegsel, bijvoorbeeld de naam van de agent, zodat iedereen in de lijst ziet dat er een agent achter zit.
- Elke PR gaat open als draft en wordt gemerged door een developer.
- De agent raakt geen pakketten, migraties of omgevingsvariabelen aan zonder akkoord in de PR.
- Bij een conflict stop je en los je het samen met de collega op die de andere kant schreef.
Daarna is het gewoon werken. Story, branch, PR, review, merge, in hetzelfde ritme als het team, alleen typ jij geen code.
Werk jij als product owner al met een agent in de repo van je team? Ik hoor graag waar het bij jou schuurt.
Veelgestelde vragen over vibe coden in een teamrepo
Mag een AI-agent zomaar pushen naar de repo van een team?
Pushen naar een eigen branch kan meestal zonder iemand te raken; dat is de zandbak links van de pijl git push in het schema. Wat niet kan, is rechtstreeks op main pushen of een PR mergen. Daar hoort branch protection op te staan, zodat GitHub die acties weigert, en daarnaast een instructie in de repo dat de agent nooit mergt.
Waarom moet git pull vóór het bouwen?
Omdat de agent anders begint op een oude kopie van de code. Alles wat collega's sindsdien hebben gemerged, ontbreekt in zijn versie, en bij de PR botsen de twee geschiedenissen. Haalt de agent eerst main binnen, dan bouwt hij op de actuele stand en blijft een conflict beperkt tot regels die echt tegelijk zijn veranderd.
Wat is een draft pull request?
Een pull request die in GitHub als werk in uitvoering staat. Iedereen kan de wijzigingen en de preview bekijken, maar er wordt nog geen review verwacht en mergen kan niet. Zodra de acceptatiecriteria kloppen, zet je hem op "ready for review" en vraag je een developer.
Wat doe ik als de agent een merge-conflict meldt?
Stoppen en de collega erbij halen die de andere kant van het conflict schreef. De agent kan de regels samenvoegen, maar weet niet waarom die collega iets veranderde en kiest dan een kant op gevoel. Samen kiezen kost een paar minuten en voorkomt dat er werk van een ander verdwijnt.