AI-ontwikkeling
Een nachtploeg van AI-agents: onderhoud dat doorloopt terwijl je slaapt
Elke nacht draait er een ploeg agents over twee codebases: dode code opruimen, tests aanvullen, vindbaarheid meten. Hoe dat is opgezet, en waarom het alleen veilig is met de juiste vangrails.
Onderhoud is het werk dat altijd wijkt voor iets urgenters. Dode code blijft staan. Tests blijven achter bij de functionaliteit. De vertaling van een nieuw scherm ontbreekt in drie van de vijf talen. Niemand kiest daarvoor — het is gewoon wat er gebeurt als er ook echte features gebouwd moeten worden.
Sinds een paar maanden draait dat werk bij ons ‘s nachts door. Een ploeg AI-agents pakt elke nacht één taak op, doet hem af, en levert het resultaat op als pull request. ’s Ochtends staat er een mail met wat er is gebeurd en wat er is misgegaan. Dit is hoe dat werkt en waarom we denken dat het veilig is.
De ploeg
Er zijn drie soorten agents, en het onderscheid is belangrijker dan de aantallen.
Onderhoudsagents draaien om de beurt. Elke nacht is er één aan de beurt: de dode-code-opruimer, de duplicatie-jager, de test-snoeier, de framework-optimalisator. Ze mogen code weghalen en herschrijven, maar ze mogen geen gedrag veranderen. Dat is de scheidslijn waar alles op rust.
Waakagents draaien elke nacht, buiten de beurtrol, omdat hun bron buiten de repo ligt. De belangrijkste meet elke ochtend Search Console en Bing Webmaster Tools voor de publieke sites, spoort regressies op en voert de verbetering zelf door.
Synchronisatie-agents houden dingen bij die uit elkaar lopen als je ze met rust laat: de vertalingen, en de kennisbank van de in-app assistent.
Daarnaast staat er één agent die wél gedrag mag veranderen: de bouwer die werk van het kanban-bord oppakt. Die mag dat alleen omdat een mens het ticket heeft goedgekeurd. Dat is geen technische maar een organisatorische vangrail, en het is de belangrijkste van allemaal.
De vangrails
Een agent die ‘s nachts alleen in je codebase staat, is precies zo veilig als de poorten eromheen. Deze vier doen het werk.
Een eigen worktree per agent
Elke agent krijgt zijn eigen git-worktree en zijn eigen branch. Twee agents kunnen dus niet in elkaars bestanden werken, en een mislukte ronde laat geen half werk achter in de hoofdcheckout. De worktree wordt na afloop weggegooid als er niets in is veranderd.
Poorten die niet te omzeilen zijn
Tests groen, typecheck groen, build groen. Bij het boekhoudproduct betekent dat bijna vierduizend tests, waarvan het grootste deel over geld en tenant-isolatie gaat. Een agent die daar doorheen wil, kan dat maar op één manier: door het echt goed te doen.
De verleiding om een falende test “even aan te passen” is bij een agent net zo groot als bij een mens onder tijdsdruk. Daarom is er een aparte controle die kijkt of de test zelf is gewijzigd in dezelfde ronde als de code die hij bewaakt. Dat is niet waterdicht, maar het maakt de makkelijke route dicht.
Eén taak per nacht
Geen agent doet twee dingen. Een ronde die één afgebakende wijziging oplevert, is te reviewen in vijf minuten; een ronde met zeven wijzigingen wordt niet gereviewd, hij wordt goedgekeurd. Dat verschil is het hele punt.
Automatisch samenvoegen mag alleen als main niet live is
Dit is de vangrail die we bijna verkeerd hadden. Bij het ene product publiceert een merge naar de hoofdbranch niets — de site gaat pas live bij een handmatige deploy. Daar mag de nachtploeg dus zelf samenvoegen: het ergste wat er kan gebeuren is dat er een wijziging klaarstaat die we ‘s ochtends terugdraaien.
Bij een product waar de hoofdbranch wél direct publiceert, mag dat niet. We hebben dat een tijd door elkaar gehaald omdat het configuratiebestand in de repo iets anders beweerde dan de hostingomgeving zelf. Sindsdien is de regel expliciet: automatisch samenvoegen is toegestaan zolang samenvoegen niet gelijkstaat aan publiceren.
Wat het oplevert
Het eerlijke antwoord: minder spectaculair dan het klinkt, en meer dan we hadden verwacht.
Wat het níét doet, is features bouwen. Dat mag ook niet en dat moet zo blijven.
Wat het wél doet, is de langzame verval tegenhouden. In een paar maanden: duizenden regels dode code weg, tientallen ontbrekende vertalingen aangevuld, tests toegevoegd op de plekken waar geld wordt gerekend, en een reeks kleine SEO-verbeteringen die we zelf nooit zouden hebben opgepakt omdat ze elk afzonderlijk te klein zijn om een avond aan te besteden.
Het waardevolste is misschien wel iets anders: de ochtendmail. Elke dag een korte samenvatting van wat er is gebeurd, wat er rood stond en wat er is blijven liggen. Dat is een dagelijkse gezondheidscheck op een codebase die je verder niet aankijkt, en die hadden we anders niet gehad.
Wat we anders zouden doen
Begin met één agent, niet met acht. De eerste twee weken kostte het repareren van de ploeg meer tijd dan de ploeg opleverde. Één agent met een goede poort is meer waard dan zes met een matige.
Laat de mislukking hard falen. De eerste versie ving fouten netjes op en ging door met de volgende agent. Het gevolg was een groene ochtendmail terwijl er drie rondes stilletjes niets hadden gedaan. Een ronde die faalt, hoort de mail rood te maken.
Reken op onderhoud aan het onderhoud. De ploeg is zelf software, met dezelfde neiging tot verval. Hij staat inmiddels onder dezelfde poorten als de rest.
Als je hier iets uit meeneemt, laat het dan dit zijn: het interessante aan agents die ‘s nachts draaien is niet dat ze goedkoop zijn. Het is dat ze werk doen dat anders helemaal niet gebeurt — en dat is een ander soort winst dan sneller doen wat je toch al deed.