Hoe u feedback kunt verzamelen van uw AI-agenten

Een AI-agent heeft deze week code voor u aangeleverd. 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 gewerkte 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 stuiten daarbij op dezelfde weerstanden 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 bepaalt 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.

Dit bericht dient als korte inleiding. Er is nu een volledige handleiding beschikbaar voor deze werkwijze, AI-agent-retrospectieven, waarin de volledige cyclus wordt behandeld, van het vastleggen van de gegevens tot de teamceremonie; begin hier en ga daarheen voor het volledige overzicht.

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 verdwijnt volledig. Zodra een sessie wordt afgesloten, is de context verdwenen. Niets daarvan wordt meegenomen naar de volgende sessie, tenzij iemand het opschrijft: de ontbrekende README waarvan het wenste dat die er was, de omgevingsvariabele die niet was gedocumenteerd, de opdrachtomschrijving die op drie manieren had kunnen worden geïnterpreteerd.

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

• Het onboarding-document waarin een bouwstap wordt beschreven die niet meer bestaat.
• Aangezien de functie door drie aanroepplaatsen op verschillende manieren wordt gebruikt, verwijst „volg het patroon” naar drie patronen.
• De opdracht waarin stond: „ruim de configuratie op”, zonder te vermelden welke configuratie precies, of hoe deze moest worden opgeruimd.
• 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, omdat de hinder onder de drempel ligt van „de moeite 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, want deze is bepalend voor alles wat hierna volgt. De AI is een deelnemer, nooit een begeleider of een beoordelaar. De AI levert input voor 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 aangepast. Mensen lezen de feedback, toetsen deze op redelijkheid en kiezen wat ertoe doet. Zolang u die grens in acht neemt, blijft de werkwijze gezond; vervaagt u deze, dan heeft u uw verbeteringsproces uit handen gegeven aan een hulpmiddel dat geen verantwoording kan afleggen voor het resultaat.

De sessie: een terugblik aan het einde van de sessie

Het mechanisme is met opzet eenvoudig gehouden. Aan het einde van een werksessie (een programmeertaak, een onderzoekstaak, een refactor) schrijft de agent één eerlijk retro-verslag in een bestand in de repository waaraan hij of zij heeft gewerkt. 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 goed ging: de momenten die het vermelden waard zijn, 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 is voorzien van een van de tien vaste labels voor de onderliggende oorzaak (zie hieronder) en eindigt met een „→ Oplossing:“ ter grootte van een ticket, de regel die het nuttig maakt. 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 drukbezette 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 uitgangspunten 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 uitsluitend 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, oftewel de gedeelde context
incorrect-context	De verstrekte informatie was onjuist of verouderd.	De opdrachtomschrijving, oftewel de gedeelde context
missing-documentation	In de repo wordt iets niet vermeld dat daar wel in zou moeten staan.	De documentatie / CLAUDE.md / AGENTS.md
incorrect-documentation	De documentatie is weliswaar beschikbaar, maar is onjuist of verouderd.	De documentatie / CLAUDE.md / AGENTS.md
work-material-friction	Het materiaal waaraan werd gewerkt, maakte de wijziging moeilijk (verwarde code, account of sjabloon).	De achterstand aan werkmateriaal / technische schuld
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 sloeg terug: onbetrouwbare builds, trage installatie, defecte tools.	Ervaring van ontwikkelaars

(Versie 2 van de vaardigheden is hernoemd codebase-frictionnaar work-material-friction; oudere vermeldingen met de oude benaming worden nog steeds als dezelfde categorie beschouwd.)

Let erop hoe de labels de verantwoordelijkheid duidelijk verdelen. Sommige verwijzen naar u: ambiguous-instruction, missing-context. Sommige verwijzen naar het project: missing-documentation, work-material-friction, environment-friction. En agent-errorverwijst naar de uitvoerder. Juist die spreiding is het punt: zo wordt voorkomen dat het logboek verandert in een lijst met klachten, 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 naar docs/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 heeft plaatsgevonden. 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 doorzoekbaar met grep. Wilt u alle missing-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 versiebeheeromgeving.
• Het is onafhankelijk van specifieke tools. Markdown in een map werkt met elke agent, elke editor en elk proces. Er is niets merkgebonden en er hoeft later niets te worden gemigreerd.

Hier volgt een voorbeeld ter illustratie. Dit is een fictieve 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. (work-material-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, bevat eigen veronderstellingen en bij elke opgave hoort een volgende stap.

Dit in uw teamretrospective meenemen

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 opgesteld voor de vergadering: de wrijvingen die zich herhaalden, de belangrijkste oplossingen gegroepeerd per label, de veronderstellingen die steeds weer op dezelfde plaats terugkeren. Hiervoor gelden dezelfde normen als voor de bijdragen (geen lof of opvultekst, geen bevinding zonder oplossing), en de eerlijkheid geldt ook in beide richtingen: het document levert even graag kritiek op de aangeleverde bijdragen (weinig onderbouwing, een oplossing die te vaag is om in praktijk te brengen) als dat het deze samenvat.

Vervolgens het menselijke aspect, dat niet verandert:

1. Lees de samenvatting vóór de evaluatie: beschouw deze als de voorbereidende lezing 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 opmerkingmissing-documentation van de AI naast de opmerking van een teamgenoot „de inwerkperiode kostte me een week”, en kunt u zien dat het om hetzelfde probleem gaat.
3. Bespreek en beslis als team. De medewerker heeft het punt aan de orde gesteld; de aanwezigen in de ruimte bepalen wat er vervolgens gebeurt. Sommige punten zult u in behandeling nemen, andere zult u opzij zetten, en bij weer andere zult u het oneens zijn. 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 gehele werkwijze verloopt op deze manier, van begin tot eind, zonder TeamRetro of enig ander specifiek product.
• Met TeamRetro plaatst de agent de berichten zelf. Indien uw team zijn retro’s in TeamRetro uitvoert, kan de agent zijn aanbevelingen opstellen op basis van het logboek en deze – na uw bevestiging per item – via de TeamRetro MCP-server plaatsen: items die in de wachtrij staan voor uw volgende retro, acties wanneer een oplossing al een verantwoordelijke heeft, of ideeën die rechtstreeks op het werkbord worden bijgedragen. Elk geplaatst item krijgt het voorvoegsel [AI retro], zodat de deelnemers in de ruimte kunnen zien welke deelnemer het naar voren heeft gebracht. Dat is het verschil in één regel: 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-repository omvat beide trajecten: ai-session-retro(schrijft het item aan het einde van de sessie) en ai-retro-brief(samenvat de items in de pre-retro-briefing) vereisen helemaal geen product, en teamretro-post-recommendationsvoegt 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-configuratie, of neem het promptpakket over 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 van „geen resultaten 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 u meestal ineens op: de agent zal iets over uw project hebben benoemd waarvan u het wel vaag wist, maar nooit had opgeschreven.

Wijst u de vermeldingen naar een docs/ai-retros/entries/map in de repository waarin uw agents werken, voert u 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 doen.

• Een AI kan niet al haar eigen fouten zien. Sommige agent-errorproblemen 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 werkelijkheid. Wanneer de agent aangeeft dat de documentatie onjuist is, dient u dit te controleren: 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 opdrachtbeschrijvingen leiden tot slechte aantekeningen. Deze werkwijze brengt wrijving aan het licht; zij creëert geen inzicht waar dat er niet was. Een sessie met een duidelijke opdrachtbeschrijving en een overzichtelijke repository levert een korte, saaie aantekening op, en dat is precies zoals het hoort.

Dat doet niets af aan de kern van de zaak. Uw AI-agenten voeren het werk nu al uit en stuiten nu al op beperkingen. 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 oprechte opmerkingen mee in de evaluatie die u toch al houdt. Dat is waar de feedback van een deelnemer thuishoort: direct naast uw medewerkers.

Wij hebben de hele ronde met ons eigen team afgelegd, inclusief de agenten. Bekijk wat er gebeurde toen onze AI-teamgenoten zich bij onze terugblik voegden.

---

Bent u bezig met het opstellen van contextbestanden voor uw agenten? Ontdek dan waarom context engineering een feedbacklus vereist. En mocht u nog helemaal niet bekend zijn met het houden van retrospectieven, begin dan met hoe u een agile retrospective houdt.