Legacy & AI: Tijdreizen in je Terminal
Sinds de hype van grote taalmodellen is losgebarsten, zullen de meeste ontwikkelaars ondertussen al wel geproefd hebben van de productiviteitswinst die deze tools, mits correct gebruik, kunnen bieden. In deze blog onderzoeken we of we verder kunnen gaan dan dat: biedt AI ook voldoende hulp bij het beheersen van Legacy Code?
Het inzetten van Large Language Models (LLM) bij het programmeren is inderdaad ondertussen stilaan goed gekend: het gaat van vragen stellen aan een chatbot (“hoe schrijf ik in Java een algoritme dat … “), overheen steeds slimmere en langer wordende code completion (automatisch aanvullen wat je wil typen in de editor), tot volledige vibe coding (in de IDE, of zelfs gewoon in een terminal): AI agenten, via prompts, hele stukken code – ja, zelfs werkende toepassingen – laten schrijven op je machine.
Deze manier van werken beschreven we reeds in een vorige blogpost, en de caveats, zaken waarop men moet letten, gelden nog steeds: blijf continu opvolgen, stel zaken in vraag, controleer, en geef de juiste hoeveelheid nuttige context mee aan het AI (een kunst op zich). Voor het behandelen van legacy code, stellen er zich echter nog een aantal verdere problemen:
- Het is geen nieuwbouw (of greenfield): er is erg veel impact van – vaak obscure – beslissingen uit het verleden.
- In veel gevallen is er reeds een massa code aanwezig.
- Vaak vraagt het com- pileren, uitvoeren en testen van de code specifieke technologie, die zelf verouderd is en soms moeilijk te in-stalleren of simuleren.
- Je bent als mens vaak niet meer onderwezen in het hoe en waarom van de bestaande codebase, waardoor het moeilijker wordt de resultaten van het AI kritisch te be-oordelen.
Vibe Coding: Een aantal Tips
Deze eenvoudige truukjes ondervonden we reeds bij ons werk rond Legacy Code & AI, maar zijn breder toepasbaar naar alle Vibe Coding projecten.
- Grote Schoonmaak: vóór je een AI loslaat op een codebase, moet je ervoor zorgen dat er geen privégegevens, paswoorden, of andere gevoelige informatie in te vinden zijn!
- Planning: vraag om opties en stel executie uit. Als je zelf bedreven bent in wat je wil doen, heb je vast en zeker al een idee van waar je precies naartoe wilt. Het kan echter soms lonen om je gesprek met het AI heel open van geest te beginnen en te vragen naar ideeën en opties (b.v. qua architectuur of gebruikte technologie) om je algemene visie te bewaarlijken (waarbij je het soms overijverige AI ook duidelijk maakt dat er alleen nog maar wordt gepland). Vraag specifiek naar meerdere suggesties! Dit kan helpen bij het brainstormen, en om je eigen ideeën aan te vullen met meer inspiratie. In het vervolg van het geprek ga je dan dieper in op de opties die je het meeste aanstaan, en dan pas vul je aan met je eigen expertise om de ideeën van het AI bij te sturen, tot er een concreet plan van actie is ontstaan dat zo optimaal mogelijk is. Pas daarna gaan we over tot effectieve implementatie.
- Indirectie en Tools. Zeker als je via een CLI (Command Line Interface) werkt, zijn zowel jij als het AI zich niet meteen bewust van alle mogelijke reeds bestaande tools die zouden kunnen worden geëxploiteerd om je doelen te bereiken. Laat het AI zoeken naar tools die zouden kunnen helpen, en helpen bij de installatie ervan. Hoe meer zaken je via tools kan doen, hoe minder de context wordt vervuild met nodeloos “manueel” werk door het AI zelf (om nog maar te zwijgen van de besparing qua token gebruik). Zo bestaan er b.v. allerlei static code analysis tools die je kan gebruiken om de kwaliteit van je geschreven code te evalueren en hoog te houden. Het is vaak een koud kunstje voor het AI om heel wat van de gegeven suggesties na de analyse uit te voeren.
- Expert Mode: soms volstaan standaard tools niet om het AI voldoende te helpen bij wat je wil dat het doet. In dat geval kan je het AI eerst diens eigen tools laten schrijven. Daar kan je erbij voor zorgen dat het resultaat, of de output van de tool, iets is wat kort en samenvattend is voor de verdere taken, om de context niet teveel te belasten. Context windows van LLMs worden weliswaar steeds groter, maar dan nog moet je ervoor zorgen dat enkel de nuttigste zaken erin zitten (pas op voor context rot).
In een vorige post rond legacy code, gaven we een erg brede definitie. Laten we dus vooreerst iets duidelijker stellen wat we met Legacy bedoelen, en de “moei- lijkheidsgraad” van Legacy projecten beter illustreren.
“Oude” code: een spectrum aan mogelijkheden
Er is niet echt een officiële definitie van legacy code; meestal spreekt men van het gebruik van niet langer ondersteunde technologie, moeilijk te onderhouden, of simpelweg “code die je van iemand anders erft”. Het gaat uiteraard altijd wel om code die nog in gebruik, en dus belangrijk is. Ironisch genoeg, zijn het vaak de meest kritische toepassingen, die al jaren meegaan en waar men al jaren “op vertrouwt”, maar dan zonder ze goed te onderhouden.
AI kan ons helpen bij het onderhoud van eender welke code, dus we zullen een spectrum demonstreren dat van de oudste, ergste legacy code gaat, tot code van projecten die slechts een kleine update nodig heeft. Aan de ene kant van het spectrum heb je programma’s, geschreven in ouderwetse programmeertalen, volgens een achterhaalde architectuur, gebruik makend van databases die niet meer van deze tijd zijn, en draaiende op servers met niet langer ondersteunde besturingssystemen: bij deze mastodonten moet men vaak bang zijn dat ze kritisch zullen falen bij de kleinste verkeerde wijziging. Helemaal aan de andere kant heb je vrij goed onderhouden software, waarin een softwarebibliotheek wordt gebruikt die niet meer de meest recente versie is: meestal een koud kunstje om ze weer helemaal up-to-date te krijgen. Ergens in het midden vind je, ten slotte, toepassingen terug waarbij de meeste developers nog niet meteen het woord Legacy in de mond zullen nemen, maar waar wel moeilijke migraties dienen te gebeuren, met b.v. een verouderd framework of twee dat zou moeten worden vervangen.
Wat kunnen we hier nu mee? Bieden LLMs ons andere mogelijkheden naargelang de plaats van het project op dit spectrum? Ons onderzoek heeft zich tot nu toe op de linkerkant van dit spectrum gefocust, dus het vervolg van deze blogpost zal veeleer over de mogelijkheden gaan om “échte” Legacy aan te pakken. Later dit jaar gaan we ook verder uitdiepen wat we met migraties en updates kunnen doen.
Gebruik van LLMs op Legacy Codebases
Het is duidelijk dat de eenvoudige prompt “herschrijf mij dit programma volgens moderne standaarden” niet zal werken (al beweren sommige vendors dat dit eraan zit te komen). We zullen iets concretere zaken gaan vragen, en het werk ook enigszins in stukjes moeten kappen. Verder zijn er eigenlijk twee zaken die we kunnen gaan doen met onze legacy code: ze herschrijven en ze documenteren.
Herschrijven van Legacy Code
Als we beginnen met code herschrijven, zullen we er vaak rekening mee moeten houden dat een heel groot project voldoende goed herbouwen een te moeilijke opgave is. We kunnen “quick wins” behalen door strategisch een aantal zaken te gaan herschrijven van een project, en die stukken dan te gebruiken in een ruimere context, waarbij een team van mensen en AI de toepassing opnieuw bouwen volgens de regels van de kunst. Bij onze experimenten stelden we vast dat het een brug te ver was om van het AI te verwachten een volledig nieuwe architectuur te gebruiken, tegelijk met het vertalen van oude code naar nieuwe. Wat wel mogelijk is, is om heel wat van de typische scaffolding van een nieuw project te vibe coden, en daar dan gericht een aantal stukken code in te injecteren die vertalingen zijn van stukjes van een legacy project. Als mens is het onze taak om duidelijk aan te geven welke architectuur we verwachten, en wat de kwaliteitsregels zijn van de nieuw geschreven code.
Eén van de grotere uitdagingen bij het herschrijven van code met behulp van AI, is het testen van de correctheid van de vertaling: doet de code nog wat ze vroeger deed (los van het feit of dit wenselijk is, want zelfs de business case kan soms te verouderd zijn in geval van Legacy)? Bij redelijk nieuwe projecten zullen er reeds heel wat testen bestaan die we kunnen uitvoeren om de correctheid na te gaan, maar bij legacy hebben we vaak het probleem dat de toepassing eenvoudigweg wordt getest in productie, of op zijn minst met productiedata: er zijn geen specifieke tests of zelfs maar veilig bruikbare testdata. In dat geval komt het erop neer een omgeving te creëren waarin we de nieuwe code op een veilige manier kunnen testen, wat meestal ad hoc werk is en enige creativiteit vraagt. We mogen namelijk geen productiedata naar de Cloud sturen, dus we moeten ervoor zorgen dat het LLM deze niet kan lezen. Het zou eenvoudiger zijn als we lokaal draaiende LLMs zouden kunnen gebruiken, maar voorlopig zijn deze nog niet krachtig genoeg (als ze al beschikbaar zijn) om dergelijke complexe taken uit te voeren met legacy code.
Een andere uitdaging is de gebruikersinterface: bij oudere projecten is deze vaak achterhaald en moet er, vanaf de grond, een nieuwe GUI (Graphical User Interface) worden opgebouwd. Dat geeft echter het probleem dat je geen basis meer hebt in het oude project om mee te vergelijken: de nieuwe interface zal doorgaans manueel door mensen moeten worden getest. Ik verwacht echter dat we op dit vlak nog vorderingen zullen zien in de nabije toekomst, wat de mogelijkheden van het AI betreft. We zien namelijk al systemen opduiken die je volledige computer kunnen besturen (zoals OpenClawd of het “Computer Use” van Anthropic), en ook integratie met meer traditionele raamwerken voor het testen van een GUI behoort tot de mogelijkheden.
Waar we, ten slotte, ook quick wins mee kunnen halen, zijn kleinere Legacy projecten. Als we een klein tot matig groot legacy programma gebruiken, met bepertke functionaliteit en een eenvoudige GUI of een duidelijke input en output in geval van batch processing, en geen business case om deze te integreren in een andere manier van werken, dan kunnen we een rechttoe rechtaan aanpak proberen om een moderne versie in een nieuwe programmeertaal te bouwen met AI. We moeten dan nog altijd goed testen en een gestructureerde aanpak hebben met bijsturingen door menselijke developers, maar het wordt wel feasible om dit voor niet-kritische toepassingen te gaan uitproberen. Een intern gebruikte toepassing is bijvoorbeeld een typische goede eerste kandidaat.
Documenteren van Legacy Code
Soms is herschrijven van Legacy met AI net iets te ambitieus, óf we hebben meer informatie nodig voor we er ons aan wagen. In dat geval kan het interessant zijn om eerst richting documentatie te kijken: het AI kan ons ook helpen om het verkennen van een legacy codebase net iets minder op archeologie voor gevorderden te doen lijken.
Van een klein tot matig stuk code uitleggen en er de business logica uithalen, of een groter stuk analyseren en de opbouw en architectuur uitleggen: dat kan met de huidige grote taalmodellen zonder meer. We kunnen echter verder gaan: we kunnen het AI tools laten bouwen om zichzelf te helpen de codebase te verkennen, en b.v. diagrammen te voorzien van de afhankelijkheden tussen de stukken code. Of we kunnen het scripts laten maken om de bevindingen na elk stuk analyse netjes te structureren in een tekstbestand voor zichzelf en een pdf voor de menselijke gebruiker.
We kunnen ook hiërarchisch werken: eerst een verkenning van de codebase doen, en dan telkens dieper duiken in de verschillende modules, om meer en meer detail te verkrijgen en de analyse aan te vullen. Dat is de top-down aanpak, die we echter kunnen aanvullen met een bottom-up versie: eens we tot in de diepte zijn gegaan, kunnen we weer zaken laten samenvatten om van het grotere plaatje een beter geïnformeerde uiteenzetting op te bouwen.
Hier is het wel van belang dat we van tevoren weten wat we precies willen bereiken. Een algemene analyse van een codebase door het AI kan interessant zijn wanneer de menselijke gebruikers het systeem nog totaal niet kennen en aanknopingspunten willen hebben om zaken te leren, maar biedt meestal weinig extra aan mensen die de codebase reeds beheersen.
Maar wanneer het doel is om de codebase te kunnen onderhouden, kunnen we eventueel een systeem opbouwen waarbij we een chatbot aanbieden die de specifieke context en bijzonderheden van het legacy project kent, en daar heel gerichte vragen over kan beantwoorden. Dit kan b.v. in CoPilot Studio. Wanneer dat niet goed genoeg werkt, kunnen we nog overwegen om manueel een knowledge base op te bouwen, gebruik makend van het AI, die dan weer door het AI kan worden gebruikt om vragen te beantwoorden.
Nog een andere optie bestaat eruit dat we specifieke informatie uit de codebase willen extraheren, zoals de business logica per afzonderlijke module, of pseudocode die menselijke developers kan helpen om de logica in een ander project te herimplementeren. (En uiteraard kan bij die tweede stap ook weer een AI worden ingezet.)
Kortom, met een beetje creativiteit kunnen we voor de meeste ad hoc analyses een betere aanpak verzinnen dan “analyseer er maar gewoon op los”. En het documenteren van een legacy systeem kan ook gewoon een eerste opstap zijn naar het herschrijven.
Besluit: vakmannen gevraagd
Zoals we hebben aan-gekaart, bieden LLMs ons stilaan erg krachtige mogelijkheden om onze Legacy Codebases aan te pakken, zéker wanneer we toegang hebben tot de grote en krachtige modellen die vandaag beschikbaar zijn. We zien echter ook dat het eigenlijk een heel goed gevulde gereedschapskoffer is, met een aantal krachtige “power tools”, en dat we moeten weten wat we ermee willen bereiken en hoe we deze best kunnen gebruiken.
We zitten nog niet op het punt dat alles automatisch gaat: we zullen dus nog steeds goede vakmannen nodig hebben om optimaal van dit gereedschap gebruik te maken. Onze raad aan developers is om zeker niet bang te zijn van AI en er geregeld gebruik van te maken bij de analyse en ontwikkeling van software: ervaring is de beste leerschool om de goede vakmannen die we hiervoor nodig hebben, op te leiden.
Voorlopig is dus het besluit: voor legacy code is AI geen wondermiddel, maar een handige gereedschapskist die je best kan uitproberen als deel van een bredere aanpak. Zoals gezegd kijken we later dit jaar eerder naar het midden en de rechterkant van het spectrum van legacy. Wij vermoeden dat hier meer mogelijkheden zijn tot automatisering van een aantal workflows, zeker als we ook dieper gebruik gaan maken van agents. Mogelijks kunnen we, voor iets eenvoudigere en repetitievere projecten, dus toch van “vakman” naar “fabriek” evolueren.
