Vi bruker GPT-4 til å sammenligne gammel og ny kode i forbindelse med konverteringen av kode i et legacy system. Hensikten er å automatisk sjekke at logikken er den samme i den nye koden. At ingenting er blitt endret ved en feil eller utelatt. (Konverteringen er også gjort ved hjelp av GPT-4)

Når GPT-4 og mennesker forsåvidt, sammenligner kode skrevet i et programmeringspråk med kode skrevet i annet vil det vanligvis være forskjeller på syntaks og måten kode er skrevet. Det som er interessant å sjekke er om logikken er den samme, at koden fortsatt gjør det samme. For å få GPT-4 til å fokusere bare på den typen forskjeller må man spesifikt sende med instruksjon om det i prompten. Selv med en instruks om å bare se på logiske forskjeller vil GPT-4 ofte si det er forskjeller når det egentlig bare endring i kode syntaks.

Siden vi bruker dette som verktøy til å gjøre automatisk QA på tusenvis av metoder så gjør en feilrate på 20-30% at det blir mye manuelt ekstra arbeid for å sjekke om en rapportert forskjell er reell. For å redusere feilraten kjøres sammenligningen en gang til hvis det rapporteres om en forskjell. Hvis det rapporteres om forskjeller i begge rundene så lagres det som noe som må sjekkes manuelt.

At forskjeller (feil) slipper igjennom uten å bli oppdaget er ikke et like stort problem siden dette er en av flere tester koden går igjennom. Om så bare 50% av åpenbare logiske feil og mangler blir oppdaget er det verdt siden det er en AI som automatisk gjør jobben. Vi ønske likevel å prøve å forbedre sammenligningen til å kunne fange opp de feilene den har sluppet igjennom.

Her er et eksempel på at GPT-4 ikke ser en forskjell som er ganske åpenbar.

GPT-4 sier at gammel og ny kode er logisk like. Selv om det er en ganske vesentlig forskjell i sjekken på Legevakt og Legevakt kommunal.

Original prompt

Prompt:

GPT-4 svar:

GPT-4 svarer nesten konsekvent at No på denne. Vi eksperimenterte med litt forskjellige prompts og fikk den egentlig ikke til å bli noe bedre. Etter hvert hadde vi en teori om at årsaken var at Legevakt og Legevakt kommunal er semantisk samme sak og også vanligvis samme sak i praksis i Norge.

For å unngå at GPT-4 skal legge noe betydning i string verdiene i koden prøvde vi å erstatte de med genererte verdier før sammenligningen gjøres.

Ulempen med dette er at det kan kanskje gjøre akkurat dette tilfellet lettere for GPT-4, men andre tilfeller kan bli vanskelige. Fordi ofte er det som er en string verdi i den ene koden oversatt til en metode, konstant eller feltnavn i den andre.

Erstattet verdier prompt

Prompt:

GPT-4 svar:

Resultatene med å bruke en prompt med erstattede verdier ble bedre, men var fortsatt oftest No. Dette gjør sammen med ulempene med å miste betydningen fra string verdiene, at løsningen ikke er god.

Prompt chain

Det er ikke alltid mulig å «prompt-engineere» alt inn i samme request. Det kan da være bedre å lage en kjede av prompts, en samtale. Der man går igjennom steg for steg detaljene man ikke får inn i den første prompten. Det kan bygges en eller flere kjeder / samtaler, basert på det samme utgangspunktet. Som så settes sammen til slutt. Her er et eksempel på hvordan string verdier sjekken kan løses ved en samtale.

Prompt:

GPT-4 svar:

Prompt:

GPT-4 svar:

Prompt:

GPT-4 svar:

Prompt:

GPT-4 svar:

Oppsummering og forbedret prompt

GPT-4 er som mennesker langt fra perfekt og gir varierende resultater og svar. Noen ganger kan en enkel prompt være nok til å få 100% riktige svar på 300 metode sammenligninger på rad. Mens andre ganger blir det nesten bare feil.

Det gjelder å finne den riktige bruken og kombinere det på en god måte med andre teknikker og verktøy. I dette tilfellet er det nok ikke verdt å bygge en kompleks prompt chain for å forbedre kvaliteten for akkurat dette. Koden er allerede auto konvertert med GPT-4 og det er sjelden denne typen feil oppstår. Det vanligste har vært når utviklerne gjør endringer selv på den genererte koden.

Det enkleste er å heller forbedre prompten litt og øke sannsynligheten litt for at forskjellene i koden oppdages.

Prompt: