Kun tekoäly avustaa koodaamista – uusi tutkimus paljastaa, miten kehittäjät oikeasti käyttävät näitä työkaluja

Tekoälykoodaustyökalujen maailma on muuttunut viime vuosina radikaalisti. Claude Code, Codex ja Gemini CLI ovat nykyään arkea monille kehittäjille. Mutta kun nämä työkalut siirtyvät laboratoriosta todelliseen käyttöön, syntyy uusia haasteita. Miten näitä palveluita voi skaalata tehokkaasti ilman, että viiveet vievät hermot?

Uuden tutkimuksen takana on Washingtonin yliopiston SyFI-laboratorio. He ovat keränneet valtavan määrän dataa siitä, miten kehittäjät oikeasti käyttävät tekoälyavusteisia koodaustyökaluja. Tulokset ovat yllättäviä – ja haastavia infrastruktuurin rakentajille.

Autonominen vallankumous, johon ei osattu valmistautua

Koodausagentit eivät ole perinteisiä chatbotteja. Kun kehittäjä pyytää tekoälyä toteuttamaan ominaisuuden tai korjaamaan bugin, käynnistyy kokonainen autonominen prosessi. Malli miettii, suorittaa komentoja, lukee ja muokkaa tiedostoja, ajaa testejä ja toistaa toimintoja, kunnes tulos on valmis.

Tutkijat analysoivat yli 4 300 todellista käyttöistuntoa, jotka tuottivat noin 55 miljardia tokenia. Löydökset ovat merkittäviä: jokainen käyttäjän pyyntö käynnistää keskimäärin 8,8 LLM-työkalu -kierrosta. Yhden kysymyksen ympärille syntyy siis lähes yhdeksän mallin ja työkalun välistä vuorovaikutuskierrosta.

Tässä piilee oleellinen ero perinteisiin järjestelmiin. Vanhat mallit odottavat kysymystä ja vastaavat – ehkä muutamalla jatkokysymyksellä. Koodausagentit ovat pitkäaikaisia autonomisia prosesseja, joissa konteksti vaihtuu jatkuvasti generoinnin ja suorituksen välillä.

Erityisen kiinnostava havainto: 88 prosenttia kaikista LLM-inferenssikierroksista tapahtuu työkalun tulosten perusteella, ei alkuperäisen käyttäjän syötteen. Malli ei vain keskustele – se toimii.

Ongelma: välimuistit eivät toimi odotetulla tavalla

Tässä luku, joka saa jokaisen infrastruktuurin rakentajan kiinnostumaan. Tutkimuksen mukaan syötteet ovat 294-kertaisia ulostuloihin verrattuna. Analysoiduissa trace-tiedoissa malle luettiin 52,56 miljardia välimuistissa olevaa tokenia ja esitäytettiin 2,34 miljardilla uudella tokenilla. Silti malleista tuli ulos vain 186,9 miljoonaa tokenia.

Tyypillinen kierros istuu 32 000–256 000 tokenin esikäsittelyssä ja lisää vain muutamia satoja tai tuhansia tokeneita ennen kuin generoi ulostuloa. Tämä luo täysin erilaisen suorituskykyprofiilin kuin mihin useimmat LLM-palvelujärjestelmät on optimoitu.

Perinteisessä kielimallipäättelyssä keskitytään generointinopeuteen – kuinka monta tokenia sekunnissa saadaan ulos. Koodausagenteille pullonkaula on usein aika ensimmäiseen tokeneihin (TTFT) sen jälkeen, kun työkalu on palauttanut tuloksen. Codexin TTFT jokaiselle vaiheelle on noin 3,1 sekuntia, mikä vastaa noin neljäsosaa kierroksen kokonaisgenerointiajasta. Yhdeksän kierrosta per pyyntö tarkoittaa, että tämä yleisoverhead kertautuu nopeasti.

Välimuistituen merkitys on myös monimutkaisempi kuin ensi alkuun vaikuttaa. Syötevälimuisti auttaa valtavien kontekstien kanssa, mutta esitäyttö jakautuu välimuistitettujen ja uusien tokenien välillä. Lyhyet inkrementaaliset esitäytöt työkalun suorituksen jälkeen vaativat erilaisia optimointeja kuin alkuperäinen pitkä konteksti.

Komentorivi hallitsee yhä

Voisit kuvitella, että tekoälyagentit keskittyisivät hienostuneeseen päättelyyn ja monimutkaiseen refaktorointiin. Tutkimus kertoo toisen tarinan.

Trace-datan 433 000 työkalukutsusta 76 prosenttia oli shell- tai komentotulkin käskyjä. Buildien ajaminen, testien suoritus, git-operaatiot, tiedostojen käsittely komentorivityökaluilla – kaikki se vähemmän glamourin näköinen työ, joka oikeasti muodostaa kehittäjän päivittäisen arjen.

Tiedostojen muokkaukset kattoivat 11 prosenttia, lukemiset ja haut 9 prosenttia. Loput jakautuivat suunnittelun, aliedustajien delegoinnin ja verkkohakujen kesken.

Tämä painottuminen komentotulkin käskyihin vaikuttaa infrastruktuuriin monin tavoin. Ensinnäkin nämä ovat pitkähäntäisiä operaatioita: yksinkertainen ls on nopea, mutta kokonaisen testisarjan ajaminen tai suuren koodikannan kääntäminen voi viedä minuutteja. Latenssijakauma ulottuu neljään suuruusluokkaan, mikä tekee kapasiteetin suunnittelusta vaikeaa.

Toiseksi työkaluvalikoima vaihtelee merkittävästi eri agenttien välillä. Claude Code käytti 54 eri työkalua, Codex vain 31. Molemmat keskittivät valtaosan kutsuistaan samaan ydinjoukkoon: shell, tiedostojen muokkaus, tiedostojen luku. Tämä viittaa siihen, että näiden korkeataajuisten työkalujen optimoiminen voisi tuottaa suhteettoman suuria parannuksia.

Mitä tämä tarkoittaa infrastruktuurille?

Jos rakennat tai operoit tekoälypohjaisia kehitystyökaluja, tutkimus tarjoaa useita käytännön johtopäätöksiä.

Ajattele työnkulkuja, älä yksittäisiä pyyntöjä. Palveluinfrastruktuurin täytyy huomioida koodausagenttien autonominen, monivaiheinen luonne. Tämä tarkoittaa pidempiaikaisia konteksteja, kehittyneempää tilanhallintaa ja eräajo-mahdollisuuksia, jotka ryhmittelevät toisiinsa liittyvät työkalukutsut.

Optimoi tyhjien aikojen hyödyntämiseen. Käyttäjät viettävät keskimäärin 46,7 minuuttia pyyntöjen välillä, vaikka ajatteluaika on vain 1,4 minuuttia. Jakauma on erittäin raskas häntä – jotkut kehittäjät iteroivat nopeasti, toiset aloittavat pyynnön ja palaavat tunnin päästä. Älykkäät ennakkoväljyttö- ja uudelleenesitäyttöstrategiat näiden hiljaisten jaksojen aikana voisivat vähentää koettua latenssia merkittävästi ilman laskennallisten kustannusten kasvua.

Erota esitäyttö- ja dekoodauspolut. 294:1 syöte-ulostulosuhde tarkoittaa, että esitäyttölaskenta on todennäköisesti hallitseva kustannuserä. Työkalun suorituksen jälkeiset inkrementaaliset esitäytöt tarvitsevat erilaisia optimointeja kuin alkuperäinen kontekstin lataus. Kannattaa harkita erillisiä resurssipoolseja tai ajoituskäytäntöjä näille eri kuormatyypeille.

Älä unohda työkalun suoritusinfrastruktuuria. Kun 76 prosenttia agentin toiminnasta on komentotulkin komentoja, konttiorkestrointi, tiedostojärjestelmäkäyttö ja build-työkalujen välimuisti nousevat ensiluokkaisiksi huolenaiheiksi. Mallin päättely on vain osa putkea.

Mitä tulevaisuudessa tapahtuu?

TraceLab-tiimi on avannut trace-keräys- ja analyysityökalunsa avoimen lähdekoodin projektina. Tämä mahdollistaa sen, että infrastruktuuritiimit voivat generoida omia tracejaan ja optimoida todellisten käyttöpatternien mukaan sen sijaan, että luotettaisiin synteettisiin testeihin.

Tämän kaltainen todelliseen käyttöön perustuva data on juuri sitä, mitä tekoälyinfrastruktuurin ala tarvitsee kypsyessään "saada toimimaan" -vaiheesta "saada toimimaan skaalassa" -vaiheeseen.

Tämä tutkimus korostaa, miksi pelkkä GPU-resurssien varaaminen ei riitä. Tekoälykoodausagenttien palveleminen ei ole vain raakaa laskentaa – se on näiden agenttikuormien ainutlaatuisten ominaisuuksien ymmärtämistä ja järjestelmien rakentamista, jotka pystyvät käsittelemään autonomista, monivaiheista, työkalupainotteista todellisuutta.

Koodausagenttien aikakausi on vasta alkanut, ja infrastruktuuripäätökset, jotka teemme nyt, muovaavat sitä, miten tehokkaasti nämä työkalut palvelevat kehittäjiä vuosien saatossa.