Hva AI er dårlig på i kode, og hvordan du sikrer deg

AI-verktøy gjør ikke tilfeldige feil. De gjør de samme feilene igjen og igjen, og når du kjenner mønstrene, fanger du dem i review på sekunder. Her er de seks vanligste, og hva som stopper dem.

1. Oppdiktede API-er og parametere

Verktøyet skriver et kall til en funksjon som høres riktig ut, men som ikke finnes, eller sender inn et parameter biblioteket ikke har. Det ser overbevisende ut fordi navnet følger konvensjonen.

Sikring: TypeScript og en kompilator som kjøres før PR. Alt som ikke typesjekkes, kommer ikke inn. For dynamiske språk: kjør koden i en test før review.

2. Utdaterte biblioteker og mønstre

Modellen er trent på kode fra flere år tilbake. Den foreslår gjerne versjon 3 av et bibliotek når dere bruker versjon 5, eller et mønster som var vanlig i 2021.

Sikring: Fortell verktøyet hvilke versjoner dere bruker, i et dokument i repoet. Be det lese dokumentasjonen i node_modules eller tilsvarende før det skriver. Ikke godta nye avhengigheter uten å sjekke at versjonen er riktig.

3. For mye kode

AI skriver gjerne 200 linjer der 50 holder: ekstra abstraksjoner, feilhåndtering for ting som ikke kan skje, og «fleksibilitet» ingen ba om.

Sikring: Be eksplisitt om minimum. Spør i review: hvilke av disse linjene kan slettes uten at testene feiler? Ofte er svaret halvparten.

4. Stille endring av oppførsel

Oppgaven var å rette en feil i én funksjon. På veien «ryddet» verktøyet i tre andre, endret en standardverdi og fjernet en sjekk det ikke forsto.

Sikring: Les diffen, ikke bare koden. Alt som er endret utenfor oppgaven skal enten begrunnes eller reverteres. En agent som får beskjed om å kun røre navngitte filer, gjør det som regel.

5. Tester som ikke tester

Verktøyet lager tester som kaller funksjonen og sjekker at den ikke kaster feil. Eller som gjentar implementasjonen linje for linje. Grønne, og verdiløse.

Sikring: En test skal feile hvis koden er feil. Be verktøyet skrive testen først, kjøre den og vise at den feiler, og så skrive koden. Det er den gamle TDD-sløyfen, og den fungerer uvanlig godt med AI.

6. Sikkerhetshull som ser ryddige ut

SQL satt sammen med strenger, hemmeligheter i kode, manglende tilgangskontroll på et nytt endepunkt. AI skriver det samme som finnes mest av på internett, og det er ikke alltid det sikreste.

Sikring: Automatiske sjekker i CI (lintere med sikkerhetsregler, skanning av avhengigheter, hemmelighetsskanning) og én fast sjekkliste for nye endepunkter: hvem får kalle dette, og med hvilke data?

Oppsummert

Ingen av sikringene er nye. De var gode ideer før AI også. Forskjellen er at de nå er nødvendige, fordi mengden kode som skrives har gått opp og tiden per linje har gått ned.