Kodefuldførelse (code completion)

Kodefuldførelse findes i tre generationer. Klassisk fuldførelse, IntelliSense-agtig og nu standardiseret i Language Server Protocols forespørgsel textDocument/completion, oplister identifikatorer, der ifølge parseren og typetjekkeren er gyldige ved markøren, så den er præcis, men foreslår aldrig mere end ét token eller navn. Statistisk fuldførelse fulgte efter Hindle et al.'s iagttagelse fra 2012 af, at kildekode er meget gentagende og forudsigelig ("On the naturalness of software"), først med n-gram-modeller og senere med neurale rangeringsmodeller. Transformerbaseret fuldførelse, udbredt af GitHub Copilot fra 2021, genererer hele linjer eller blokke og er det, de fleste udviklere i dag mener med begrebet.

En moderne fuldførelsesforespørgsel er en stram realtidspipeline. Editoren debouncer tastetryk, annullerer igangværende forespørgsler, når brugeren skriver videre, og bygger en prompt af præfikset før markøren, suffikset efter den (formateret til en fill-in-the-middle-model) og nogle få uddrag hentet fra nabofiler, der er åbne, eller et lokalt indeks. Latensbudgettet er på et par hundrede millisekunder fra ende til anden, så udbyderne bruger forholdsvis små modeller, cacher aggressivt og streamer tokens. Efterbehandlingen afgør, hvor et forslag skal stoppe, typisk ved at afbalancere parenteser, følge indrykning eller tjekke, at resultatet stadig kan parses, og fjerner tekst, der gentager suffikset. Nyere "next edit"-funktioner udvider idéen fra at indsætte ved markøren til at forudsige, hvor og hvad den næste ændring andetsteds i filen bliver.

Kvalitet måles anderledes end ved chat. Offline-benchmarks bruger enhedstests i stil med HumanEval eller testsæt til infilling, mens online-telemetri følger acceptraten, og hvor meget accepteret kode der overlever uændret efter nogle minutter. Ziegler et al. (2022) fandt, at acceptraten blandt de brugsmål, de undersøgte, var den bedste forudsigelse af udviklernes oplevede produktivitet, hvilket forklarer, at leverandørerne optimerer efter den, men accept siger intet om korrekthed eller sikkerhed.

Risikoen kommer af mængde og lav friktion. En udvikler kan se hundredvis af forslag om dagen, hver accepteret med et enkelt Tab, så automatiseringsbias er strukturel frem for lejlighedsvis. Fuldførelser kan kalde API'er, der ikke findes, bruge forældede eller usikre mønstre, importere hallucinerede pakker eller gengive licenseret kode ordret, og fordi modellen kun ser lokal kontekst, kan den bryde med invarianter, der er fastlagt andre steder i kodebasen. Kontrollerne er de sædvanlige for upålidelig kode: kompiler og typetjek, kør tests og SAST i CI, og slå leverandørens eventuelle filtre for hemmeligheder og match med offentlig kode til.