Je nieuwe collega drinkt geen koffie

Er is een collega bij gekomen in het team die nooit koffie drinkt. Hij staat dus ook nooit bij het apparaat als iemand vertelt dat die ene klant eigenlijk iets heel anders bedoelde, of dat we die feature vorige maand bewust hebben laten vallen. En als iets hem niet duidelijk is, vraagt hij niet door. Hij vult het gewoon zelf in, met een zekerheid waar ik als consultant af en toe jaloers op ben.

Die collega is een AI-coding-agent, en in steeds meer teams zit er een.

Deze week las ik Learn Harness Engineering, een open-source cursus van WalkingLabs over hoe je zo'n agent betrouwbaar laat werken. Hun stelling is dat het meestal niet aan het model ligt als een agent er in een echt project een zooitje van maakt. Het ligt aan wat eromheen staat: de harness. Ze onderbouwen dat met een experiment van Anthropic, waarin hetzelfde model met dezelfde opdracht zonder harness na twintig minuten iets opleverde dat niet werkte, en met harness na zes uur een spel dat je echt kon spelen.

Zo'n harness bestaat uit instructies, een bijgehouden voortgang, verificatie, afgebakende scope en een vaste manier om een werksessie te beginnen en af te sluiten. Hetzelfde woord wordt ook gebruikt voor het programma rond het model zelf, zoals Claude Code, maar die laag laat ik graag aan de engineers. Het gaat mij om wat je in je eigen project rond zo'n agent neerzet, en daar herkende ik bij elke les iets uit mijn eigen vak.

Wat de agent niet ziet, bestaat niet

Zo formuleert de cursus het eerste principe, en het is een prettig ongemakkelijke zin om op jezelf los te laten. Alles wat de agent moet weten, moet in de repository staan: het productdoel, voor wie het is, welke beslissingen we namen en wat we bewust laten liggen. Bij mijn eigen producten staat een flink deel daarvan nergens opgeschreven. Het zit in mijn hoofd, in een Slack-thread of in een gesprek bij de koffie. Voor mensen werkt dat vaak nog redelijk, voor de collega zonder koffie bestaat het simpelweg niet.

Hetzelfde zie je terug bij de feature list die de cursus gebruikt: een lijst met kleine stukken werk, elk met een status, waarvan de agent steeds het eerstvolgende onafgemaakte item oppakt. Dat is gewoon een Product Backlog die een machine kan lezen. De agent neemt de volgorde letterlijk, dus wie de backlog ordent, stuurt direct wat er gebouwd wordt.

Klaar is pas klaar als je het kunt laten zien

Verificatie is in de cursus streng geregeld: de agent mag pas zeggen dat iets af is als de tests slagen. Dat werkt alleen als de acceptatiecriteria toetsbaar zijn, en daar gaat het vaak mis. "Het moet gebruiksvriendelijk zijn" kan een agent niet controleren, dus vinkt hij het gewoon af. Een concreet voorbeeld van wat de gebruiker doet en wat er dan moet gebeuren, kan hij wel controleren. Een acceptatiecriterium is in die zin ook gebruikerservaring, alleen nu voor een agent.

Ook de andere regels zijn oude bekenden. Eén feature tegelijk, met een Definition of Done die er echt toe doet. Een logboek aan het eind van elke sessie met wat af is, wat nog niet bewezen is en waar de volgende sessie verder moet. Een agent die te veel tegelijk oppakt, doet precies wat teams doen die te veel tegelijk oppakken: overal aan beginnen en weinig afmaken. Hij doet het alleen sneller.

Wat mij vooral opviel, is hoe weinig hiervan nieuw is. Een team van mensen vangt vage stories op door even langs te lopen en het na te vragen. Een agent doet dat niet, en daardoor wordt zichtbaar wat wij als Product Owners lieten liggen omdat het team het toch wel oploste. Misschien is een goede harness vooral het werk dat we altijd al hadden moeten doen.

En toch blijft de koffie belangrijk

Er is één ding dat ik in de cursus mis. Een harness zorgt ervoor dat de agent betrouwbaar bouwt wat we vragen. Of we het juiste vragen, daar zegt hij niets over. Hoe beter de harness, hoe sneller je ook het verkeerde product oplevert.

Als bouwen goedkoper en sneller wordt, zit de moeilijkheid steeds meer in weten wat de moeite waard is om te bouwen. Discovery wordt daardoor belangrijker, en dat haal je niet uit een repository. We maken producten voor mensen, en als het goed is samen met mensen. Praten en luisteren, met gebruikers, met klanten en met het team, blijft dus minstens zo belangrijk als een goed geschreven feature list.

Schrijf het op voor de collega die geen koffie drinkt, en blijf zelf koffie drinken met de mensen voor wie je het maakt.

Welke beslissing over jouw product bestaat op dit moment alleen nog bij de koffieautomaat?