Elk team heeft een repo waar niemand meer in durft. Hij doet het nog. Niemand weet precies hoe.
Laatst vroeg een .NET-developer me of hij AI-agents kon inzetten om die van hen te documenteren. Ja, zei ik. Maar die vraag is groter dan hij klinkt.
Waarom is documentatie niet het echte doel?
Documentatie is het doel niet. Je wilt snappen wat een oude repo doet en waarom hij zo gebouwd is. Daar stranden veel migraties. Het schrijven van code is allang niet meer het knelpunt.
Hoe stuur je AI door vijftien jaar bedrijfslogica?
Met agentic coding stuur je AI gericht door vijftien jaar bedrijfslogica. Code, git-historie, het ticketsysteem. En dan komt de vraag die ertoe doet: is dit dode code, of mis ik iets?
De code zegt wat er gebeurt. Een commit uit 2017 zegt soms waarom. De mensen die het bedacht hebben, zijn al jaren geleden vertrokken. En in een oud bug-issue vindt een AI-agent ineens de reden voor een vaag if-statement.
AI-agents kunnen dit niet zonder hulp. Jouw oordeel blijft nodig, net als dat van developers en domeinexperts die aannames bevestigen of aanscherpen. Dat herstelde begrip wordt je nieuwe specificatie.
Waarom is verifiëren gevaarlijker dan de legacy zelf?
Onlangs migreerde ik een .NET Core 2.1-service naar .NET 10. De vraag was niet of AI-agents de code konden herschrijven. De vraag was: doet het nieuwe precies wat het oude deed?
De uitdaging zat bij Entity Framework. Oude modeldefinities, complexe foreign keys. Een moderne query-engine vertaalt zo'n legacy Include net even anders naar SQL, en dan krijg je ongemerkt ander data-gedrag. Code die er prima uitziet. Cijfers die stilletjes anders rekenen.
Dat vond ik het venijnige eraan. Genereren is goedkoop geworden, dus verifiëren is het belangrijkste werk. Het is dezelfde dynamiek die ik bij die ene package die je niet durft te updaten ook zie: de risico's zitten niet in het schrijven, maar in wat je niet ziet.
Een migratie die op het eerste gezicht klopt maar onder water iets anders doet, is gevaarlijker dan de legacy die je al had. Want nu vertrouw je het.
Hoe bewijs je dat het klopt?
Daarom laat ik agents niet alleen bouwen. Ze moeten ook helpen bewijzen dat het klopt. Bestaand gedrag reconstrueren, omzetten in teststappen en blijven aantonen dat de logica niet verandert.
Zo wordt het herstelde begrip uit de oude repo niet alleen je specificatie, maar ook je vangnet. Je migreert pas als je kunt laten zien dat oud en nieuw hetzelfde doen.
Hebben jullie zo'n repo waar niemand meer aan wil? Wat houdt je tegen om hem scherp te krijgen voor je hem aanraakt?
