Ba AI skrive bedre og bedre og bedre kode – til slutt ble resultatet motsatt

– Det kreves en solid utviklerbakgrunn for å forstå hva som faktisk er en god idé, sier mannen bak eksperimentet.

AI-assistenter er til mye større hjelp for utviklere som kan mye fra før, viser eksperiment. 📸: Ole Petter Baugerød Stokke
AI-assistenter er til mye større hjelp for utviklere som kan mye fra før, viser eksperiment. 📸: Ole Petter Baugerød Stokke Vis mer

Store språkmodeller (LLM-er) kan forbedre sine egne kodeforslag hvis du ber om det, men du må ha en del erfaring som utvikler for å få AI-assistentene til å gjøre det på en god måte, skriver The Register.

Et nytt eksperiment gjennomført av Max Woolf, senior data scientist i Buzzfeed, viser at selv om AI-assistenter kan være nyttige for nybegynnere, så er de mye nyttigere om du faktisk vet hva du holder på med – og vet hvordan du skal spørre.

Eksperimentet gikk kort fortalt ut på å gjentatte ganger be AI-assistenten – i dette tilfellet Anthropic Claude – om å gjøre koden den foreslo bedre.

– Hvis kode faktisk kan forbedres ved hjelp av iterative forespørsler, som å be LLM om å “gjøre koden bedre” – selv om det er veldig tullete – ville det vært en enorm produktivitetsøkning, skriver Woolf i et blogginnlegg.

Inspirert av AI-meme

Woolf fikk idéen til eksperimentet etter at OpenAI i november i fjor lanserte muligheten for at ChatGPT kunne generere bilder.

I løpet av ukene etter lanseringen flommet internett over av AI-genererte bilder der folk ga ChatGPT et bilde og gjentatte ganger ba den om å gjøre den "mer av ett eller annet":

– Hva vil skje hvis vi prøver en lignende teknikk på kode? LLM-generert kode er sannsynligvis ikke slurvete (selv om det ikke er umulig), ettersom den følger strenge regler. I motsetning til kreativ output som for eksempel bilder, kan kvaliteten på kode måles mer objektivt, skriver Woolf.

Han ba så Claude i oppgave å skrive Python-kode som tok en liste med 1 million heltall mellom 1 og 100.000, og fant forskjellen mellom det minste og største tallet der summen av sifrene i tallet blir 30.

Dette er prompten som ble brukt:

Write Python code to solve this problem:

Given a list of 1 million random integers between 1 and 100,000, find the difference between the smallest and the largest numbers whose digits sum up to 30.

Resultatene fra eksperimentet er lagt ut på Github.

Ble overengineered

AI-assistenten klarte å løse oppgaven på første forsøk, og løsningen var ifølge Woolf korrekt og omtrent slik en nybegynner i Python-programmering ville gjort det. Koden tok gjennomsnittlig 657 millisekunder å kjøre på en Apple Macbook Pro med M3-prosessor.

Altfor tregt – så Woolf ga Claude beskjeden:

write better code
  • Koden han fikk tilbake var 2,7 ganger raskere enn første versjon.
  • Men kunne den bli enda raskere? Det kunne den!
  • Med flere gjentakelser av "write better code"-prompten oppnådde Claude en ytelsesforbedring på hele 99,7 ganger sammenlignet med første versjon.
  • Problemet var at AI-assistenten etter hvert begynte å legge til en masse som gjorde koden ekstremt "overengineered".

– Denne metoden for iterative prompting for å forbedre kode har sine svakheter: koden er faktisk bedre, men i etterpåklokskapens lys er "bedre" altfor vagt. Jeg ønsket algoritmiske forbedringer, ikke en full SaaS-applikasjon, skriver Woolf.

«Jeg ønsket algoritmiske forbedringer, ikke en full SaaS-applikasjon.»

Prompt engineering er viktig

At Claude klarte å øke ytelsen til sitt eget kodeforslag med bortimot hundre ganger var vel og bra, men Woolf endte altså opp med kode som gjorde en masse annet enn bare å løse det aktuelle problemet.

Han gjentok derfor eksperimentet med "prompt engineering", ved å bruke en system prompt, som bare er tilgjengelig via et API. Der kunne han gi LLM-en detaljerte instruksjoner for hva den skal gjøre, at den ikke skulle produsere kode utover det den ble bedt om, hvordan den skal optimalisere koden, og så videre.

Deretter ga han Claude nesten samme prompt som tidligere, men en tilleggsbeskjed om å gjøre optimalisering av koden.

Første versjon av koden han fikk tilbake kjørte på 11,2 millisekunder – 59 ganger raskere enn koden han fikk generert uten de detaljerte instruksene.

Max Woolf fikk flere bugs som krevde utvikler-erfaring for å fikse da han brukte prompt engineering, men koden ble også vesentlig bedre. 📸: Max Woolf - minimaxir.com
Max Woolf fikk flere bugs som krevde utvikler-erfaring for å fikse da han brukte prompt engineering, men koden ble også vesentlig bedre. 📸: Max Woolf - minimaxir.com Vis mer
«Det kreves en solid utviklerbakgrunn for å forstå hva som faktisk er en god idé.»

Etter flere iterasjoner kom Claude opp med en løsning som kjørte 100 ganger raskere enn den opprinnelige koden.

Koden ble ikke raskere enn koden uten prompt engineering, men den ble bedre – og mengden kode var mye mindre. Koden gjorde det den skulle, men ikke mer.

Erstatter ikke utviklere på lenge

Woolf skriver at avansert og gjennomtenkt prompt engineering gjorde at LLM-en mye raskere klarte å øke ytelsen på koden den genererte, sammenlignet med da han stilte bare enkle spørsmål til AI-en.

Ulempen var at det var større sannsynlighet for små, subtile bugs – siden LLM-er ikke er optimalisert for å lage slik "høyytelses" kode.

– Til syvende og sist så kreves det mennesker for å fikse de uunngåelige feilene, uansett hvor ofte AI-entusiaster beskriver LLM-er som magi.

– Disse LLM-ene vil selvfølgelig ikke erstatte utviklere på lenge, siden det kreves en solid utviklerbakgrunn for å forstå hva som faktisk er en god idé, skriver Woolf.