De AI-augmented Developer

Generatieve AI is dé hype van 2023. Elke dag zien verschillende nieuwe bedrijfjes het daglicht die een graantje proberen mee te pikken. De tekstgenerator GPT-3 kwam uit in 2020 en verzette de bakens wat betreft het behoud van onderwerp, thematiek en stijl, in aanzienlijke langere teksten. (Dat maakt ze nog niet waarheidsgetrouwer, maar dat is een andere discussie.) Sindsdien is het mogelijk om teksten te genereren over zowat elk onderwerp in zowat elke taal, die niet alleen syntactisch correct zijn, maar ook voldoende rekening houden met de bredere context. Een chatbotinterface daarbovenop, in de vorm van chatGPT eind 2022, schakelde alles nog enkele versnellingen hoger.

Software-ontwikkeling is bij uitstek tekst-intensief. Het gaat niet alleen over code schrijven in een bepaalde programmeertaal, maar eveneens over specificaties, documentatie, procesmanagement, testen, deployment, service level agreements, … Al deze onderdelen houden verband met elkaar en haken op elkaar in. Het feit dat Large Language Models (LLMs), zoals GPT-3 en haar opvolgers, complexere contexten kunnen hanteren, waaronder de verbanden tussen tekst en code, opent perspectieven voor de inzet van (tekstuele) generatieve AI in de software development cyclus. Zeker sinds Github CoPilot uitbracht, zien we ook hier in sneltempo nieuwe tools opduiken, die een kijkje waard zijn.

Achtergrond

De meeste code editors bevatten al decennialang goede hulpmiddelen, zoals voor de automatische detectie van syntaxfouten, syntax highlighting, en het automatisch aanvullen van kleine stukjes code. Externe plugins zoals linters kunnen een goede formattering en andere “best practices” aanmoedigen. Een goede compiler gaat proberen om niet alleen een directe syntaxfout te melden (“foutief beëindigd statement”), maar geeft idealiter ook suggesties over mogelijke remedies (“ben je misschien een puntkomma vergeten?”) – wat geen sinecure is. Zonder dat er absoluut AI moet schuilgaan achter al deze tools – met statische analyse en documentatiegeneratoren op basis van templates geraak je immers al een heel eind – is er dus al een lange geschiedenis die hieraan vooraf ging.

Tegelijk omvat AI ook heel wat meer dan het genereren van tekst en media. Ook AI heeft een lange geschiedenis, en de toepassing van AI-methodes op software engineering gaat minstens terug tot in de tijd van de expert systems, decennia geleden. In de meeste compilers en interpreters zitten allerlei optimizers die tot doel hebben de software efficiënter te doen draaien. Constraint optimization is een belangrijke tak van AI waarmee men o.a. problemen van timing, scheduling en logistiek tracht op te lossen – onmisbaar in besturingssystemen. En in faculteiten economie staat de inzet van AI al langer bekend onder de naam operations research.

De indrukwekkende kracht van recente LLMs doet velen hopen op een nieuwe productiviteitsboost in de Software Development Lifecycle (SDLC). Reden genoeg om eens te bekijken wat generatieve AI ertoe kan bijdragen. Houd daarbij wel in het achterhoofd dat er vandaag ook veel overhyped wordt, en dat sommige ideeën die vandaag de revue passeren, enkel bestaan als slideware – i.e. als mooie belofte op mooie slides. De grote consultancybureau’s zijn er alvast als de kippen bij, maar schrijven ook veel in algemene bewoordingen in de toekomstige tijd [1, 2, 3, 4]. Bij het effectief aanwenden van generatieve AI op de productievloer, komt immers heel wat meer kijken dan het omdraaien van een knop – o.a. qua governance en veiligheid zijn er wel wat vragen te stellen, wat ook de EU niet ontgaat.

Generatieve AI in de Software Development Lifecycle

Requirements analyse

Het inzamelen van alle vereisten en ze omzetten naar technische specificaties is een heel karwei, niet in het minst omdat er altijd heel wat impliciete vereisten opduiken, waar de eindgebruiker niet onmiddellijk aan denkt – van zeldzame uitzonderingssituaties tot dingen die zodanig evident lijken dat men er niet meer aan dacht. Hier schittert de business analist, wiens taak erin bestaat om de brug te slaan tussen eindgebruikers, klanten, en het development team. Daartoe heeft die een arsenaal aan middelen ter beschikking, waaronder use case modellering, customer journeys, mindmaps, storyboards, flowcharts, …

Generatieve AI-systemen kunnen mogelijk een nutige bijdrage leveren als er nieuwe scenario’s uitgedacht moeten worden, scripts verzonnen moeten worden, samenvattingen gemaakt moeten worden, of als er voortgeborduurd moet worden op bestaande teksten. Het is denkbaar dat er op die manier sneller gaten of inconsistenties in de requirements analyse verholpen kunnen worden. Vaak speelt standaard office software een grote rol in de uitwerking van een requirements analyse. De business analist zal dus zeker uitkijken naar het moment wanneer generatieve AI geïntegreerd zal worden in office software.

Planning & Design

Aan de tekentafel van de software architect, kan generatieve AI mogelijk bijdragen met voorstellen voor keuzes qua architectuur en design op basis van de ontvangen input. Dat gebeurt best wel bedachtzaam en bewust, want: wat met de accuraatheid? LLMs staan erom bekend dat ze kunnen hallucineren en onbestaande of onmogelijke teksten kunnen genereren. Bovendien zijn de huidige generatieve AI-systemen vaak geoptimaliseerd om de gebruiker te behagen en naar de mond praten, zonder dat ze begrijpen wat ze uitbraken – wat hen ook de bijnaam “stochastische papegaaien” heeft opgeleverd.

Image: “African grey parrot bird“/ CC0 1.0

Het spreekt voor zich dat al wat een software-architect ontwerpt, of wat een projectmanager inplant, in de praktijk ook mogelijk, haalbaar, consistent en inhoudelijk correct moet zijn. Projectmanagers en architecten moeten nog steeds zelf goed begrijpen waar ze mee bezig zijn, want dat aspect neemt een AI vooralsnog niet over. Validatie van de output blijft dus aan de orde, en dat kost tijd en middelen. Al te voortvarende inzet van generatieve AI kan bovendien ook negatieve impact hebben: het kan soms efficiënter zijn om zelf 1 idee manueel uit te werken, dan om 10 gegenereerde ideeën te moeten valideren, corrigeren en combineren.

Implementatie

Net als een tekst in een mensentaal, is de code van een programma ook een opeenvolging van letters en leestekens. Een LLM schrijft bijgevolg met evenveel gemak Java of Python als Engels, Nederlands of Chinees (tenminste, als er voldoende bestanden in die talen in de trainingsdatabase zaten). Github CoPilot is een versie van GPT-3 die geoptimaliseerd werd voor het schrijven van code en beschikbaar is als plugin in een IDE.

Het automatisch genereren van code op basis van natuurlijke taal is misschien de meest tot de verbeelding sprekende vernieuwing. Ontwikkelaars kunnen de gewenste functionaliteit in gewone taal beschrijven, waarna de AI een bijbehorend stuk code produceert. Dit kan het programmeerproces aanzienlijk versnellen, zorgen voor minder fouten en een betere adoptie van best practices – al zijn er ook kanttekeningen. Je loopt bijvoorbeeld risico om nieuwe fouten te introduceren, die bovendien moeilijker te debuggen zijn omdat ze in code staan die je niet zelf geschreven hebt. Het blijft ook hier van belang dat de programmeur met enige kennis van zaken de generatieve AI aanstuurt en de output ervan met een kritisch oog evalueert.

Daarnaast kan generatieve AI ook helpen bij het vinden van fouten in bestaande code. Door het analyseren van grote datasets met correcte en foute code, of vragen en antwoorden, kan de AI in staat zijn om patronen te herkennen die tot bugs of tot beveiligingsproblemen leiden. Met behulp van deze kennis kan het systeem suggesties doen om de fouten in de code te herstellen, of om snel een antwoord te bieden als er een foutmelding opduikt.

Generatieve AI kan alleszins de leercurve veel aangenamer maken voor een developer die moet leren werken met een nieuw systeem, een nieuwe software library, of een nieuwe programmeertaal. Met gerichte gegenereerde suggesties, kunnen developers sneller aan de slag met code in talen die ze nog niet helemaal beheersen, en moeten ze minder vaak zelf StackOverflow of andere resources uitpluizen. Uiteraard geldt ook hier: het is niet omdat je een rekenmachine mag gebruiken in de wiskundeles, dat je niet meer zelf moet kunnen rekenen.

Testing & QA

Testen is een cruciaal aspect van softwareontwikkeling. Als generatieve AI wordt ingezet bij de implementatie van software, neemt het belang ervan alleen maar toe. Gegenereerde code kan immers nog steeds fouten bevatten – ook subtielere, die gemakkelijk aan de aandacht ontsnappen. Een grondige teststrategie is dus eigenlijk een absolute voorwaarde, wil men generatieve AI inzetten bij software development.

Een manier waarop generatieve AI kan bijdragen aan het testen van software is door automatisch testcases te genereren op basis van de specificaties van de software. Zo zou men qua unit testing en code coverage sneller vooruitgang moeten kunnen maken. Ook hier is enige waakzaamheid wel nuttig. Zeker bij het gebruik van een LLM kan het immers dat een gegenereerde testcase nog enige verbetering behoeft.

Bepaalde manieren van testing zijn al sterk geautomatiseerd – denk aan Fuzzing of Mutation testing. Het is denkbaar dat AI daarbij ingezet kan worden voor het gerichter genereren of prioritiseren van nieuwe testcases. Op een meer high-level niveau, bijvoorbeeld wat betreft het verzinnen van scenario’s bij functionele testen of het maken van testscripts voor bepaalde testing frameworks, is generatieve AI alvast erg veelbelovend.

Deployment

(Een nieuwe versie van) software in productie stellen is niet evident en vergt soms lange pipelines van niet-triviale taken en complexe configuraties. De DevOps-methodologie die sterk inzet op de automatisatie daarvan, met CI/CD als centrale component, is ondertussen al goed ingeburgerd. Net zoals stukjes code gegenereerd kunnen worden op basis van een beschrijving in natuurlijke taal, kan hetzelfde worden verwacht voor het genereren van configuraties, deployment scripts, infrastructuurcode of container-orkestraties.

Onderhoud & Support

AI van de niet-generatieve soort wordt al regelmatig ingezet bij het voorspellen van storingen of het optimaliseren van onderhoud, bvb. op basis van de logs. Het genereren van code kan dan weer van nut zijn voor andere optimalisaties, zoals van de prestaties. Van code die niet performant genoeg is, kunnen immers vaak varianten worden gemaakt die sneller zijn – al gaat dat regelmatig gepaard met een hogere complexiteit en vermindering van de leesbaarheid van de code. Een generatieve AI kan mogelijk trucjes voorstellen die de developer nog niet kende: wist je al dat de snelste manier om een geheel getal te delen door 2, is om alle bits in het geheugen een plekje op te schuiven?

Een LLM die met code overweg kan is in principe zo algemeen dat ook andere vormen van optimalisatie mogelijk zijn. Wil je de code net veel leesbaarder maken? Of wil je een bepaalde library vervangen door een andere? Ook daarvoor kunnen suggesties worden voorgeschoteld.

Qua user support kunnen we onder andere denken aan het automatisch genereren van gepersonaliseerde antwoordmails op basis van een ticket in een ticketingsysteem, of de automatische escalatie van een ticket tot bij de juiste persoon. Als er daarbij weinig tolerantie is voor fouten, dan komt ook hier weer menselijke validering om de hoek kijken.

Documentatie & Kennismanagement

Als we code kunnen genereren uit een beschrijving in gewone taal, dan gaat het omgekeerde uiteraard ook: beschrijvingen genereren uit code. Dat is met name interessant wanneer je als developer geconfronteerd wordt met een ondergedocumenteerde codebase die je niet kent.

A quill held by a robot hand writing on infinitely long parchment, surrealist painting. Generated with DALL-E 2.

Maar ook zelf een duidelijke commentaar aanmaken van een stuk code dat je net hebt geschreven, ten behoeve van je collega’s en de toekomstige maintainers, is mogelijk. Niets verhindert je bovendien om die commentaar te laten genereren in de annotatiestijl van je favoriete documentatiegenerator – of waarom niet, in de stijl van Shakespeare.

[Image: A quill held by a robot hand writing on infinitely long parchment, surrealist painting. Generated with DALL-E 2.]

Conclusie

De vraag van 1 miljoen is: gaat het nu echt sneller? Hoeveel efficiënter kan een development team werken bij adoptie van deze tools? Het is erg moeilijk om een eenduidig antwoord te geven. De algemene teneur over Github CoPilot en gelijkaardige AI-assistenten, bij developers op sociale media en fora, is dat het aanzien wordt als een heel handig hulpmiddel met positieve impact op de productiviteit. Objectieve metingen zijn echter nog schaars. Een iets grootschaliger studie van Google (die weliswaar nog dateert van voor chatGPT en GPT-4), hield het op gemiddeld 6% kortere iteratietijden. Dat is wel wat, maar toch heel wat minder dan de “10x productiviteitswinst” die allerhande futuristen (of doemdenkers) graag orakelen.

In de achtergrond woeden ook nog talloze juridische debatten. O.a. over het copyright op gegenereerde code , het oneigenlijk webscrapen en benutten van code onder bepaalde (open source) licenties door de makers van generatieve AI, en het feit dat suggesties van een generatieve AI overeenkomsten kunnen vertonen met elders copyrighted code zonder dat de gebruiker dat beseft (en dat zo de gebruiker nietsvermoedend wordt voorgesteld om te plagiëren), is het laatste woord nog niet gezegd. Het zou ons te ver brengen om daar in dit artikel verder op in te gaan, maar we volgen die aspecten bij Smals Research ook nauwgezet op.

Software engineering blijft dus nog wel even mensenwerk. Generatieve AI heeft veel potentieel als hulpmiddel dat expertise kan ondersteunen én aanbrengen, en dat lange zoektochten naar een antwoord op specifieke vragen kan inkorten. Dat neemt niet weg dat kritische denkvaardigheden en een adequate teststrategie absoluut nodig blijven, en misschien nog belangrijker worden dan tevoren, om gegenereerde inhoud te valideren en te verifiëren.

P.S.

Voor dit artikel maakte ik, in beperkte mate, ook gebruik van chatGPT en de conversationele interface van Bing Search. Uiteraard werd alles grondig gevalideerd, en draagt de auteur nog steeds de volledige eindverantwoordelijkheid – zoals het hoort. Werd het daarom sneller geschreven? Nauwelijks. Ik heb slechts een fractie gebruikt van de teksten die deze systemen voor mij hebben gegenereerd, en het meeste daarvan dan nog sterk herschreven. Dat valideren, oppoetsen en bijschaven, blijft manueel en tijdrovend werk.

De teksten die deze systemen hebben aangebracht, bezorgden me wel een interessant algemeen overzicht, in die mate dat ik ook een kort woordje heb kunnen schrijven over aspecten van de software development lifecycle waar ik in eerste instantie niet aan gedacht had. Het gebruik van deze tools heeft dus wel geleid tot een evenwichtiger eindresultaat – maar, dat blijft een aanvoelen, en ook niet meer dan een anekdotische ervaring.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Leave a Reply

Your email address will not be published. Required fields are marked *