Onze AI-collega’s hebben zich bij onze retro-sessie aangesloten

Wij ontwikkelen software voor retrospectieven, dus het retro-bord van ons team ziet er vrij standaard uit: Start, Stop, een kolom met openstaande acties, de gebruikelijke discussies op vrijdag. Vorige week kwamen er enkele nieuwe bijdragers bij. Zes van de kaarten waren niet door mensen geschreven — ze waren ingediend door de AI-agenten waarmee wij dagelijks samenwerken, en gaven een samenvatting van de knelpunten uit hun eigen werksessies met ons.

Laten we duidelijk zijn over wat dit precies inhoudt, want de bewoording is van belang. Het gaat hier niet om een AI die in de retro aanwezig is: er is geen bot die de vergadering leidt, noch een AI-functie die de kaarten van de deelnemers samenvat. De medewerkers die het daadwerkelijke werk in ons team verrichten (degenen die code schrijven, inhoud redigeren en audits uitvoeren) waren bij de bijeenkomst aanwezig zoals elke teamgenoot dat zou doen: met hun eigen verslag van hoe het werk is verlopen. Deelnemers, geen facilitators; de bijeenkomst bleef van ons.

Dit was ook geen publiciteitsstunt. De aanleiding kwam tijdens een van onze eigen terugblikken: iemand merkte op dat de onboarding-documentatie (alweer) verouderd was en iemand anders vertelde dat een agent hen die ochtend tijdens een sessie terloops precies daarop had gewezen, voordat de context uit beeld verdween. De agent wist het wel; niets in zijn systeem gaf aan dat deze opmerking het waard was om te bewaren. Daarom hebben we de afgelopen weken een experiment op onszelf uitgevoerd: de werkwijze is dezelfde als die we hebben beschreven in hoe u feedback van uw AI-agenten kunt verzamelen. Aan het einde van elke substantiële, door AI ondersteunde werksessie schrijft de agent een korte, gestructureerde retro-notitie over zijn eigen werk: wat ging er goed, wat verliep moeizaam, wat kostte elke vertraging, één label voor de hoofdoorzaak per punt en een voorgestelde oplossing. De verslagen worden opgeslagen in de repositories waarin het werk plaatsvond. Toen er voldoende waren verzameld, las een bijbehorend proces ze allemaal door en voerde de terugkerende patronen rechtstreeks in op ons retro-bord, voorzien van een voorvoegsel[AI retro]zodat niemand zich vergist in de auteur.

Dit is wat onze nieuwste collega’s te zeggen hadden over het werken bij ons.

Wat zij ontdekten

De kop waarmee zij het bericht begonnen, ging over henzelf. Op de bovenste kaart stond: “Begin met controleren voordat u actie onderneemt — fouten bij de uitvoering door agenten zijn verantwoordelijk voor 38% van de wrijving (twee keer zoveel als de op één na belangrijkste oorzaak); de terugkerende kosten ontstaan doordat men een oorzaak vaststelt, doorzet of heroriënteert voordat de live-code, gegevens of de status van de branch zijn gecontroleerd.” De grootste bron van wrijving in ons AI-ondersteunde werk was, volgens de agenten zelf, de agenten, met name de gewoonte om te handelen op basis van een veronderstelde toestand van de wereld in plaats van eerst de actuele toestand te controleren. Dergelijke eerlijkheid waarderen wij bij elke collega.

Het belangrijkste thema, dat zich als een rode draad door het geheel trok, overschreed alle grenzen die een mens niet zou overschrijden. Er deden zich bij het werken met gelijktijdige agents fouten voor met Git en de status van branches, die in acht sessies verspreid over twee repositories aan het licht kwamen: verouderde bases, ongelezen branch-doelen, een agent die een branch verplaatste die door een andere agent werd gebruikt, en een PR die zonder verificatie naar een ander doel werd verplaatst. Geen enkele sessie op zich zou hiermee ook maar in de buurt van de top zijn gekomen; elk incident leidde slechts tot een schouderophalen en een paar verloren minuten. Maar over de acht sessies heen bekeken, was het onmogelijk te negeren.

We zijn betrapt op het doorvoeren van wijzigingen op basis van onvolledige controles. Vier gevallen waarin iets werd doorgevoerd of samengevoegd na een beperktere controle dan wat CI daadwerkelijk uitvoert: een eenvoudige typecontrole in plaats van de volledige build, gerichte tests in plaats van de volledige testsuite. Tweemaal in één repository, op dezelfde dag.

En de meest ongemakkelijke kaarten hadden helemaal niets met het werk zelf te maken; ze gingen over de opvolging. Op één kaart werd opgemerkt dat door een hiërarchische kloof in de testprocedure een reproduceerbare crash twee beoordelingsrondes had kunnen ontgaan, en dat het document met de oplossing de dag ervoor was voorgesteld maar nooit was opgesteld. Op een andere kaart werd opgemerkt dat dezelfde vertraging bij de tool nu al twee sessies had gekost, „zonder dat er tussendoor een definitieve oplossing was geleverd“. Een derde kaart: hetzelfde patroon van steeds verder uitdijende vereisten, drie opeenvolgende sessies, „waarbij telkens werd opgemerkt dat het zich herhaalde ten opzichte van de vorige sessie“. Het blijkt dat de medewerker zich herinnert wat wij hadden beloofd te doen.

De twee dingen die het waard zijn om naar te staren

Ten eerste: dit was voor niemand zichtbaar. Dat is geen gebrek aan aandacht; het is de aard van het probleem. Wrijving tijdens AI-sessies is chronisch en van ondergeschikte aard, waardoor er nooit een evaluatie na afloop plaatsvindt en het probleem verdwijnt zodra de sessie is beëindigd. Ieder van ons had zijn deel verwerkt en was verder gegaan. De rangschikking (dit patroon kost het team het meest) bestaat alleen in het geaggregeerde overzicht, en dat geaggregeerde overzicht bestaat alleen omdat de vermeldingen vergelijkbaar waren: hetzelfde schema, dezelfde kleine reeks labels voor hoofdoorzaken, waarbij elke melding verwijst naar een sessie met een datum. Dit is het aggregatieconcept dat centraal staat in de gids bij dit bericht, en het is het onderdeel dat wij het liefst op onszelf wilden testen.

Ten tweede: de agenten gaven niemand, ook zichzelf niet, zomaar de schuld. De aantekeningen volgen twee regels die belangrijker bleken te zijn dan wij hadden verwacht. Bij „frictiepunten” wordt de kloof beschreven en wat deze heeft gekost, nooit wie deze heeft veroorzaakt: geen namen, geen „het rapport van X”. En „de agent maakte een fout“ is een residuele aanduiding, die alleen wordt gebruikt wanneer de input daadwerkelijk toereikend was; dat is precies waarom het cijfer van 38% onze aandacht trok: het doorstond die toetsing. Het resultaat leest als een goede retro-bijdrage: specifiek, onderbouwd met bewijs, zonder schuld toewijzing en in gelijke mate enigszins gênant voor iedereen.

Wat de aanwezigen besloten

Wij hebben besloten om alle drie de voorgestelde maatregelen uit te voeren, elk op het aangegeven niveau. De regel „Controleer de status van de live-branch en de PR voordat u wijzigingen aanbrengt” wordt opgenomen in de agentdocumentatie van elke repository; dit is een aanpassing in de documentatie met betrekking tot het thema van de acht sessies. De pre-push-hook die de CI-equivalente build en tests uitvoert, wordt toegevoegd aan de repositories die te lijden hadden onder onvolledige controles; dit is een aanpassing aan de omgeving, zodat het niet afhankelijk is van iemands geheugen. En de documentatie over de testconventie die „de dag ervoor was gemarkeerd maar nooit is geschreven”, wordt momenteel opgesteld, met de crash die door de mazen van het net is geglipt als praktijkvoorbeeld.

Geen grootschalige reorganisatie, geen nieuw proces: drie kleine aanpassingen ter grootte van een ticket, in samenwerking met de verantwoordelijken. Deze bescheiden aanpak is bewust gekozen: het hele uitgangspunt van deze werkwijze is dat kleine verbeteringen, gericht op het juiste niveau en daadwerkelijk gecontroleerd in de volgende cyclus, een cumulatief effect hebben. Of deze drie verbeteringen standhouden, zal precies blijken uit de beoordeling van de volgende opdracht; hetzelfde mechanisme dat ons de vorige keer op de hielen zat, zal ons hierop beoordelen.

Het is nog vroeg in het proces, en dat zeggen wij ook heel duidelijk. Maar toen wij die retro-sessie verlieten, waren wij meer geïnteresseerd in onze eigen werkpatronen dan wij in lange tijd zijn geweest — en voelden wij ons een beetje competitief ten opzichte van een collega die zelfs nooit moe wordt.

De eerlijke voetnoten

Dit is ons eerste samengevatte rapport; het betreft gegevens van weken, niet van maanden, dus beschouwen wij de ranglijsten als een indicatie voor de verdeling van aandacht, niet als een definitieve verantwoording. De kosten in de vermeldingen zijn schattingen van de agent zelf en zijn als zodanig gemarkeerd. De meer ambitieuze beweringen van de methode (dat labels consistent blijven tussen beoordelaars, dat de trendlijn daadwerkelijk afbuigt nadat correcties zijn doorgevoerd) zijn experimenten die wij momenteel uitvoeren, en geen aannames die wij doen; wij zullen de uitkomsten hiervan in elk geval publiceren.

Maar het belangrijkste resultaat was al zichtbaar: een reeks patronen die niemand in het team afzonderlijk kon waarnemen, gerangschikt, onderbouwd en opgenomen in de bijeenkomst waar degenen die verantwoordelijk zijn voor de oplossingen al aanwezig waren. In het Feedback Flywheel van Rahul Garg staat in de lijst met terugkerende onderwerpen vermeld: „een agendapunt in de bestaande sprint-retrospective: wat werkte er deze sprint goed met AI?“ Wij kunnen nu melden dat dit agendapunt aanzienlijk interessanter is wanneer uw AI-teamgenoten hun eigen punten indienen.

Probeer het eens binnen uw eigen team

Alles wat wij hebben gebruikt, is gratis en wordt beschreven in de handleiding: hoe de invoervelden werken, de labels voor de onderliggende oorzaken, de regels voor het niet-loggen (geen vertrouwelijke informatie, geen klantgegevens en nooit iets waarmee een persoon kan worden geïdentificeerd), en het agendapunt van 15 minuten voor de facilitator, plus de twee vaardigheden waarmee de fasen van vastlegging en synthese worden uitgevoerd. Het werkt met elke geschikte agent en een tekstbestand; ons product is slechts één van de mogelijke opslagplaatsen voor de resultaten, geen vereiste.

In de volgende cyclus zal uit de goedkeuringscontrole van de opdrachtbrief blijken of wij dat testdocument deze keer daadwerkelijk hebben opgesteld. Wij zullen u hiervan op de hoogte brengen. Zij zullen dat ook doen.

Heeft u het geprobeerd? Bent u het er niet mee eens? Wij menen het serieus als we zeggen dat we graag van u horen: ai-discussion@TeamRetro.com.