Kallein malli ei tee koko työtä

Melkein jokainen, joka aloittaa tekoälyavusteisen kehityksen, tekee saman virheen. Valitaan se kaikkein fiksuin ja kallein malli, ja annetaan sen tehdä kaikki: arkkitehtuurin suunnittelu, koodirivien kirjoittaminen, testien ajaminen, jopa pilkun paikan tarkistus. Kun lasku alkaa näyttää ikävältä tai vastaukset hidastuvat, käännytään toiseen ääripäähän ja vaihdetaan kaikki halvimpaan malliin. Molemmat ovat väärä johtopäätös samasta virheestä.

Rakentaessani Pyöräpassia ja muita sivuprojektejani opin, että kysymys ei ole “mikä malli on paras”, vaan “mikä malli sopii mihinkin tehtävään”. Suunnittelu, toteutus ja katselmointi ovat kolme eri kognitiivista tehtävää, ei kolme hintaluokkaa samasta työstä.

Kolme roolia, ei kolme hintaluokkaa

Kalleimmat mallit (Claude Opus tai Fable) ajattelevat syvemmin ja pitävät hallussaan isomman kokonaiskuvan. Ne sopivat siihen vaiheeseen, jossa pitää hahmottaa arkkitehtuuri, tunnistaa riskit etukäteen ja päättää missä järjestyksessä asiat kannattaa rakentaa. Halvimmat mallit (Haiku) ovat nopeita ja edullisia, mutta niiden vahvuus on hyvin rajatun, valmiiksi speksatun tehtävän toteutus, ei avoimen ongelman ratkominen. Väliin jäävä malli (Sonnet) on tasapainoisin, ja siksi se sopii parhaiten valvonta- ja katselmusrooliin: se ei ole halvin mahdollinen valinta, mutta se on riittävän hyvä huomaamaan kun jokin menee pieleen, ilman että siitä tulee yhtä kallis kuin suunnittelija.

Hintaero näiden välillä ei ole pieni. Halvin malli maksaa karkeasti viidesosan tai jopa kymmenesosan kalleimman hinnasta samasta tokenimäärästä. Kun toteutustyö on suurimmaksi osaksi hyvin speksattua, ei-luovaa työtä, tuo hintaero on täysin hukkaan heitettyä rahaa jos koko putki ajetaan kalleimmalla mallilla.

Yksi aalto käytännössä

Kun aloitan uuden ominaisuuden rakentamisen (Pyöräpassin liikehakemisto tai vastaava kokonaisuus), annan kalleimmalle mallille koko kontekstin: mitä ollaan rakentamassa, mitä rajoituksia on, mitä pitää testata. Se tuottaa toteutussuunnitelman, joka on jaettu aaltoihin, eli selkeästi rajattuihin, peräkkäisiin työvaiheisiin. Suunnitelmaan kuuluu aina myös testausvaatimukset, kuten yksikkötestit ja tarvittaessa e2e-testaus Playwrightilla, koska ilman niitä seuraava vaihe ei tiedä milloin aalto on oikeasti valmis eikä vain näytä valmiilta.

Sen jälkeen halvempi malli ottaa yhden aallon kerrallaan ja toteuttaa sen suunnitelman mukaan. Tässä vaiheessa väliin jäävä malli toimii kahdessa roolissa vuorotellen. Ensin valvojana: se tarkkailee edistymistä, esimerkiksi git-lokia, ja puuttuu asiaan jos toteuttaja jää jumiin tai alkaa iteroida samaa kohtaa loputtomiin ratkaisematta ongelmaa. Sitten katselmoijana: kun aalto on valmis, se käy koodin läpi ennen kuin seuraava aalto alkaa, ja tekee tarvittavat korjaukset tai antaa tarkemmat ohjeet seuraavaan vaiheeseen.

Tämä katselmusvaihe on tärkeämpi kuin miltä ensin kuulostaa. Sama malli joka juuri kirjoitti koodin, on huono arvioimaan omaa työtään, koska se on taipuvainen kehumaan omaa ratkaisuaan. Erillinen rooli, joka lukee vain diffin ja todisteet, löytää asioita joita testit eivät koskaan löydä: esimerkiksi koodin joka toimii mutta ei ole järkevää, tai suunnitelman joka on tulkittu väärin.

Rakennustyömaan logiikka

Ajattele rakennustyömaata. Arkkitehti piirtää suunnitelman ja päättää missä järjestyksessä talo kannattaa rakentaa: perustukset ennen seiniä, seinät ennen kattoa. Rakennusmiehet tekevät varsinaisen työn suunnitelman mukaisesti, ja he ovat siinä nopeampia ja edullisempia kuin arkkitehti olisi, jos hän itse muuraisi jokaisen kiven. Työnjohtaja kiertää työmaalla, huomaa kun jokin menee suunnitelmasta poikkeavaan suuntaan, ja tarkastaa valmiin työn ennen kuin seuraava vaihe alkaa.

Kukaan ei palkkaa arkkitehtiä muuraamaan kiviä, eikä anna rakennusmiehen päättää itse talon kantavien rakenteiden sijoittelusta. Sama logiikka pätee malliporrastukseen, ja silti useimmat käyttävät tekoälyä juuri niin: sama malli suunnittelee, toteuttaa ja hyväksyy oman työnsä, ilman että kukaan tarkastaa väliltä.

Mitä tämä tarkoittaa käytännössä

Jos tekoälykehitys tuntuu kalliilta, ensimmäinen tarkistus on: ajetaanko koko putki kalleimmalla mallilla, vaikka suurin osa työstä on toteutusta joka ei vaadi sitä älyä? Jos taas tekoäly tuntuu valehtelevan valmiudesta, jumiutuvan tai tuottavan hienovaraisia virheitä, tarkistus on toinen: onko halvin malli töissä yksin, ilman kenenkään valvontaa tai katselmusta?

Yksi konkreettinen työkalu kannattaa rakentaa heti alkuun: erillinen prosessidokumentti, joka kuvaa miten toteutus etenee, mitä pitää testata ja mitä sääntöjä noudatetaan. Se ei ole dokumentaatiota jota kukaan lukee kerran ja unohtaa, vaan se on ainoa asia joka pitää halvan ja kalleen mallin samalla sivulla, koska jokainen malli lukee saman sääntökirjan riippumatta siitä kuka sen alun perin kirjoitti. Ilman sitä ihmisen pitää itse kantaa kontekstia mallista toiseen, ja juuri se on se työ jota koko porrastuksella yritettiin välttää.

Konkreettisen esimerkin siitä, mitä yksi ihminen ja tämä työnjako saavat aikaan, näet Pyöräpassin rakentamisesta kertovasta kirjoituksestani. Ja jos kiinnostaa nähdä miten sama logiikka toimii dataputkessa eikä vain koodissa, tämä kirjoitus avoimen datan ja kielimallin yhdistämisestä on hyvä jatko.