Gegenereerde code evalueren: Een praktisch raamwerk voor ontwikkelaars

De opkomst van AI-codeassistenten heeft het landschap van softwareontwikkeling onherroepelijk veranderd. Grote taalmodellen (LLM's) schrijven in seconden hele functies, klassen of zelfs complete modules. Maar deze snelheid brengt een cruciaal probleem met zich mee: hoe weten we of de gegenereerde code daadwerkelijk goed is? Het handmatig nalezen van AI-code schaalt niet, en vertrouwen op oppervlakkige signalen is een recept voor technische schuld. In dit artikel bespreken we een systematische aanpak om de kwaliteit van door AI gegenereerde code te evalueren.

De illusie van 'het compileert'

Een van de grootste valkuilen bij het beoordelen van AI-modellen voor codegeneratie is de aanname dat code die compileert (of zonder syntaxisfouten wordt geparst in geïnterpreteerde talen) ook correct is. LLM's zijn uitmuntend in syntaxis. Ze hebben miljarden regels correct opgemaakte Python, JavaScript en C++ gezien. Een model zal zelden een vergeten puntkomma of een verkeerd ingesprongen blok produceren.

Echter, syntactische correctheid garandeert geen semantische correctheid. Code kan perfect compileren, maar volkomen de plank mislaan wat betreft de bedrijfslogica. Het kan randgevallen (edge cases) negeren, oneindige lussen bevatten, of subtiele 'off-by-one' fouten introduceren. Als u een benchmark voor codegeneratie ontwerpt, mag "het bouwt zonder errors" nooit uw enige, of zelfs uw belangrijkste, metriek zijn.

Functionele correctheid: Meer dan de 'Happy Path'

De heilige graal van code-evaluatie is functionele correctheid: doet de code daadwerkelijk wat de prompt of de specificatie vroeg? Om dit te meten, moeten we verder kijken dan een visuele inspectie. We moeten de code uitvoeren tegen een reeks geautomatiseerde tests.

Wat is pass@k? (In gewone mensentaal)

Als u wetenschappelijke papers of benchmarks over AI-codering leest, komt u steevast de term pass@k (uitgesproken als "pass at k") tegen. Wat betekent dit concreet?

Omdat LLM's probabilistisch zijn, genereren ze niet altijd hetzelfde antwoord op dezelfde prompt. Als u een model vraagt om een sorteeralgoritme te schrijven, kan het de eerste keer falen, maar de tweede keer een perfecte oplossing bieden. Pass@k is een metriek die hiermee rekening houdt.

• pass@1: Het model krijgt exact één kans. Als de eerste gegenereerde code alle tests doorstaat, is het een 'pass'. Dit is de strengste en meest realistische weergave van de ervaring van een eindgebruiker in een IDE.
• pass@10: Het model mag 10 verschillende oplossingen genereren. Als ten minste één van die 10 oplossingen alle tests doorstaat, wordt het als een succes beschouwd.

Wanneer u modellen vergelijkt voor uw eigen taken, adviseer ik sterk om te focussen op pass@1. Ontwikkelaars hebben in de praktijk geen tijd om 10 verschillende AI-suggesties te testen en de juiste eruit te vissen. Wilt u hier een efficiënte balans in vinden? Lees dan meer over de afwegingen in ons artikel over kosten per taak berekenen.

Test-Driven Development (TDD) als evaluatie-engine

Om pass@k betrouwbaar te meten, heeft u een robuuste testsuite nodig. Dit betekent dat uw evaluatie-dataset moet bestaan uit drie componenten per taak:

1. Een duidelijke prompt (de opdracht).
2. Een verborgen implementatie (optioneel, als referentie).
3. Een set van unit tests met een hoge dekkingsgraad (coverage).

De gegenereerde code wordt in een geïsoleerde container geplaatst samen met de unit tests. Alleen als 100% van de tests slaagt, inclusief negatieve tests en edge cases, scoort het model een punt. Let hierbij wel op dat de tests zelf niet tot de trainingsdata van het model behoren. Meer over het opzetten van een schone testomgeving vindt u in onze gids over een testset zonder datalek opzetten.

Stijl, leesbaarheid en onderhoudbaarheid beoordelen

Functionele correctheid is de basis, maar code wordt vaker gelezen dan geschreven. AI-modellen hebben soms de neiging om nodeloos complexe of onconventionele code te produceren. Een goede evaluatie weegt daarom ook de kwaliteit van de code mee.

Statische analyse en 'Code Smells'

Voordat code door een mens wordt beoordeeld, kan een groot deel van de stijlevaluatie worden geautomatiseerd. Hulpmiddelen zoals SonarQube, ESLint of Pylint kunnen worden ingezet op de LLM-output om objectieve metrieken te verzamelen:

• Cyclomatische complexiteit: Maakt het model te veel geneste if/else-statements?
• Duplicatie: Herhaalt het model code in plaats van herbruikbare functies te schrijven?
• Naamgevingsconventies: Volgen de variabelen en functies logische patronen en het bedrijfsbrede stijlgids?

Veiligheidsrisico's spotten: De blinde vlek van AI

Het blindelings overnemen van AI-code is een enorm veiligheidsrisico. LLM's zijn getraind op enorme hoeveelheden code van het internet, inclusief miljoenen regels code die fundamenteel onveilig zijn. Als u niet expliciet evalueert op veiligheid, loopt u het risico bekende kwetsbaarheden in uw codebase te introduceren.

Veelvoorkomende LLM-kwetsbaarheden

Bij het evalueren van codegeneratoren moet u specifiek letten op de neiging van het model om de volgende fouten te maken:

• SQL-injecties: Gebruikt de AI ruwe strings voor databasequery's in plaats van geparameteriseerde queries (prepared statements)?
• Hardcoded geheimen: Plaatst de AI dummy-wachtwoorden, API-sleutels of cryptografische zouten direct in de code in plaats van omgevingsvariabelen aan te roepen?
• Gehallucineerde API's en pakketten: Dit is een uniek AI-risico. Soms verzint een model een handig lijkend open-source pakket dat helemaal niet bestaat. Een kwaadwillende actor kan ontdekken dat een LLM vaak een bepaalde nep-bibliotheek aanraadt, dit pakket daadwerkelijk publiceren met malware, en wachten tot ontwikkelaars het per ongeluk installeren (package hallucination squatting).

Zorg dat uw evaluatieraamwerk statische applicatiebeveiligingstesten (SAST) bevat die de output van de LLM scannen op veelvoorkomende OWASP Top 10-kwetsbaarheden. Voor een diepere duik in het actief provoceren van modellen om onveilige code te schrijven, kunt u ons stuk over red teaming en veiligheidstests raadplegen.

Een eigen evaluatieraamwerk bouwen in 5 stappen

Het vertrouwen op algemene benchmarks zoals HumanEval of MBPP (Mostly Basic Python Problems) is niet voldoende. Deze benchmarks bestaan uit generieke, algoritmische puzzels die niet reflecteren hoe u in uw bedrijf software bouwt. U heeft een bedrijfscontext nodig. Om verschillende AI-assistenten objectief voor uw eigen use-cases te vergelijken, volgt u deze stappen:

1. Definieer de baseline (Golden Dataset): Verzamel 50 tot 100 representatieve tickets of taken uit uw recente sprints. Isoleer de instructie (prompt) en verzamel de bijbehorende unit tests.
2. Integreer bedrijfscontext: Ontwikkelaars werken nooit in een vacuüm; ze gebruiken interne bibliotheken. Voeg documentatie van uw interne API's toe aan de prompt en kijk of de LLM deze correct weet te benutten. Kennis over hoe u de juiste context aanlevert, vindt u via onze uitgebreide gids over prompt engineering voor developers.
3. Bouw een sandboxed testomgeving: Voer gegenereerde code nooit uit op uw host-machine of productienetwerk. Gebruik geïsoleerde Docker-containers zonder netwerktoegang om de unit tests te draaien en de pass@k score te berekenen.
4. Automatiseer de code-inspectie: Koppel een linter en een SAST-tool aan de output-pijplijn om direct rapporten te genereren over de cyclomatische complexiteit en veiligheidsrisico's van de gegenereerde code.
5. Beoordeel en itereer: Verzamel de statistieken in een dashboard. Vergelijk het aantal geslaagde tests, de doorlooptijd, en de codekwaliteitsscores tussen verschillende modellen (bijv. GPT-4, Claude 3, of lokale modellen zoals CodeLlama).

Conclusie

Het evalueren van AI-codegeneratie vereist een verschuiving in mindset. We moeten afstappen van het idee dat een compilatie-succes gelijk staat aan goed werk. Door een robuust raamwerk op te zetten dat zich richt op functionele correctheid via unit tests (pass@k), geautomatiseerde stijlanalyses en meedogenloze veiligheidscontroles, beschermt u de integriteit van uw codebase. Het stelt u in staat om AI-assistenten niet als wondermiddelen te zien, maar als krachtige, zij het feilbare, gereedschappen die strikte kwaliteitscontrole behoeven.