Vibe-koodaus ja avustettu ohjelmointi

Joku näyttää sinulle sovelluksen, jonka hän rakensi viikonloppuna. Se toimii. Ruudulla on kirjautuminen, tietokanta, hakutoiminto ja siisti ulkoasu. Luonteva kysymys on: milloin tämä on valmis?

Kysymys kuulostaa yksinkertaiselta, mutta sen sisällä on monta eri kysymystä. Tämä juttu purkaa ne auki, koska koodin tuottaminen on halventunut nopeasti eikä sen jälkeen tuleva työ ole halventunut samassa tahdissa.

Mistä sana tulee

Termin vibe coding otti käyttöön Andrej Karpathy helmikuussa 2025. Hän kuvasi sillä työtapaa, jossa muutokset hyväksytään katsomatta niitä läpi ja toteutusta ohjataan sen perusteella, miltä lopputulos näyttää käytössä. Collinsin englannin sanakirja valitsi termin vuoden 2025 sanaksi ja määrittelee sen luonnollisella kielellä ohjatun tekoälyn käyttämiseksi koodin kirjoittamisen apuna.

Suomeksi sana ei ole vakiintunut. Tässä jutussa käytetään muotoa vibe-koodaus, koska se on se muoto, johon lukija törmää muualla.

Ohjelmoija Simon Willison rajasi termin maaliskuussa 2025 omassa kirjoituksessaan yhdellä lauseella:

Kun puhun vibe-koodauksesta, tarkoitan ohjelmiston rakentamista kielimallilla katselmoimatta koodia, jonka se kirjoittaa.

Saman kirjoituksen otsikko on "Kaikki tekoälyavusteinen ohjelmointi ei ole vibe-koodausta (mutta vibe-koodaus on mahtavaa)", ja se on koko erottelun ydin. Suomennos on oma, alkuperäinen lause on englanniksi.

Termin käyttö on sittemmin laajentunut, ja arkipuheessa sillä tarkoitetaan usein mitä tahansa mallin avulla koodaamista. Siksi tässä jutussa tehdään oma rajaus: vibe-koodauksella tarkoitetaan tässä nimenomaan sitä kapeaa työtapaa, jossa lähdekoodia ei merkityksellisesti katselmoida. Se on Karpathyn alkuperäinen kuvaus, ja se on myös se työtapa, jonka riskit ovat erilaiset kuin katselmoidun työn.

Rajaus on tarpeen, koska muuten samasta sanasta puhutaan kahdesta eri asiasta.

Kaksi työtapaa saman nimen alla

Yritysten esityksissä nämä menevät jatkuvasti sekaisin. Ero ei ole siinä, kuka kirjoittaa koodin, vaan siinä, millä perusteella se hyväksytään ja kuka vastaa lopputuloksesta.

Kumpikin voi olla käyttökelpoinen, mutta katselmoimaton tapa vain silloin, kun mahdollinen vahinko on rajattu, ympäristö eristetty ja muutokset palautettavissa. Ongelma syntyy siitä, että ensimmäisellä tavalla tehty asia esitellään toisena.

Yksi dokumentoitu tapaus

Rakensin keväällä 2026 pilottisovelluksen bändien harjoituskäyttöön: kappaleet, sovitukset, sointukaaviot, demonauhat, settilistat ja reaaliaikainen keskustelu samassa työtilassa. Käytin apuna kielimallia koko ajan. Luvut ensimmäisestä tuotantoon viedystä versiosta, omista muistiinpanoistani:

• kuusi ja puoli viikkoa, käytännössä viikonloppuja
• noin 13 000 riviä koodia, 88 tiedostoa
• 24 käyttöliittymäkomponenttia, 16 sivua, 5 palvelinfunktiota
• 142 automaattista testiä ja 64 erillistä testiä tietokannan käyttöoikeussäännöille

Nämä ovat itse kirjaamiani lukuja yhdestä projektista. Vertailuryhmää ei ole, joten ne eivät kerro, kuinka paljon nopeampaa tämä oli kuin sama työ ilman mallia. Oma arvioni on, että ero oli suuri, mutta se on arvio eikä mittaus.

Yksi asia luvuista on silti täsmällinen. Willisonin rajaa vasten mitattuna tämä ei ollut vibe-koodausta. Katselmoin muutokset. Päätin itse tietomallin, käyttöoikeudet, mitä testataan ja mitä ei rakenneta lainkaan.

Kerron tämän siksi, että juuri tällaiset luvut kiertävät verkossa otsikolla "rakensin sovelluksen tekoälyllä". Luvut voivat olla totta. Otsikko on silti harhaanjohtava.

Mitä tutkimus sanoo tuottavuudesta

Yhtä kerrointa ei ole, ja se on tämän kohdan tärkein havainto. Tulokset riippuvat tehtävästä, työkalusta, koodikannan tuttuudesta ja siitä, mitä ylipäätään mitataan.

Koodausaktiivisuus kasvaa paljon enemmän kuin julkaisut. Toukokuun 2026 NBER-työpaperissa yhdistettiin yli 100 000 GitHub-kehittäjän toiminta heidän tekoälytyökalujensa käyttötietoihin. Kaltaistetussa tapahtumatutkimuksessa automaattisen täydennyksen, vuorovaikutteisten agenttien ja itsenäisten agenttien käyttöönottoon yhdistyivät commit-määrässä noin 40, 140 ja 180 prosentin kumulatiiviset estimaatit. Itsenäisten agenttien kohdalla vastaava estimaatti oli 50 prosenttia projektien määrässä ja 30 prosenttia varsinaisissa julkaisuissa. Neljän sovelluskaupan aineistossa uusien sovellusten määrä kasvoi kohtalaisesti, mutta kokonaiskäyttö ei kasvanut lainkaan.

Tutkijat kutsuvat ilmiötä heikoimman lenkin hypoteesiksi: tuotantoketjun inhimilliset pullonkaulat vaimentavat vahvan tuottavuushyödyn. Kyseessä on havainnoiva asetelma eikä satunnaistettu koe. Tulos on yhdenmukainen tässä jutussa kuvatun ilmiön kanssa, mutta se mittaa GitHub-aktiivisuutta ja julkaisuja, ei suoraan kustannuksia tai käyttäjäarvoa.

Satunnaistetuissa kokeissa tehtäviä valmistui enemmän. Kolmessa satunnaistetussa kenttäkokeessa Microsoftilla, Accenturella ja eräässä suuryrityksessä oli yhteensä 4 867 kehittäjää. Aineistot yhdistettynä koodiavustimen käyttö lisäsi valmistuneita tehtäviä 26,08 prosenttia, ja hyöty oli keskimäärin suurempi kokemattomilla kehittäjillä. Yksittäiset kokeet olivat kuitenkin meluisia, ja kyse oli koodintäydennysavustimista eikä vuoden 2026 agenteista.

Koordinointi hidastuu. Avoimen lähdekoodin projekteja koskevassa tutkimuksessa Copilotin käyttö lisäsi projektitason koodikontribuutioita 5,9 prosenttia ja osallistuvien kehittäjien määrää 3,4 prosenttia. Samalla koordinointiin kuluva aika kasvoi 8 prosenttia. Kokonaisvaikutus oli positiivinen, mutta huomaa mitä mitattiin: kontribuutioita, ei toimitettua arvoa.

Kokeneet eivät automaattisesti hyödy eniten. METR:n kokeessa 16 kokenutta avoimen lähdekoodin kehittäjää työskenteli omissa, vuosia tuntemissaan projekteissa. He olivat alkuvuoden 2025 työkalujen kanssa 19 prosenttia hitaampia kuin ilman. Tutkijat pitävät tulosta tilannekuvana yhdestä asetelmasta eivätkä yleisenä lakina, ja työkalut ovat kehittyneet sen jälkeen.

METR jatkoi koetta uudemmilla työkaluilla ja julkaisi helmikuussa 2026 uudet luvut. Ne olivat edelleen hidastumisen puolella, alkuperäisistä kehittäjistä jatkaneilla 18 prosenttia ja uusilla rekrytoiduilla 4 prosenttia, mutta kummankin luottamusväli ulottuu nopeutumisen puolelle. Tutkijat pitävät omaa estimaattiaan epäluotettavana. Osallistujien rekrytointi ja mukana pysyminen on vaikeutunut, ja kyselyssä 30–50 prosenttia kehittäjistä kertoi jättäneensä joitakin tehtäviä ilmoittamatta, koska ei halunnut tehdä niitä ilman tekoälyä. Koe jää siis järjestelmällisesti paitsi niistä kehittäjistä, joiden odotukset tekoälyn hyödystä ovat myönteisimmät. Tutkijoiden oma arvio on, että todellinen hyöty on mitattua suurempi, mutta sitä ei tästä aineistosta voi sanoa. Aineisto on siis heikkoa näyttöä vaikutuksen nykyisestä koosta.

Kokonaiskuva on juuri se, mistä tämä juttu kertoo. Koodausaktiivisuus ja valmistuneiden tehtävien määrä kasvavat joissakin asetelmissa mitattavasti. Se, mitä toimitetaan valmiiksi asti, ei välttämättä kasva samassa suhteessa.

Portaikko, jota ei näy ulospäin

Seuraava malli on oma havainnollistava jäsennykseni eikä alan standardi. Todellisuudessa vaiheet menevät limittäin ja kulkevat edestakaisin. Malli on tässä siksi, että se tekee näkyväksi yhden asian: ohjelma ei siirry tilasta "ei ole" tilaan "on" yhdellä askeleella.

1. Idea. Mitä ongelmaa ollaan ratkaisemassa ja kenelle.

2. Määrittely. Mitä ohjelma tekee, kenelle ja millä ehdoilla. Tästä lisää alempana.

3. Toimivuuden osoitus. Englanniksi proof of concept. Kysymys on kapea: onnistuuko tämä ylipäätään?

4. Demo. Eri asia kuin edellinen. Toimivuuden osoitus vastaa tekniseen kysymykseen, demo on tehty näytettäväksi ihmiselle ja saa olla kulissi.

5. Pienin julkaisukelpoinen tuote. Englanniksi MVP. Sen tarkoitus on testata oletus asiakkaasta tai markkinasta oikealla palautteella. Se ei määritelmällisesti vaadi kirjautumista tai mitään yksittäistä ominaisuutta. Se tarvitsee juuri ne turvallisuus- ja luotettavuusominaisuudet, joita sen todellinen käyttötapa edellyttää, eikä enempää.

6. Julkaisu. Kestääkö tämä sen, että käyttäjä tekee jotain, mitä kukaan ei arvannut? Kaksi ihmistä painaa samaa nappia yhtä aikaa. Verkko katkeaa kesken tallennuksen.

7. Tuotteistaminen. Tähän kuuluu sekä liiketoimintatyötä että teknistä työtä: hinnoittelu ja sopimusehdot, mutta myös moniasiakkuus, laskutuslogiikka, mittarointi ja käyttöönotto.

8. Ylläpito. Kuka korjaa tämän kolmen vuoden päästä? Kirjastot vanhenevat, rajapinnat muuttuvat, tietoturva-aukkoja löytyy.

9. Asiakastuki. Kuka vastaa, kun se ei toimi, ja mistä hän tietää, mikä meni pieleen?

10. Käyttöpalvelu. Englanniksi operations. Joku valvoo, että palvelu on pystyssä, ottaa varmuuskopiot ja pitää kirjaa katkoista.

Läpileikkaavat vastuut

Nämä eivät ole portaikon askelmia vaan kulkevat kaikkien läpi alusta asti. Jos ne jättää loppuun, ne jäävät tekemättä.

• Tietoturva ja käyttöoikeudet. Suunnitellaan tietomallin kanssa, ei sen jälkeen.
• Tietosuoja ja sääntely. Henkilötietojen käsittely ratkaistaan ennen kuin niitä kerätään. Tekoälyasetuksen soveltuminen määräytyy muun muassa järjestelmän käyttötarkoituksen ja riskiluokan sekä oman toimijaroolin perusteella, joten nämä on tiedettävä ennen rakentamista.
• Saavutettavuus. Jälkikäteen korjaaminen voi vaatia merkittäviä rakenteellisia muutoksia käyttöliittymään.
• Ylläpidettävyys. Rakenne, jota ei voi muuttaa, on päätetty ensimmäisenä päivänä.

Missä kohtaa tekoäly lyhentää eniten

Seuraava on oma arvioni, ei mittaustulos.

Arvion ydin on tämä: vaikutus on suurin siinä osassa, joka oli ennestäänkin nopein. Toimivuuden osoitus ja demo ovat tyypillisesti olleet halpoja verrattuna siihen, mitä tulee jälkeen. Kun ne halpenevat lisää, ero näkyvän ja näkymättömän työn välillä kasvaa.

Miksi osaaminen ratkaisee edelleen

Tutkimus ei osoita, että kokeneet saisivat aina suuremman nopeushyödyn. METR:n asetelmassa juuri kokeneet hidastuivat tutuissa projekteissaan, ja satunnaistetuissa kenttäkokeissa hyöty oli keskimäärin suurempi kokemattomilla. Tulos vaihtelee tehtävän, työkalun, koodikannan tuttuuden ja mittarin mukaan, joten yhtä suuntaa ei voi olettaa kummallekaan ryhmälle.

Osaaminen vaikuttaa siis johonkin muuhun kuin kirjoitusnopeuteen. Se vaikuttaa siihen, pystyykö tekijä arvioimaan arkkitehtuuria, turvallisuutta, puuttuvia vaatimuksia ja tuotoksen ylläpidettävyyttä. Näitä mallin tuotos ei itsessään takaa.

Tästä seuraa vibe-koodauksen kova reunaehto. Kun koodia ei katselmoida, poistuu se kohta, jossa arviointi ennen tapahtui. Vastuu ei siirry koneelle. Se jää sille, joka hyväksyy ohjelman ja ottaa sen käyttöön, riippumatta siitä onko ketään nimetty.

Missä riski oikeasti istuu

Koodissa

Käyttöoikeudet. Kuka näkee kenen tiedot. Tämä on helppo saada näyttämään toimivalta, koska omilla tunnuksilla testattaessa kaikki näyttää oikealta.

Tietomalli. Se, miten tiedot on järjestetty, voi olla yksi kalleimmista muutoksista, erityisesti sen jälkeen kun tuotantodataa on kertynyt ja integraatioita on rakennettu.

Hiljaiset virheet. Tallennus epäonnistuu, mutta käyttöliittymä näyttää onnistuneelta.

Kertyvää korjausvelkaa kutsutaan tekniseksi velaksi. Tekoäly ei poista sitä vaan nopeuttaa myös sen syntymistä.

Agentissa

Tämä on vuoden 2026 olennaisin lisä, ja se jää usein kokonaan pois keskustelusta. Työkaluilla varustettu koodausagentti ei vain ehdota tekstiä. Se voi sille annettujen oikeuksien puitteissa lukea ja muuttaa tiedostoja, suorittaa komentoja, asentaa paketteja ja käyttää verkkoa sekä lukea tehtävänkuvauksia ja verkkosisältöä. Riski ei siis ole vain huono koodi vaan myös se, mitä agentti tekee ajaessaan.

• Salaisuudet ja lähdekoodi voivat päätyä mallipalvelun käsiteltäviksi tai vuotaa työkalukutsujen kautta, jos agentilla on pääsy ympäristömuuttujiin ja avaintiedostoihin.
• Epäsuora kehoteinjektio tehtäväkuvauksista, dokumentaatiosta ja verkkosivuilta. Agentti lukee ohjeensa ja käsittelemänsä aineiston samasta tekstivirrasta.
• Liian laajat oikeudet tiedostoihin, verkkoon ja tuotantoympäristöön.
• Haitalliset riippuvuudet ja odottamattomat sivumuutokset, joita kukaan ei pyytänyt.
• Testien tai turvakontrollien muuttaminen samalla, kun agentti "korjaa" toteutusta. Tämä on erityisen ikävä, koska se saa mittarin näyttämään vihreää.

Nämä eivät ole yksittäisen kirjoittajan huolia. OWASP käsittelee agenttisovellusten riskit omana luettelonaan, jonka kärjessä ovat agentin tavoitteen kaappaus sekä identiteetin ja oikeuksien väärinkäyttö.

Vastalääke on sama kuin muussakin turvallisuussuunnittelussa: agentti ajetaan eristetyssä ympäristössä, sille annetaan vain tehtävän vaatimat oikeudet, kaikki muutetut tiedostot käydään läpi, eikä sillä ole suoraa pääsyä tuotantoon tai salaisuuksiin.

Seitsemän käytäntöä, jotka pitävät vauhdin kasassa

Huomaa jutun rakenteesta yksi asia. Kaikki alla oleva siirtää työtä pois kapeasta vibe-koodauksesta kohti katselmoitua työtä. Se on tarkoitus. Kysymys ei ole siitä, saako mallia käyttää, vaan siitä, miten sen nopeus saadaan ilman että vastuu jää nimeämättä.

Kuusi seitsemästä on käytäntöjä, jotka olivat olemassa ennen tekoälyä.

1. Määrittely kirjoitetaan ennen kuin malli käynnistetään.

Malli tai agentti voi lähteä rakentamaan yhden lauseen ohjeesta kysymättä riittäviä tarkennuksia. Se tekee kertomatta jääneet päätökset puolestasi, hiljaa ja yleensä nopeimman valmistumisen suuntaan. Määrittely on paikka, jossa nuo päätökset tehdään itse.

Toiminnallinen määrittely kertoo, mitä ohjelma tekee ja kenelle: ketkä sitä käyttävät, mitä kukin rooli saa nähdä ja tehdä ja mitä tapahtuu, kun jokin menee pieleen. Reunatapaukset ovat tässä tärkeämpiä kuin päätoiminnot: oman kokemukseni mukaan päätoiminnot osuvat useammin kohdalleen myös ilman erillistä ohjeistusta.

Tekninen määrittely kertoo tietomallin, käyttöoikeudet, sen, mikä ajetaan missäkin ja sen mitkä osat pitää pystyä vaihtamaan myöhemmin. Nämä ovat kalleimmat päätökset muuttaa jälkikäteen.

Käyttöliittymän luovutuspaketti kannattaa tehdä samaan aikaan: näkymät, tilat, värit, typografia, välistykset, tyhjät tilat ja virheilmoitukset. Ilman sitä malli keksii visuaalisen kielen uudelleen joka näkymässä. Myös tämä sivusto rakennettiin sellaisen paketin pohjalta.

Mallia voi käyttää määrittelyn kirjoittamiseen, ja siinä se on hyödyllisimmillään haastattelijana: pyydä sitä kysymään, mitä olet jättänyt kertomatta. Vastaukset ovat silti sinun.

2. Dokumentaatio pidetään ajan tasalla koko ajan, ei lopuksi.

Tämä on kääntynyt päälaelleen. Ennen dokumentaatio kirjoitettiin seuraavaa ihmistä varten, ja siksi sen sai lykätä. Nyt malli lukee sen ja käyttää sitä ohjeenaan, joten vanhentunut dokumentaatio ei ole pelkkä puute vaan aktiivinen virhelähde.

Kun koodia syntyy nopeammin kuin sitä ehtii lukea, dokumentaatio on usein ainoa paikka, johon aikomus jää talteen. Koodista näkee, mitä tehtiin. Se, mitä harkittiin ja hylättiin, näkyy vain siellä minne se on kirjattu: muistiinpanoissa, arkkitehtuuripäätöksissä, tehtäväkorteissa tai muutosten perusteluissa.

3. Versionhallinta, pienissä paloissa.

Versionhallinta merkitsee muistiin jokaisen muutoksen ja sallii palaamisen aiempaan hetkeen. Mallin kanssa se muuttuu kahdesta syystä välttämättömäksi.

Ensinnäkin malli voi muuttaa kymmeniä tiedostoja yhdellä kertaa, ja ilman versionhallintaa paluu ei ole toimenpide vaan toive.

Toiseksi versionhallinta näyttää muutokset erotuksena eli vain muuttuneet rivit. Se tekee katselmoinnista käytännössä mahdollista. Pienet, yhtä asiaa koskevat muutokset ovat luettavia. Yhden illan tuhannen rivin möykky ei ole.

4. Agentti eristetään ja sille annetaan vain tarvittavat oikeudet.

Tämä on edellä kuvattujen agenttiriskien käytännön vastine, ja se on käytännössä painavampi asia kuin mallin valinta. Aja agentti erillisessä ympäristössä, rajaa sen tiedosto- ja verkkopääsy, pidä salaisuudet sen ulottumattomissa, älä anna sille suoraa pääsyä tuotantoon ja käy läpi kaikki sen muuttamat tiedostot.

Valinnaisena lisänä toinen malli voi arvioida tuloksen eri tehtävänannolla. Se on lisäsignaali eikä varmistus. Sama malli tuottaa eri ajokerroilla eri tuloksia, eikä eri toimittajan malli takaa riippumatonta arviota. Ensisijaiset kontrollit ovat ihmiskatselmointi, testit, tyyppitarkastus, staattinen analyysi ja riippuvuustarkastus.

5. Testisuunnitelma tehdään ennen koodia.

Kyse ei ole testien kirjoittamisesta. Malli kirjoittaa testit nopeasti. Kyse on siitä, että päätät etukäteen, mikä ei saa koskaan mennä rikki, ja se päätös on ihmisen.

Kirjasin omassa projektissani kolme kohtaa ennen ensimmäistä riviä: sointujen jäsentäminen, sävellajin vaihto ja käyttöoikeussäännöt.

Testit nopeuttavat palautetta mutta eivät korvaa katselmointia. Ne osoittavat vain, että toteutus läpäisee ne tarkistukset, jotka testijoukkoon on osattu sisällyttää.

METR antoi maaliskuussa 2026 neljän ylläpitäjän arvioida 296 agentin tekemää muutosehdotusta, jotka kaikki läpäisivät SWE-bench-testit. Noin puolta niistä ei olisi hyväksytty päähaaraan sellaisenaan. Agentit eivät saaneet korjata työtään palautteen perusteella, joten kyse ei ole kyvyn ylärajasta. Se kertoo silti täsmällisesti, mitä läpäisty testi ei todista. Mitä suurempi muutoksen riski on, sitä riippumattomampia määrittelyn, testien ja toteutuksen tarkistusten pitää olla.

6. Käyttöliittymä katselmoidaan matkan varrella, ei lopuksi.

Mallia voi käyttää suunnittelun arvioijana: anna sille näkymä ja täsmälliset kriteerit, ja se voi ehdottaa mahdollisia puutteita, kuten epäjohdonmukaisia välejä tai heikkoja kontrasteja.

Ehdotus ei ole toteamus. Kuvasta ei voi luotettavasti päätellä kosketusalueita, semanttisia merkintöjä eikä ruudunlukijan käyttäytymistä, eikä mikään automaattinen työkalu yksin riitä osoittamaan palvelua saavutettavaksi. Näin sanoo myös W3C:n oma arviointiohje. Kriteerit ja johtopäätös ovat ihmisen.

Ajoitus ratkaisee. Jos katselmointi jää loppuun, korjaukset osuvat kohtiin, joiden päälle on jo rakennettu.

7. Modulaarisuus ja siirrettävyys päätetään alussa.

Ilman rajoitteita malli optimoi välittömän tehtävän valmistumista, joten yhden palveluntarjoajan omat kutsut leviävät helposti kaikkialle koodiin.

Vastalääke on pitää toimittajakohtaiset osat ohuen rajapinnan takana. Se pienentää muutoksen vaikutusalaa, mutta se ei tee vaihtamisesta muutosta yhdessä paikassa: tietokannat, tunnistautuminen ja maksupalvelut eroavat toisistaan myös merkitykseltään ja toiminnallisesti, eikä rajapinta poista niitä eroja.

Kyse ei ole periaatteellisesta riippumattomuudesta vaan hinnasta. Riippuvuuksia ei poisteta, ne valitaan, ja sama ajattelu pätee malleihin kuin suvereenissa tekoälyssä laajemminkin.

Milloin kevyt työtapa riittää

Vibe-koodaus sopii silloin, kun vahingon laajuus on rajattu ja muutokset ovat palautettavissa. Käyttäjien määrä tai kertakäyttöisyys eivät ole kriteerejä: viiden ihmisen sisäinen työkalu voi käsitellä palkkoja, ja kertakäyttöinen skripti voi tuhota tuhat tiedostoa.

Kysy näitä:

• Kuinka arkaluonteista dataa tämä koskee? Julkinen aineisto on eri asia kuin henkilötiedot.
• Mihin sillä on pääsy? Lukuoikeus yhteen hakemistoon on eri asia kuin tuotantotunnukset.
• Ovatko muutokset palautettavissa? Versionhallinta ja varmuuskopiot muuttavat vastauksen.
• Kuinka laajalle vahinko yltää, jos se menee pieleen? Sinuun, tiimiisi vai asiakkaisiin.
• Onko se eristetty? Erillinen ympäristö rajaa suurimman osan seurauksista.

Vastausten perusteella sama tehtävä voi olla kevyt tai raskas riippumatta siitä, kuinka pieneltä se näyttää.

Yksi käyttökohde kannattaa rajata pois. Koodin ymmärtämisen harjoitteluun tämä työtapa ei sellaisenaan sovi. Anthropicin 52 kehittäjän satunnaistetussa kokeessa tekoälyavusteinen ryhmä sai välittömässä osaamistestissä keskimäärin 50 prosenttia ja käsin koodannut ryhmä 67 prosenttia, eikä ryhmien pieni aikaero ollut tilastollisesti merkitsevä. Koe oli pieni ja lyhyt eikä kerro pitkän aikavälin oppimisesta, mutta se riittää siihen, ettei oppimista kannata laskea tämän työtavan hyödyksi.

Idean tappaminen halvalla on sitäkin arvokkaampi käyttö. Rakenna se päivässä, huomaa, ettei se toimi, ja heitä pois. Väärä idea voidaan parhaimmillaan hylätä päivissä eikä kuukausissa.

Milloin koodi katselmoidaan

Kun virheen hinta lankeaa jollekin muulle:

• asiakkaiden tai potilaiden tiedot
• raha, laskutus ja maksut
• turvallisuus ja fyysiset laitteet
• mikä tahansa, jonka pitää toimia vielä viiden vuoden päästä
• mikä tahansa, jota pitää pystyä puolustamaan viranomaiselle jälkikäteen

Tämä ei tarkoita, ettei tekoälyä saisi käyttää. Se tarkoittaa, että työtapa on taulukon oikea sarake.

Neljä kysymystä, ennen kuin demo luvataan tuotteeksi

1. Onko joku katselmoinut koodin? Jos ei, kyseessä on kokeilu riippumatta siitä, miten valmiilta se näyttää.
2. Mitä tapahtuu, kun käyttäjä tekee jotain, mitä ei arvattu? Pyydä näyttämään se, ei kertomaan.
3. Mihin agentilla oli pääsy sitä rakennettaessa? Tuotantotunnuksiin, asiakastietoihin, verkkoon?
4. Kuka korjaa tämän kolmen vuoden päästä ja millä rahalla? Ylläpito on budjettirivi, ei asenne.

Mitä tästä kannattaa jäädä mieleen

Yhdellä lauseella

Tekoäly on joissakin asetelmissa lisännyt koodin ja ohjelmistotehtävien tuotantoa huomattavasti, mutta hyödyn suuruus vaihtelee, ja NBER:n vuoden 2026 aineistossa kasvu vaimeni matkalla commit-määrästä projekteihin, julkaisuihin ja sovelluskauppojen kokonaiskäyttöön, joten nopeasti syntynyt demo ei yksin osoita tuotteen valmiutta tai käyttäjäarvoa.

Sidonnaisuus

Yllä kuvattu pilottisovellus on oma projektini eikä myynnissä. Luvut ovat itse kirjaamiani eikä niitä ole ulkopuolisesti varmennettu.