Go-teamet: flaskehalsen flyttet fra å skrive kode til å verifisere den

Historisk målte utviklere et språks produktivitet i hvor lett det er å skrive, skriver Go-teamet på Google Developers Blog. Når en kodeagent kan generere hundrevis av syntaktisk gyldige linjer på sekunder, er den hastigheten ikke lenger interessant. Flaskehalsen har flyttet seg til gjennomgang, verifisering og vedlikehold av kode som allerede finnes.

Argumentet deres er at Go ble designet for akkurat den situasjonen lenge før agentene kom. Rob Pike, Robert Griesemer og Ken Thompson bygde språket rundt teamarbeid: én påtvunget formatering gjennom gofmt, bevisst begrensede abstraksjoner, og et standardbibliotek som gjør det unødvendig å dra inn eksterne rammeverk. Resultatet er at kode fra en senioringeniør, en fersking og en språkmodell ser lik ut, og en hallusinert API-kall stikker seg raskere ut.

Den tekniske påstanden som er lettest å etterprøve, handler om kompilatoren. I dynamisk typede språk som Python slipper hallusinerte egenskaper forbi syntakssjekken og krasjer først i produksjon. I Go nekter kompilatoren å bygge hvis agenten kaller en metode som ikke finnes, sender feil type eller lar en variabel stå uinitialisert. Kombinert med Gos kompileringshastighet gir det agenten en rask selvkorrigeringssløyfe før et menneske i det hele tatt ser koden.

Go-teamet peker også på forsyningskjeden. Språkmodeller foreslår gjerne utdaterte eller uvedlikeholdte tredjepartspakker fra treningsdataene sine, mens Gos standardbibliotek leder modellen mot pakker som allerede er der. Når eksterne avhengigheter trengs, ligger sjekksummer og hurtigkopier av hver modul i Gos checksum-database og modulspeil, og govulncheck flagger kode som faktisk kaller sårbare symboler.

Dette er Googles eget innlegg om Googles eget språk, så argumentet er ikke nøytralt. Men premisset er verdt å teste uansett språkvalg: hvis agenten din skriver mest kode, er spørsmålet hvor mye av verktøykjeden din som er standardisert nok til at både du og modellen leser samme svar.

Hva bør du gjøre?

1. Kjør gofmt, go vet og govulncheck i agentens egen sløyfe, ikke bare i CI, slik at modellen retter seg selv før du leser diffen.
2. Mål hvor lang tid du bruker på å verifisere agent-generert kode mot hvor lang tid den bruker på å skrive den. Det tallet, ikke tokenprisen, avgjør hvilket språk som lønner seg.
3. Sett fuzz-tester på grensetilfellene i koden agenten rører mest, siden Gos innebygde fuzzing gir modellen et konkret signal å iterere mot.