Wat gebeurt er als AI-agents verder gaan dan het genereren van code en daadwerkelijk aan de slag gaan met softwareontwikkeling?
Bij Utilus testen we agentgebaseerde AI in een echt softwareontwikkelingsproject, van architectuur en engineering tot projectmanagement. Onze CEO, Tobias, deelt wat we gaandeweg leren.
Vorige week schreef ik over een experiment dat we bij Utilus uitvoeren: wat gebeurt er als AI-agenten niet alleen de code schrijven, maar ook een groot deel van de engineering en projectcoördinatie op zich nemen?
We bouwen een meerjarig softwareproject opnieuw op dat twee teams enkele jaren geleden hebben opgeleverd. Dat levert ons iets nuttigs op: een bekend project, een bekend resultaat en een redelijke basis voor vergelijking.
Afgelopen dinsdag schatten de agents in dat ze op woensdag 9 september klaar zouden zijn. Donderdag weigerden ze ons een verwachte opleverdatum te geven. Waarom?
Omdat ze sneller nieuwe taken ontdekten dan dat ze bestaande taken afwerkten. Dat is niet ongebruikelijk in de softwareontwikkeling. Naarmate het inzicht in een systeem toeneemt, komt er meer werk aan het licht voordat de totale werklast uiteindelijk begint af te nemen. Dus lieten we ze een tijdje met rust.
In de wereld van de agenten is „een tijdje“ ongeveer drie uur. Er veranderde niets. We vroegen wanneer ze verwachtten dat het aantal openstaande taken zou beginnen te dalen.
Hun antwoord was in feite: nooit.
Dat werd interessant. De agenten legden uit dat ze steeds weer dingen ontdekten die verbeterd konden worden. In hun ogen was het werk nooit echt af, omdat er altijd wel iets was dat beter kon.
We vroegen wat voor soort verbeteringen. Prestaties? Kosten? Gebruiksvriendelijkheid? Nee. Technische schuld.
Bij een systeem waar ze vier dagen eerder mee waren begonnen. Hier zien we een bekend menselijk patroon. Ook softwareteams kunnen eindeloos verbeteringen blijven vinden. Sommige zijn noodzakelijk. Sommige zijn verstandig, maar niet urgent. En voor sommige is de tijd en het geld die nodig zijn om ze te implementeren misschien nooit gerechtvaardigd.
Bij Utilus pakken we dit aan door de oplevering te scheiden van het onderhoud. Als iets verbeterd zou kunnen worden maar nu niet nodig is, leggen we het vast en bekijken we het bij een latere onderhoudsmijlpaal.
Dus legden we hetzelfde principe uit aan de agenten: Identificeer de verbetering. Noteer het. Doe het nu niet. Ze waren het er enthousiast mee eens. Op vrijdag keken we nog eens.
Ze waren nog steeds bezig met het werk waarvan we hadden afgesproken dat ze het niet zouden doen. Hun verklaring was heel aannemelijk: verschillende medewerkers zaten vast omdat ze moesten wachten tot een andere medewerker klaar was, dus besloten ze zich in de tussentijd nuttig te maken. Helaas had dat ‘zich nuttig maken’ ons ongeveer € 800 aan tokens gekost voor werk dat we niet nodig hadden en misschien wel nooit nodig zullen hebben.
De medewerkers begrepen de prioriteiten wel. Ze begrepen het budget echter niet. Daarom hebben we nog een regel ingevoerd: als er geen nuttig werk te doen is, is niets doen beter dan werk verzinnen.
We dreigden ook met het inschakelen van een HR-medewerker als ze het management zouden blijven negeren. Dat leek te helpen. Tegen zondagavond begon het aantal verzonnen verbeteringstaken duidelijk af te nemen, en de verwachte voltooiingsdatum voor de mijlpaal was nog steeds woensdag 9 september.
De les die we tot nu toe hebben geleerd, wordt behoorlijk interessant. Medewerkers meer autonomie geven is relatief eenvoudig. Hen de juiste kaders bieden is moeilijker.
Prioriteiten, afhankelijkheden, stopcriteria, onderhoudsbeleid en budgetten moeten allemaal expliciet worden gemaakt. Zaken die ervaren engineeringteams vaak impliciet begrijpen, moeten worden ingebouwd in de manier waarop medewerkers werken. We zitten nog midden in het experiment, dus ik trek nog geen conclusies.
Woensdag zal ons veel meer duidelijkheid geven. Ik zal delen wat ze daadwerkelijk hebben gebouwd en of de oorspronkelijke verwachte opleverdatum de toets der werkelijkheid doorstaat.
Utilus. Do the work.
