Agentic engineering: software onderhouden met AI-agents

Een prototype kan overtuigen tijdens een demonstratie. Onderhoud stelt andere vragen. Wat gebeurt er met bestaande gegevens als je een functie verandert? Wie beslist over een uitzondering? En hoe merkt de volgende bouwer waarom iets zo gemaakt is?

Agentic engineering gebruik ik hier als werkbegrip voor gecontroleerd softwarewerk met AI-agents. De agent kan onderzoeken, aanpassen en testen. Mensen blijven verantwoordelijk voor de eisen, de afwegingen en het resultaat dat gebruikers krijgen.

Een agent voert meerdere stappen uit en gebruikt de uitkomst van een stap om verder te werken. Bij software kan hij bestaande code lezen, een fout onderzoeken, een wijziging aanbrengen en tests uitvoeren. Agentic engineering gaat over het organiseren en beoordelen van dat werk gedurende het leven van een applicatie.

Martin Fowler legt bij agentic engineering nadruk op mensen die verantwoordelijkheid blijven dragen voor code en gedrag. Dat is zijn duiding; het begrip heeft geen unieke officiële definitie. Voor dit artikel is de praktische vraag: kun je het werk van de agent begrijpen, controleren en later voortzetten?

Wie de basis nog wil opfrissen, kan beginnen bij onze uitleg over AI coding.

Stel dat een opleidingsbureau een deelnemersportaal heeft. De beheerder vraagt: 'Laat deelnemers hun inschrijving wijzigen.' Dat klinkt als één functie, maar verbergt besluiten. Mag een deelnemer ook naar een volle groep wisselen? Wat als een cursus al begonnen is? Blijft de oorspronkelijke keuze bewaard?

Werk eerst één regel uit: een deelnemer mag vóór de afgesproken sluitingstijd naar een beschikbare groep van dezelfde cursus wisselen. Bij onvoldoende plek blijft de bestaande inschrijving bestaan. De beheerder bepaalt de sluitingstijd en de uitzonderingsroute.

Nu heeft de agent een opdracht met observeerbaar gedrag. Hij hoeft geen bedrijfsbeleid te bedenken uit de namen van databasevelden. Een onbesliste regel komt terug als vraag in het werk, in plaats van stilzwijgend als code bij gebruikers terecht te komen.

De agent zoekt uit waar inschrijvingen worden opgeslagen, hoe een ingelogde deelnemer herkend wordt en waar de capaciteit van groepen wordt bepaald. Laat hem verwijzen naar de gevonden onderdelen. 'Er is vast al een functie voor' is nog geen bruikbaar onderzoeksresultaat.

Daarna beschrijft hij welke bestaande route kan worden uitgebreid en welke gevolgen dat heeft voor administratie en bevestigingen. Als een groep wijzigen ook een factuurcorrectie oproept, is dat relevante afhankelijkheid. Het hoeft niet allemaal meteen gebouwd te worden, maar de eigenaar moet het kunnen afwegen.

Dit onderzoek voorkomt een tweede inschrijfroute naast de eerste. Een app onderhouden betekent ook aansluiten bij keuzes die al bestaan. Een nieuwe bibliotheek is pas aan de orde als het bestaande gereedschap de concrete behoefte niet dekt.

Kies voor de eerste bouwronde één wissel tussen twee beschikbare groepen. Schrijf vooraf wat de controle moet vaststellen: de nieuwe groep staat geregistreerd, de oude plek komt vrij en de deelnemer ziet na opnieuw openen dezelfde uitkomst. Voeg ook een weigering toe bij een volle groep.

De agent mag tests voorstellen, maar de eis bepaalt wat een test moet bewijzen. Een test die alleen controleert of zijn nieuwe functie wordt aangeroepen, kan groen zijn terwijl de verkeerde groep wordt opgeslagen. Bekijk daarom de eindtoestand met herkenbare voorbeeldgegevens.

Anthropic onderscheidt bij agentevaluaties wat een agent zegt van wat werkelijk in de omgeving is gebeurd. Voor deze oefening is een bevestigingszin onvoldoende: de inschrijving moet daadwerkelijk naar de juiste groep verwijzen.

Bij een deelnemersportaal zit de waarde niet alleen in het nieuwe wisselknopje. De beheerder moet een fout kunnen herstellen, een medewerker moet de wijziging kunnen verklaren en de volgende bouwer moet weten welke regel is afgesproken. Dat hoort in dezelfde opdracht.

Vraag daarom een korte toelichting met de relevante bestanden, de gekozen gedragsregel en de uitgevoerde controles. Maak duidelijk wie eigenaar blijft van uitzonderingen. Een agent kan bijvoorbeeld melden dat een factuurgevolg nog buiten de opdracht valt; de eigenaar beslist vervolgens of de functie daarmee vrijgegeven kan worden.

Een bruikbare prompt helpt om dat resultaat te vragen. Onze gids over prompt engineering behandelt de formulering. Het blijvende onderhoud vraagt daarnaast bronkennis, controles en besluiten die buiten één chat bruikbaar blijven.

Voor de eerste wijziging kan de eigenaar het plan bekijken voordat de agent bouwt. Bij herhaald werk met duidelijke grenzen kan de agent meer zelfstandig onderzoeken en testen. De grens verschuift op basis van wat aantoonbaar werkt, niet omdat een eerdere demonstratie indruk maakte.

Een praktische afspraak is dat de agent stopt wanneer de opdracht een nieuw bedrijfsbesluit nodig heeft. Bijvoorbeeld wanneer twee deelnemers tegelijk de laatste plek proberen te nemen en het bestaande systeem daar geen regel voor heeft. Dat vraagt ontwerp van de wijziging als geheel, geen willekeurige keuze in één functie.

Anthropic adviseert in Building effective agents eenvoudige oplossingen als vertrekpunt. Ik zou daarom pas extra agentrollen toevoegen als één afgebakende werkwijze een aantoonbaar knelpunt heeft.

Een goede aanwijzing is dat je zonder de oorspronkelijke chat kunt vaststellen wat gevraagd was, welke wijziging is gemaakt en hoe die is beoordeeld. Ook een afgewezen voorstel kan goed werk zijn, zolang duidelijk is waarom het niet past. Het aantal gegenereerde regels vertelt daar weinig over.

Begin met een onderhoudstaak die je zelf inhoudelijk kunt beoordelen. Laat de agent eerst het bestaande gedrag uitleggen, leg één verbetering vast en beoordeel het resultaat op dezelfde criteria. In de cursus Claude Code voor gevorderden kun je die samenwerking verder uitwerken. Het doel is software waar je verantwoordelijkheid voor kunt nemen, ook wanneer de agent een groot deel van de uitvoering doet.