Van taak naar PR:
de delivery-workflow
Met de launcher en de workspace-repo op orde (stap 1 en 2) is de basis gelegd. Nu wordt de agent verbonden met het echte werk: het taskboard. Dit is het moment waarop de agent stopt met “iets doen dat handig lijkt” en begint met “werk oppakken dat de organisatie heeft geprioriteerd”.
Stap 3, 4 en 5 zijn onlosmakelijk verbonden. Het taskboard geeft richting, Git bewijst wat er is gedaan, en de vertrouwensopbouw bepaalt hoe snel je dat stelsel kunt uitbreiden. Sla één van de drie over, en de andere twee werken maar half.
Stap 3 · Koppel een taakbeheersysteem
Het taskboard is de gedeelde werkvoorraad én een zichtbare state machine. Niets gebeurt buiten het bord om. Niet door de agent, niet door de developer naast hem.
De agent krijgt via een veilige integratie toegang tot het systeem van keuze: Jira, ClickUp, Azure DevOps, GitHub Projects of vergelijkbaar. Dat kan via een API-token met minimale rechten, of via een MCP-koppeling die precies die acties toestaat die nodig zijn voor de taakcyclus. Breed toegang geven omdat het makkelijker is, is een anti-patroon: scope de bevoegdheid op wat de agent werkelijk nodig heeft.
Vanaf dit moment is het bord de enige bron van werk. Mens en agent zien dezelfde voorraad, dezelfde statussen en hetzelfde bewijs. Wat niet op het bord staat, bestaat niet voor de agent.
De vaste taakcyclus:
- Lees taak, acceptatiecriteria en afhankelijkheden. Ontbreken die? Vraag om verduidelijking via comment. De agent gokt niet.
- Claim de taak en zet die op In Progress, zodat geen tweede agent of collega hetzelfde oppakt.
- Maak branch, implementeer en test volgens de workflows uit de workspace-repo.
- Maak commit en pull/merge request met verwijzing naar de taak.
- Voeg bewijs en samenvatting toe aan de taak: wat gedaan, hoe getest, waar staat de PR.
- Zet naar Review of Testing. Nooit stilzwijgend naar Done.
Doorstroom op het bord:
Mens of geautomatiseerde gate
De agent neemt de cyclus tot en met Review. Wat daarna komt, beslist een mens of een expliciete policy.
Valkuilen:
- Taken zonder acceptatiecriteria. De agent levert wat er letterlijk staat, niet wat je bedoelde. Investeer in taakhygiëne voordat je taken delegeert.
- Twee agents claimen dezelfde taak. Maak claimen atomair: status en assignee in één operatie, zodat er geen race condition mogelijk is.
- De agent rapporteert ‘klaar’ zonder bewijs. Eis testoutput, screenshots of een PR-link als onderdeel van de statusovergang. Geen bewijs betekent terug naar In Progress.
Eén taak doorloopt een volledig traceerbare cyclus van To Do tot Review, waarbij elke statusovergang, het bewijs en de PR-link op het bord staan, zonder dat een mens iets heeft overgetypt.
Stap 4 · Werk met Git flow en CI/CD
Het taskboard vertelt wát er gebeurt. Git bewijst hóe. CI/CD maakt elke wijziging verifieerbaar voordat die een volgende omgeving bereikt.
Dit is geen extra bureaucratie bovenop het ontwikkelproces. Het is precies het tegendeel: een agent die altijd via dezelfde route werkt, maakt de reviewlast kleiner naarmate het vertrouwen groeit.
De aanpak:
- Branchnaam bevat het taak-ID (bijv.
feature/PROJ-142-invoice-export) zodat elke commit herleidbaar is naar de beslissing die eraan ten grondslag lag. - Pull request bevat scope, risico en testbewijs. Maak een PR-template; de agent vult hem consequenter in dan de gemiddelde developer, omdat hij geen slechte dag heeft.
- CI voert build, tests, linting en securitychecks uit op elke PR. De agent krijgt CI-falen als feedback en herstelt zelf tot de pipeline groen is. Iteraties zijn zichtbaar in de PR-geschiedenis.
- Artifacts zijn immutable en worden tussen omgevingen gepromoveerd. Wat op staging getest is, is bit-voor-bit wat naar productie gaat. Nooit opnieuw bouwen op een andere tak.
- Rollback is vooraf ontworpen en getest. Een rollbackplan dat nooit geoefend is, is een hoop, geen plan. Test het minstens één keer voor je het nodig hebt.
“Review van AI-code is geen wantrouwen, maar het mechanisme waarmee je autonomie kunt verhogen: hoe betrouwbaarder de pipeline bewijst dat een wijziging deugt, hoe minder een mens per wijziging hoeft te kijken en hoe meer taken je veilig kunt delegeren. Investeringen in tests en CI betalen zich hier dubbel uit.”
Valkuilen:
- De agent krijgt merge-rechten op de hoofdbranch “omdat de tests toch groen zijn.” Houd merge naar main bij een mens of een expliciete policy, zeker in de eerste iteraties.
- Flaky tests. Een agent die leert dat rood “gewoon nog een keer draaien” betekent, leert precies het verkeerde. Los flaky tests op voordat je de agent op de pipeline loslaat.
- CI-secrets breed beschikbaar in de pipeline-omgeving. Behandel de CI-runner als semi-vijandig terrein. Scope tokens per stap; geef alleen wat die stap nodig heeft.
Voor een willekeurige productiewijziging kun je binnen twee minuten de keten tonen: taak · branch · commits · PR met review · groene CI-run · gepromoveerd artifact · deployment.
Stap 5 · Bouw vertrouwen gecontroleerd op
De techniek staat nu. Stap 5 gaat over tempo. Autonomie groeien in bewezen stappen, en net zo makkelijk terugschalen als opschalen, dat is de kern van beheersbaarheid.
De grootste fout op dit punt is de verleiding om de goede week te extrapoleren naar permanent vertrouwen. Betrouwbaarheid toont zich pas onder herhaling, variatie en minder bekende taken. Bouw systematisch op, niet op gevoel.
Het groeipad:
- Eén taak, dan stoppen. Inspecteer alles: de code, statusupdates, het bewijs, de kwaliteit van de PR-beschrijving. Pas als alles klopt, ga je verder.
- Enkele taken naar Review. Is taak vijf net zo zorgvuldig als taak één? Consistentie onder volume is het eerste echte signaal.
- Een geschikte To Do-swimlane. Markeer expliciet welke taken agent-geschikt zijn. De agent kiest alleen daaruit; de rest blijft voorbehouden aan mensen.
- Pas daarna: unattended runs en orchestratie (stap 6 en verder in de volgende iteraties).
- Bij regressies: terugschalen. Bevoegdheden of scope tijdelijk verkleinen is geen falen, maar de kern van beheersbaarheid. Bouw het opnieuw op vanuit de data.
Meet het. Definieer vooraf wat “aantoonbaar betrouwbaar” betekent in jouw context:
| Metric | Wat het meet | Drempelwaarde (voorbeeld) |
|---|---|---|
| PR zonder rework door review | Kwaliteit van de eerste oplevering | > 80% na tien taken |
| CI-iteraties per taak | Zelfherstelvermogen en testvolwassenheid | Gemiddeld < 2 |
| Escalaties in plaats van gokken | Judgment: weet de agent wanneer hij moet stoppen? | 0 ongemelde gissingen |
| Statusupdates compleet en tijdig | Traceerbaarheid van het proces | 100% bij statusovergang |
Verhoog autonomie op basis van die cijfers, niet op basis van een goede week.
Autonomie is een verdiende operationele eigenschap, geen eenmalige instelling. Het niveau mag per project en per taaktype verschillen: dezelfde agent kan op het interne tool L5 draaien en op het klantkritische systeem L2.
Er ligt een kort, schriftelijk afsprakenkader: welke taaktypes op welk autonomieniveau draaien, welke metrics een verhoging rechtvaardigen, en wie bij een regressie terugschaalt.
Het hart van de methode
Stap 3, 4 en 5 zijn het hart van de methode. Ze bepalen of AI-werk zichtbaar, herhaalbaar en beheersbaar is.
- Zonder het taskboard weet niemand wat de agent doet.
- Zonder CI/CD is er geen bewijs dat het klopt.
- Zonder vertrouwensopbouw is er geen basis om te groeien.
Met de drie samen is de agent een volwaardig teamlid: traceerbaar, toetsbaar en stuurbaar. Niet omdat de technologie perfect is, maar omdat het proces de fouten opvangt en zichtbaar maakt voordat ze schade aanrichten.
Terug naar overzicht