Agenttikehitys on kontekstin hallintaa kahdella tasolla

Agenttivetoinen ohjelmistokehitys on pohjimmiltaan tiedonhallintaa. Agentteja ohjataan kohti tavoitteita tiedon ja niistä muodostuvan kontekstin avulla, joka määrittää, miten haluamme toimia ja mitä sääntöjä noudatamme.

Kontekstilla on kaksi tasoa: yksilön ja tiimin taso. Yksilön näkökulmasta kyse on siitä, miten hallitaan kielimallille annettua kontekstia valitussa työkalussa, kuten Claude Codessa tai Codexissa. Tiimi- ja organisaatiotasolla kyse on enemmän tiedon jakamisesta ja yhteisen ymmärryksen luomisesta.

Kun agenttikehitys pääsee vauhtiin, yksi suurimmista sudenkuopista on teknisen velan lisäksi ymmärrysvelka. Pureudun ensin kontekstin hallintaan. Se auttaa ymmärtämään, miksi ymmärrysvelka koskettaa koko tiimiä.

Tarjoa tarkka konteksti ja pidä se relevanttina

Agenttivetoisessa kehityksessä yksi tärkeimmistä asioista on pitää konteksti-ikkuna relevanttina ja tuoreena. Konteksti toimii kuin työmuisti: kun keskityt johonkin, käytät sitä vain kyseiseen tehtävään, etkä täytä sitä turhalla tiedolla.

Kielimallit käsittelevät tekstiä, kuvia ja ääntä, mutta kehittäjinä meitä kiinnostaa lähinnä teksti. Agenttiympäristöt mahdollistavat kielimalleille itsenäisemmän työskentelyn: kielimalli voi tehdä todellisia muutoksia tiedostojärjestelmään, lukea koodipohjan nykytilaa, hakea tietoa internetistä ja käyttää kolmannen osapuolen palveluita.

Kehittäjän päätehtävä on tarjota agentille mahdollisimman tarkka konteksti. Tavallisin ja toimivin tapa on suunnitella annettava tehtävä huolellisesti. Ja suunnittelulla tarkoitan tässä tapauksessa nimenomaan yksittäisen tehtävän ja ominaisuuden suunnittelua. Tuotteen roadmap voi olla hyödyllistä taustatietoa, mutta ei relevanttia kontekstin hallinnassa.

Suunnittelu vie pitkälle

Hyvä suunnitelma antaa agentille tavoitteen ja askeleet sen saavuttamiseksi. Suunnitelman luominen saattaa kuitenkin vaatia ensin koodipohjan nykytilan ja olemassa olevien ratkaisujen tutkimista. Kehittäjän ei tarvitse itse kirjoittaa suunnitelmaa, vaan hän voi pyytää agenttia sekä tutkimaan koodipohjaa että tekemään suunnitelman ja sen jälkeen toteuttamaan suunnitelman.

Tutkimus → suunnitelma → toteutus -työnkulku pakottaa agentin ja käyttäjän luomaan parhaan mahdollisen kontekstin käsillä olevalle tehtävälle. Claude Code esimerkiksi ehdottaa kontekstin tyhjentämistä ennen suunnitelman toteuttamista. Näin kannattaa tehdä.

Mitä kontekstiin kuuluu?

• Nykyinen keskusteluistunto ja sen koko sisältö
• AGENTS.md- ja CLAUDE.md-tiedostojen sisältö eli käytännössä "projektimuisti", joka säilyy istuntojen välillä
• Taitojen (skills), MCP:n, aliagenttien ja muiden laajennusten määritykset

Agenttiympäristöt hallitsevat kontekstia automaattisesti. Ne tiivistävät keskustelun, kun konteksti-ikkuna täyttyy. Yleensä tässä vaiheessa suorituskyky on jo heikentynyt, sillä kokemuksen mukaan suorituskyky heikkenee jo puolessa välissä konteksti-ikkunaa. Asiat kuitenkin kehittyvät nopeasti työkalujen ja mallien kehittyessä.

Tällä hetkellä kontekstia kannattaa hallita aktiivisesti. Tiivistä ja siivoa vapaaehtoisesti näin:

• (Claude Code) Paina "tupla-esc" hylätäksesi virheilmoitukset ja palataksesi ajassa taaksepäin istunnossa.
• (Claude Code) Aja /compact tiivistääksesi manuaalisesti ennen kuin ympäristö tekee sen automaattisesti.
• Delegoi valittuja töitä aliagenteille. Niillä on omat konteksti-ikkunansa.
• Hylkää umpikujat ja aloita alusta uusilla ideoilla.
• Siirrä tiivistelmiä ja suunnitelmia manuaalisesti toisille agenteille tai malleille.

Kontekstin hallinta muistuttaa lopulta hieman ihmisten johtamista. Mitä selkeämmin kommunikoit odotukset ja tavoitteet, sitä parempi suorituskyky. Se on kuin ilmaista johtamisharjoittelua työntekijän kanssa, joka ei koskaan pahastu.

Mitä tapahtuu kehittäjien osaamiselle?

Jos suurin osa kehitystyöstä on kontekstin hallintaa agenteille, mitä tapahtuu koodaukselle? Ja mitä tapahtuu kyvylle arvioida generoitua koodia?

Uskon, että kehittäjien tulee pysyä perillä siitä, miten koodi ja syntaksi toimivat. Tämä tarkoittaa eri asioita eri projekteissa, toimialoilla ja palvelun kriittisyydestä riippuen. Joskus ydinlogiikka täytyy kirjoittaa tai testata kokonaan käsin tai joskus jopa jokainen rivi täytyy arvioida huolellisesti. Joka tapauksessa vastuuhenkilöiden on ymmärrettävä, miten koodi toimii.

Kone voi kirjoittaa suuren osan koodista, mutta edelleen ihminen on se, joka työn arvioi. Automaation seuraava askel on mahdollisesti se, että tekoäly on vastuussa myös koodin katselmoinnista. Ehkä sekin saavuttaa pian riittävän hyvän tason.

Lopullinen vastuu tuloksista on kuitenkin edelleen ihmisellä. Riippumatta siitä, katselmoiko hän koodia rivi riviltä, tosiasia on, että arvioitavaa ja sisäistettävää tulee olemaan enemmän. Tämä luo pullonkauloja ihmisten omaksumiskykyyn.

Koodikatselmointien merkitys muuttuu

Tiimityö on yhteistä suunnittelua ja tiedon jakamista. Ohjelmistokehityksessä yksi tärkeimmistä yhteistyön muodoista on toisen koodin katselmointi.

Koodikatselmoinnit eivät ole aina suoraviivaisia, ja mielipiteet voivat erota. Se on myös ehkä kehittäjien ammatin vähiten hohdokas puoli, vaikka kaikki tunnustavat sen tärkeyden. Katselmointi on ollut usein prosessin pullonkaula jo ennen kuin tekoäly moninkertaisti koodin tuotantonopeuden.

Luonnollisesti pullonkaula pahenee, kun koodimuutoksia tulee enemmän. Yritämme ratkaista sen ottamalla käyttöön lisää tekoälytyökaluja. Automatisoitujen koodikatselmointien tavoite on löytää bugeja, ilmeisiä virheitä, kyseenalaisia arkkitehtuuripäätöksiä tai haistaa, onko koodissa jotain mätää.

Katselmointien tavoite ei ole kuitenkaan vain löytää virheitä. Niiden epäsuora vaikutus on jaetun omistajuuden ja koodipohjan ymmärryksen kasvattaminen. Tulevaisuudessa koodikatselmoinneissa korostuukin yhä enemmän yhteisen ymmärryksen varmistaminen. Kun tekoäly tuottaa koodia moninkertaisella vauhdilla, pelkkä bugien etsiminen ei riitä. Tiimin on tietoisesti varmistettava, että kaikki ymmärtävät mitä on tehty.

Enemmän koodia ja dokumentaatiota

Kontekstin hallinnan vaatima suunnittelu saa kehittäjät kirjoittamaan (tai generoimaan) enemmän dokumentaatiota kuin koskaan. Koska kehittäjien ei tarvitse enää kirjoittaa niin paljon koodia, aikaa ja kapasiteettia jää enemmän suunnitelmien arvioimiseen. Toteutuksen jälkeen myös dokumentaation voi hoitaa agentteja hyödyntäen. Tekoäly voi luoda tekstin lisäksi diagrammeja, kuvia tai muita visualisointeja, jotka tekevät muutoksista ja dokumentoinnista helposti ymmärrettäviä.

Ihmismieli pystyy kuitenkin omaksumaan vain rajallisen määrän tietoa. Jossain kohtaa tiimeillä tulee raja vastaan agenttien ja tiedon määrän koordinoinnissa. Lopulta tiimeissä alkaa kertymään ymmärrysvelkaa (comprehension debt), mikä usein viittaa myös teknisen velan olemassaoloon. Tässä vaiheessa tiimin täytyy hidastaa, ehkä jopa pysähtyä hetkeksi, määrittää uudelleen suuntaansa ja jatkaa vasta sitten kehitystä.

Vastuu säilyy ihmisellä

Tärkein neuvoni olkoon: älä lopeta tekoälyn käyttöä siihen, kun koodi on generoitu, testattu ja pushattu tuotantoon. Varmista, että tiimisi ymmärtää, mitä olette saaneet aikaan. Kun panostat dokumentointiin ja ymmärryksen jakamiseen, olet askeleen lähempänä luomassa lähes autonomista järjestelmää, jossa agentit voivat hoitaa työt itsenäisesti. Agentit ottavat vastaan kontekstin ja hiovat sen annettujen ohjeiden pohjalta, luovat suunnitelmat ja toteuttavat ne sekä kirjaavat dokumentaatiot ja yhteenvedot tiimillesi luettavaksi. Sinä toimit orkestroijana ja vastuunkantajana.

Tämän tekstin käännöksessä käytettiin apuna Claudea. Alkuperäinen teksti on kirjoitettu englanniksi blogiimme. Kirjoittaja on tarkistanut, muokannut ja hyväksynyt sisällön.