Michael JohnsonAgentille voi antaa tehtävän, odottaa muutoksia repositorioon ja saada tarkistettavaksi pull requestin luonnoksen. Koodin mukana herää kuitenkin kysymys: vastaako tulos tehtävänantoa, ja jäikö testeiltä jokin tärkeä ongelma huomaamatta?
4. helmikuuta 2026 GitHub ilmoitti Claude- ja Codex-koodausagenttien julkisesta esikatselusta. Yhtiön mukaan agenteille voi antaa tehtäviä issueista ja pull requesteista, minkä jälkeen niiden laatiman PR-luonnoksen voi tarkistaa. Tämä vahvistaa, että tällainen käyttötapaus on tullut osaksi kehitysympäristöä, mutta ei todista ajansäästöä eikä koodin laadun paranemista.
Kysymys ei siis ole vain siitä, pystyykö agentti kirjoittamaan koodia. Olennaista on, mitä ihmisen on tehtävä delegoidun tehtävän ympärillä: määriteltävä reunaehdot, seurattava työn etenemistä ja arvioitava tulosta.
Valvonta ei ole pelkkä lopputarkastus
21. syyskuuta 2026 arXivissa julkaistussa ennakkojulkaisussa tutkijat ehdottavat, että koodausagentin valvontaa tarkasteltaisiin vaiheittaisena prosessina. Tutkimus The Work Behind Delegation perustuu 19 kokeneen kehittäjän havainnointiin ja työnkulkujen kaavioihin. Kirjoittajat kuvaavat seitsemän valvonnan vaihetta ja soveltavat tätä viitekehystä kehittäjien julkisiin Reddit-keskusteluihin.
Kirjoittajien kuvaamiin toimintatapoihin kuuluu suunnitteluun panostaminen, joidenkin valvontatehtävien siirtäminen toisille agenteille sekä toistuvien ohjeiden muuntaminen uudelleenkäytettäviksi materiaaleiksi. Kyseessä on analyyttinen viitekehys, ei ajankäytön mittaus: tutkimus ei selvitä, kuinka paljon kehittäjät käyttävät aikaa valvontaan tai onko tällainen prosessi manuaalista työtä nopeampi. arXivin sivulla ennakkojulkaisun ilmoitetaan olevan vertaisarvioinnissa, joten sen johtopäätöksiä on pidettävä alustavina.
Käytännössä on hyödyllistä erottaa kolme toimintoa. Tehtävän määrittely asettaa tavoitteen ja reunaehdot. Seuranta auttaa huomaamaan, poikkeaako agentti aikeesta. Tarkistus auttaa arvioimaan, voidaanko tulos hyväksyä vaatimukset, koodi ja testit huomioon ottaen. Onnistuminen yhdessä vaiheessa ei takaa onnistumista seuraavassa: korjaus voi näyttää uskottavalta mutta ratkaista väärän ongelman tai vaatia huomattavaa uudelleentyöstöä.
Yhteisön kokemukset eivät ole tilastotietoa
r/LocalLLaMA-keskustelussa yksi osallistuja kertoi pettyneensä kokemuksiinsa paikallisista malleista ja agenteista: hänen mukaansa tuloksia piti korjata ja agentteja muistuttaa ohjeista. Saman keskusteluketjun muut osallistujat kuvasivat itselleen hyödyllisemmäksi prosessin, jossa tehtäviä rajataan, työskennellään vaiheittain ja koodi tarkistetaan huolellisesti. Nämä ovat yksittäisiä käyttäjähavaintoja, eivät mallien vertailutesti tai tiimien tuottavuuden mittaus.
Kokemusten erot osoittavat, että niihin voivat vaikuttaa tehtävä, malli, ympäristö ja työskentelytapa. Yhden keskustelun perusteella ei kuitenkaan voi päätellä, mitkä käytännöt ovat keskimäärin tehokkaimpia tai kuinka usein ongelmia ilmenee. Ketju käsittelee paikallisia malleja, joten sen havaintoja ei pidä automaattisesti yleistää kaikkiin agenttityökaluihin.
Ihmisen osallistuminen ei itsessään tarkoita, että delegoinnista ei olisi hyötyä. Kehittäjä voi jakaa tehtävän osiin, tarkistaa muutokset ja täsmentää vaatimuksia – ja silti vastata lopputuloksesta. Mutta ilman tehtävän määrittelyyn, korjauksiin ja katselmointiin kuluvan ajan huomioimista ei voida sanoa, vähenikö kokonaistyömäärä.
PR-luonnos ei vielä ole hyväksytty PR
GitHubin kuvaamassa käyttötapauksessa agentille voi antaa issuen, ja tulokseksi saa pull requestin luonnoksen. Sen luomisen ja hyväksymisen väliin jää erillisiä kysymyksiä: vastaako muutos vaatimuksia, onko reunatapaukset huomioitu, ovatko testit riittäviä ja sopiiko ratkaisu projektin arkkitehtuuriin?
Näitä kriteerejä ei voi tiivistää yhdeksi mittariksi. Luotujen muutosten määrä ei vastaa käyttökelpoisten muutosten määrää, eikä testien läpäisy välttämättä vahvista kaikkia korjauksen tärkeitä ominaisuuksia. Edes laadukkaalta näyttävä tulos ei itsessään kerro, kuinka paljon työtä sen valmisteluun ja tarkistamiseen kului.
Kokonaisvaikutuksen arvioimiseksi on huomioitava koko prosessi: tehtävän määrittely, tuloksen odottaminen, katselmointi, korjaukset ja koodin myöhempi ylläpito. Tarkastellut lähteet eivät tarjoa tällaista kokonaisvertailua.
Mitä voidaan päätellä?
Ennakkojulkaisu tarjoaa viitekehyksen valvonnasta keskustelemiseen, ja GitHub on kertonut käyttötavasta, jossa agentille annetaan tehtävä ja sen valmistelema PR tarkistetaan. Reddit-keskustelu osoittaa, että yksittäiset käyttäjät kuvaavat sekä paikallisten mallien käytön vaikeuksia että hyödyllisiksi kokemiaan toimintatapoja. Yhdessä nämä aineistot auttavat pohtimaan, miten delegoidun koodin tarkistus järjestetään, mutta ne eivät kerro nettovaikutuksesta tuottavuuteen.
Niistä ei voi päätellä, että kehittäjät olisivat yleisesti jo siirtyneet koodin kirjoittamisesta valvontaan, että agentit aiheuttaisivat aina lisätyötä tai että ne parantaisivat koko alan tuottavuutta. Tällaiset päätelmät edellyttävät vertailukelpoisia ajan ja laadun mittauksia erilaisissa tehtävissä ja tiimeissä.
Tiimin käytännön kysymys on täsmällisempi: millaisia muutoksia agentti voi valmistella itsenäisesti, mitä on tarkistettava ennen yhdistämistä ja kuka vastaa siitä, että tulos ratkaisee alkuperäisen tehtävän? Delegointi ei poista tätä insinöörityötä – se muuttaa sitä, missä työ alkaa ja mihin se keskittyy.