Hoe u feedback kunt verzamelen van uw AI-agenten

Een AI-agent heeft deze week code voor u geleverd. Hij heeft uw opdracht gelezen, de codebase doorzocht, liep vast op een punt waar de documentatie onjuist was, heeft zich daar op goed geluk doorheen gewerkt en is verder gegaan. Toen eindigde de sessie — en alles wat hij had geleerd over de knelpunten in uw project ging daarmee verloren. Niemand heeft de enige deelnemer die zojuist een uur in uw repository heeft doorgebracht, gevraagd wat de vertraging veroorzaakte.

Retrospectieven zijn er juist om die kloof voor mensen te dichten: het team komt bijeen, brengt in kaart wat heeft geholpen en wat in de weg stond, en zet dit om in verandering. AI-agenten verrichten nu daadwerkelijk werk binnen uw team — en zij stuiten op dezelfde weerstand als uw medewerkers, soms zelfs nog meer. De vraag is dus eenvoudig. Als een agent het werk van het team doet, waarom komt dit dan niet aan bod in de retrospectieve?

Deze handleiding gaat over het toevoegen van die stem. Het gaat niet om een nieuwe vorm van retrospective, noch om het automatiseren van de inbreng van uw medewerkers — het gaat om een nieuwe deelnemer. De AI levert feedback; uw team beslist nog steeds wat die feedback betekent. Hieronder leest u hoe u deze feedback kunt verzamelen en hoe u deze kunt integreren in de retrospective die u al houdt.

Waarom het de moeite waard is om de ervaringen van uw AI-agent vast te leggen

Het argument voor een menselijke terugblik is dat herinneringen vervagen en lessen niet worden gedeeld. Bij een AI-agent is het probleem nog acuter: zijn werkgeheugen vervaagt niet, maar verdampt. Zodra een sessie wordt afgesloten, is de context verdwenen. De ontbrekende README-bestand waarvan het wenste dat die er was, de omgevingsvariabele die niet was gedocumenteerd, de opdracht die op drie manieren had kunnen worden geïnterpreteerd — niets daarvan wordt meegenomen naar de volgende sessie, tenzij iemand het opschrijft.

En agenten verzamelen een specifiek, nuttig soort signaal. Gedurende een uur werk vallen agenten dingen op die een mens over het hoofd ziet, omdat een mens de context al in zijn hoofd heeft:

• Het onboarding-document waarin een bouwstap wordt beschreven die niet meer bestaat.
• De functie wordt op drie verschillende manieren aangeroepen, dus „volg het patroon” verwijst naar drie patronen.
• De opdracht waarin stond: „ruim de configuratie op”, zonder te vermelden welke configuratie precies, of hoe grondig dit moest gebeuren.
• De testsuite waarvoor een service moet draaien, maar waarvan nergens wordt aangegeven dat u deze moet starten.

Een menselijke ontwikkelaar stuit hier ook op, haalt zijn schouders op, zoekt een oplossing en dient zelden een melding in — de hinder ligt onder de drempel van „het waard om in de vergadering aan de orde te stellen“. Een agent zal, mits op de juiste manier gevraagd, elk probleem melden, met het bijbehorende bewijsmateriaal. Dat is de meerwaarde: niet dat de AI uw proces beter begrijpt, maar dat het een frisse blik biedt, zonder ego en zonder opgebouwde tolerantie voor de kleine ergernissen. Samenwerking tussen mens en AI werkt het beste wanneer beide partijen kunnen aangeven wat hen heeft vertraagd.

Eén belangrijke kanttekening voordat we verdergaan, omdat deze bepalend is voor alles wat hierna volgt. De AI is een deelnemer, nooit een begeleider of een beoordelaar. De AI levert bijdragen aan de retrospective, net zoals elke andere deelnemer dat doet. De AI leidt de vergadering niet, geeft uw team geen cijfers en beslist niet wat er moet worden aangepakt. Mensen lezen de feedback, toetsen deze op realiteitszin en kiezen wat ertoe doet. Zolang u die grens in acht neemt, blijft de werkwijze gezond; vervaagt u die grens, dan heeft u uw verbeteringsproces uit handen gegeven aan een hulpmiddel dat geen verantwoording kan afleggen voor het resultaat.

De training: een terugblik aan het einde van de sessie

Het mechanisme is met opzet klein gehouden. Aan het einde van een werksessie — een programmeertaak, een onderzoekstaken of een refactor — schrijft de agent één eerlijk retro-verslag naar een bestand in de repository waarin hij aan het werk was. Dit kost de agent minder dan een minuut. Een mens besteedt ongeveer evenveel tijd aan het controleren of alles klopt. Dat is de hele cyclus.

Een goed artikel bestaat uit vier delen:

1. Wat ging er goed — de momenten die het waard zijn om te onthouden, gekoppeld aan iets concreets dat tijdens de sessie is gebeurd. Geen lof, geen opvultekst. Als het niet naar een specifiek moment kan verwijzen, wordt het niet opgenomen.
2. Wrijvingspunten — situaties waarin het werk moeilijker werd dan nodig was. Elk wrijvingspunt wordt gekoppeld aan een van de tien vaste labels voor de onderliggende oorzaak (zie hieronder) en — dit is de regel die het nuttig maakt — eindigt met een „→ Oplossing:“ ter grootte van een ticket. Geen bevinding zonder oplossing.
3. Een ‘Doe dit eerst’-topoplossing — de enige aanpassing die het meest zou hebben geholpen. Eén punt, bovenaan geplaatst, zodat een drukke lezer die verder niets leest, toch het belangrijkste te zien krijgt.
4. Gedane veronderstellingen — elk punt waarop de agent een leemte heeft opgevuld met een veronderstelling. Deze zijn van onschatbare waarde. Een veronderstelling is een plek waar uw context dubbelzinnig was of ontbrak; de agent laat u precies zien waar hij een antwoord moest verzinnen.

Twee principes zorgen ervoor dat de bijdragen betrouwbaar blijven. Uitsluitend op feiten gebaseerde momenten — elk punt verwijst naar iets dat daadwerkelijk is gebeurd, zodat niemand algemeen advies te lezen krijgt. En de eerlijkheid geldt voor beide kanten: de agent geeft kritiek op het materiaal dat hem of haar is aangereikt en op zijn of haar eigen fouten. Een bijdrage die alleen de codebase de schuld geeft en nooit zegt: „Ik heb dit verkeerd geïnterpreteerd en twintig minuten verspild”, is niet eerlijk; deze werkwijze vereist beide.

De tien labels voor onderliggende oorzaken

Elk knelpunt krijgt precies één label. Een vaste, beperkte woordenschat zorgt ervoor dat een stapel losse klachten verandert in een patroon waarop u kunt inspelen: wanneer hetzelfde label in tien sessies terugkomt, weet u waar u uw volgende uur aan moet besteden. De tien labels omvatten de manieren waarop het echte werk wordt belemmerd.

Etiket	Wat dit betekent	Waar de oplossing doorgaans terechtkomt
ambiguous-instruction	De opdracht kon op meer dan één manier worden geïnterpreteerd.	De persoon die de opdracht opstelt
missing-context	De informatie die de medewerker nodig had, werd niet verstrekt.	De opdrachtomschrijving, of de gedeelde context
incorrect-context	De verstrekte informatie was onjuist of verouderd.	De opdrachtomschrijving, of de gedeelde context
missing-documentation	In de repo wordt iets niet vermeld dat daar wel in zou moeten staan.	De documenten / CLAUDE.md / AGENTS.md
incorrect-documentation	De documentatie is weliswaar beschikbaar, maar is onjuist of verouderd.	De documenten / CLAUDE.md / AGENTS.md
codebase-friction	De code zelf maakte de aanpassing lastig — een ingewikkelde structuur, zonder naadjes.	De codebase / de achterstand in technische schulden
missing-access-or-tool	Er waren geen inloggegevens, machtiging of hulpmiddel beschikbaar.	Operaties / platform / toegangscontrole
agent-error	De agent had het verkeerd begrepen — verkeerd geïnterpreteerd, een verkeerde afslag, verspilde moeite.	Het eigen verslag van de agent, eerlijk gezegd
changed-requirements	Het doel werd halverwege de sessie verplaatst.	Planning / omvangbeheer
environment-friction	De ontwikkelomgeving stelde ons voor uitdagingen — onbetrouwbare builds, trage installatie, defecte tools.	Ervaring van ontwikkelaars

Let erop hoe de labels de verantwoordelijkheid duidelijk verdelen. Sommige verwijzen naar u — ambiguous-instruction, missing-context. Sommige verwijzen naar het project — missing-documentation, codebase-friction, environment-friction. Enagent-error verwijst naar de uitvoerder. Die spreiding is juist de bedoeling: zo wordt voorkomen dat het logboek een lijst met klachten wordt, en wordt het een overzicht van waar verbetering nodig is, aan alle kanten.

Het logboek: gewone Markdown, in uw repository

Voor de vastleggingsstap hoeft er geen product te worden geïnstalleerd. De agent schrijft naardocs/ai-retros/entries/ als gewone Markdown, die samen met de code wordt vastgelegd. Dat is een bewuste keuze:

• Het bevindt zich daar waar het werk plaatsvond. De discussie vond plaats in deze repository; daar staat ook het verslag ervan. Iedereen die de Git-geschiedenis bekijkt, ziet de feedback direct naast de wijziging die aanleiding gaf tot die discussie.
• Het is diffbaar en grepbaar. Wilt u allemissing-documentationitems van de afgelopen maand? Dat is een grep. Wilt u zien of de frictie daalt nadat u de build hebt gerepareerd? Dat staat in de versiebeheer.
• Het is onafhankelijk van specifieke tools. Markdown in een map werkt met elke agent, elke editor en elk proces. Geen propriëtaire oplossingen, niets dat later gemigreerd moet worden.

Hier volgt een illustratief voorbeeld — dit is een verzonnen sessie om de opbouw te laten zien; het betreft geen echte pilootgegevens:

# Session retro — add rate limiting to the public API
Agent: Claude Code · 2026-07-13 · ~50 min

## Do this first
→ Fix: Document the Redis connection setup in CLAUDE.md — three of us
  will hit this same wall. (missing-documentation)

## What went well
- The `middleware/` folder has a clear pattern; the existing auth
  middleware was a clean model to copy for the rate limiter.
- Tests ran fast once the service was up.

## Friction
- Nothing documented that the test suite needs Redis running locally.
  Spent ~15 min chasing a connection error before finding it by reading
  docker-compose.yml. (missing-documentation)
  → Fix: Add a "Running tests locally" section to CLAUDE.md naming the
    Redis dependency and the `docker compose up redis` command.
- The brief said "add sensible rate limits" without numbers. I chose
  100 req/min per key. (ambiguous-instruction)
  → Fix: Decide the real limits with the team and put them in the ticket.
- `config/limits.ts` and `config/throttle.ts` both looked like the right
  home for the setting; I couldn't tell which was canonical. (codebase-friction)
  → Fix: Merge or clearly comment which config owns rate limiting.

## Guesses I made
- Assumed 100 req/min because the payment endpoints use that. May be
  wrong for read-heavy public endpoints — please check.
- Assumed rate-limit responses should be 429 with a Retry-After header.

Beschouw dit als een aantekening van een deelnemer, want dat is het ook. Het is concreet, het bevat eigen veronderstellingen en bij elke opgave hoort een volgende stap.

Dit in uw teamretrospective opnemen

De afzonderlijke inzendingen vormen het uitgangsmateriaal. Voorafgaand aan uw retro wordt in een begeleidende synthesestap de inzendingen sinds de vorige keer doorgenomen en wordt er een samenvatting van één pagina voor de vergadering opgesteld: de wrijvingen die zich herhaaldelijk voordoen, de belangrijkste oplossingen gegroepeerd per label, en de veronderstellingen die steeds weer op dezelfde plek terugkeren. Deze samenvatting voldoet aan dezelfde normen als de bijdragen zelf — geen lof of opvultekst, geen bevinding zonder oplossing — en de eerlijkheid geldt ook in omgekeerde richting: de samenvatting levert even gemakkelijk kritiek op de aangeleverde bijdragen (zwak bewijs, een oplossing die te vaag is om in praktijk te brengen) als dat zij deze samenvat.

En dan het menselijke aspect, dat niet verandert:

1. Lees de samenvatting vóór de evaluatie — beschouw deze als de voorbereidende informatie van nog een deelnemer, niet als de agenda.
2. Zet de bovenste één of twee punten op het bord, naast wat uw medewerkers hebben meegebracht. Nu staat de opmerking vanmissing-documentation de AI naast de opmerking van een teamgenoot „de inwerkperiode kostte me een week“ — en u kunt zien dat het om hetzelfde probleem gaat.
3. Bespreek en beslis als team. De agent heeft het punt aan de orde gesteld; de mensen in de zaal bepalen wat er vervolgens gebeurt. Sommige punten zult u in behandeling nemen, andere zult u opschorten, en weer andere zult u afwijzen. Dat is allemaal prima — zo levert een deelnemer een bijdrage, in plaats van dat een systeem iets oplegt.

Er zijn twee manieren om deze laatste stap af te ronden, en de eerste kost niets:

• Met elk retro-hulpmiddel. De opdracht is slechts een document. Lees deze vóór de vergadering door en voeg de belangrijkste punten toe aan het bord dat u gebruikt — inclusief plakbriefjes. De hele werkwijze verloopt op deze manier, van begin tot eind, zonder TeamRetro of enig ander specifiek product.
• Met TeamRetro plaatst de agent zelf berichten. Als uw team zijn retro’s in TeamRetro houdt, kan de agent zijn aanbevelingen opstellen op basis van het logboek en — na uw bevestiging per item — deze via de TeamRetro MCP-server plaatsen: uitgestelde punten die in de wachtrij staan voor uw volgende retro, acties wanneer een oplossing al een verantwoordelijke heeft, of ideeën die rechtstreeks op een running board worden bijgedragen. Elk geplaatst item krijgt het voorvoegsel [AI retro], zodat de groep kan zien welke deelnemer het naar voren heeft gebracht. Dat is het verschil in één zin: in plaats van dat u de feedback van de AI naar de vergadering brengt, dient de deelnemer deze zelf in.

Aan de slag in ongeveer 10 minuten

Het geheel is open source onder een MIT-licentie. De teamretro-skills-repo omvat beide trajecten:ai-session-retro (schrijft het bericht aan het einde van de sessie) enai-retro-brief (samenvat de berichten in de pre-retro-briefing) vereisen helemaal geen product, enteamretro-post-recommendations voegt het publicatietraject voor TeamRetro-teams toe. Een tool-onafhankelijk promptpakket maakt het geheel compleet.

Om te beginnen:

1. Kloon de repository en voeg de vaardigheden toe aan uw Claude Code-installatie, of kopieer het promptpakket als u met een ander programma werkt.
2. Gebruikt u Claude Code niet? Het promptpakket is zo opgesteld dat het werkt met Cursor, GitHub Copilot of elke andere agent waaraan u een systeemprompt kunt doorgeven — dezelfde vierdelige invoer, dezelfde tien labels, hetzelfde principe: „geen resultaat zonder oplossing“.
3. Voer één sessie uit terwijl het programma actief is. Lees aan het einde de notitie die het heeft opgeschreven. Bij die eerste lezing valt het meestal ineens op: de agent zal iets over uw project hebben benoemd waarvan u het wel vaag wist, maar nooit had opgeschreven.

Stel de vermeldingen in op eendocs/ai-retros/entries/map in de repository waarin uw agents werken, voer een commit uit, en u bent alvast op weg.

Eerlijke beperkingen

Dit is een jong kantoor dat vertrouwen wekt door openhartig te zijn over wat het niet kan.

• Een AI kan niet al haar eigen fouten zien. Sommigeagent-error problemen zijn onzichtbaar voor de agent die ze heeft veroorzaakt — zij weet niet wat zij niet weet. Menselijke controle is geen overbodige extra; het is de manier waarop de blinde vlekken worden opgespoord. Daarom blijft de AI een deelnemer en nooit de rechter.
• Eén vermelding is slechts een anekdote. U hebt ongeveer vijf vermeldingen nodig voordat de patronen betekenis krijgen. Een enkele storing tijdens een sessie kan gewoon pech zijn; vijf keer hetzelfde label is daarentegen een signaal. Wacht een paar weken voordat u al te veel conclusies trekt.
• De agent rapporteert zijn eigen ervaring, niet de feitelijke situatie. Als de agent aangeeft dat de documentatie onjuist is, controleer dit dan — soms is de documentatie wel correct en heeft de agent deze verkeerd geïnterpreteerd. Dat is nog steeds nuttige informatie (het betekent namelijk dat de documentatie gemakkelijk verkeerd kan worden geïnterpreteerd), maar de oplossing is een andere.
• Slechte opdrachten leiden tot slechte aantekeningen. Deze werkwijze brengt tegenstellingen aan het licht; ze creëert geen inzichten waar die er niet waren. Een sessie met een duidelijke opdracht en een overzichtelijke repository levert een korte, saaie aantekening op — en dat is precies de bedoeling.

Dat doet niets af aan de kern van de zaak. Uw AI-agenten voeren het werk al uit en lopen nu al tegen grenzen aan. De enige vraag is of u daar achter komt. Geef hen aan het einde van de sessie even de tijd om u dit te vertellen, bekijk de teruggekoppelde informatie met een menselijk oordeel en neem de eerlijke opmerkingen mee in de evaluatie die u toch al houdt — rechtstreeks naast uw medewerkers, waar de feedback van een deelnemer thuishoort.

---

Wilt u weten wat er gebeurde toen we dit met ons eigen team deden? Lees onze AI nam deel aan onze retro — dit is wat het ons vertelde. Bent u bezig met het opstellen van contextbestanden voor uw agenten? Ontdek waarom context engineering een feedbackloop nodig heeft. En als u nog helemaal niet bekend bent met het houden van retro’s, begin dan met hoe u een agile retrospective houdt.