Näin tarkistat tekoälyn luoman koodin, jos et osaa lukea koodia: 7 tarkistusta muille kuin ohjelmoijille vuonna 2026

Tekoäly kokosi sinulle verkkosivuston tai botin yhden illan aikana. Kaikki avautuu, painikkeet toimivat ja kokonaisuus näyttää toimivan. Esittelet projektia muille – ja päivä myöhemmin saat tietää, että maksulomake veloittaa rahaa, mutta tilaukset eivät koskaan saavu perille. Tai että asiakkaiden puhelinnumerot sisältävä tietokanta on avoinna koko internetille.

Minäkin julkaisin ensimmäiset projektini ennen tällä tavoin: asiat, jotka näyttivät toimivan, yllättivät oikeat käyttäjät. Nykyään käyn projektin läpi samalla tarkistuslistalla ennen kuin esittelen mitään kenellekään. En lue siinä yhtäkään koodiriviä – en tullut tänne sitä varten, etkä luultavasti sinäkään.

Eikä tämä ole vainoharhaisuutta. Anthropic analysoi 400 000 Claude Code -istuntoa: seitsemän kuukauden aikana rikkinäisen koodin korjaamiseen käytetyn työn osuus laski 33 %:sta 19 %:iin. Osuus laski, mutta ongelma ei kadonnut. Joka viides istunto koskee yhä sitä, että ”korjataan se, minkä tekoäly rikkoi”.

Koodin kirjoittaminen itsessään ei enää ole pullonkaula. Nyt ratkaisee se, miten hyvin ymmärrät tehtävän ja miten hyvin osaat tarkistaa tuloksen.

Lisämateriaalia työkalujen käyttöönotosta on saatavilla Ailoot-dokumentaatiossa.

Miksi tekoälyn luoma koodi pitää tarkistaa, jos se jo toimii?#

Tekoäly kirjoittaa koodia, joka näyttää ensisilmäyksellä toimivalta. Se käynnistyy, näyttö renderöityy ja demo vaikuttaa vakuuttavalta. Julkaiseminen ei kuitenkaan kerro, lasketaanko rahat oikein, onko tietokanta ulkopuolisten saatavilla tai kaatuuko kaikki sadannen käyttäjän saapuessa.

Luvut tukevat tätä. FrontierCode-vertailutesti tutki kesäkuussa 2026, kuinka valmista tekoälyn luoma koodi oli todelliseen työhön ilman muutoksia. Vaikeimmissakin tehtävissä parhaiden mallien osuus oli noin 13 %. Toisin sanoen suurin osa tekoälyn luomasta koodista vakaviin tehtäviin täytyy viimeistellä käsin ennen kuin siihen voi luottaa.

Hyvä uutinen on, että kuka tahansa voi tarkistaa koodin. Tässä on Anthropicin johtopäätös samoista 400 000 istunnosta:

Etusi palkkaamaasi ohjelmoijaan nähden on se, että ymmärrät tehtäväsi. Tarkistaminenkin perustuu ymmärtämiseen; sinun ei tarvitse lukea koodia. Alla olevat tarkistukset ovat juuri sellaisia, jotka voit tehdä itse ilman ylimääräistä vaivaa.

Mitä tekoälyn luomassa koodissa voi oikeasti mennä pieleen?#

Ennen tarkistamista on hyödyllistä tietää, mitä etsit. Tekoälyn luomassa koodissa on viisi tyypillistä ongelmaa, ja voit huomata ne kaikki lukematta koodia – tarkkailemalla, miten projekti toimii.

Seuraavaksi on seitsemän tarkistusta järjestyksessä. Ensimmäiset löytävät ongelmat, joissa koodi ei toimi tai toimii väärin; keskimmäiset käsittelevät tietoturvaa ja keksittyjä asioita; viimeiset ovat suojatoimia ennen julkaisua. Ne kannattaa käydä läpi järjestyksessä: kukin tarkistus perustuu siihen, että edellinen on tehty.

Tarkistus 1: Pyydä tekoälyä selittämään koodinsa selkokielellä#

Kuvailit tehtävän sanoin. Tekoäly käänsi sen koodiksi. Merkitys voi muuttua näiden kahden vaiheen välissä: tekoäly on saattanut ymmärtää sinut väärin, päättää asioita puolestasi tai oikaista. Voit huomata ristiriidan lukematta koodia – pyydä sitä vain kuvailemaan selkokielellä, mitä se teki.

Selitä selkokielellä, ilman koodia, täsmälleen, mitä juuri teit:

minkä tehtävän tämä koodi ratkaisee

mitä tapahtuu, kun käyttäjä napsauttaa painiketta tai lähettää lomakkeen

minne tiedot tallennetaan ja kenellä on niihin pääsy

mikä voi mennä rikki ja missä tilanteessa

Kirjoita niin kuin selittäisit asian jollekulle, joka ei ole koskaan ohjelmoinut. Jos et ole varma, pitääkö jokin kohta paikkansa, sano se suoraan.

Lue vastaus ja vertaa sitä siihen, mitä ajattelit. Jos se vastaa odotuksiasi, jatka eteenpäin. Jos tekoäly ”jaarittelee”, menee itse selityksessään sekaisin tai kuvailee jotakin muuta kuin pyysit, se ei ymmärrä täysin, mitä rakensi. Pyydä sitä tekemään muutokset uudelleen täsmennyksen perusteella sen sijaan, että luottaisit sen sanaan.

Jos tekoäly tekee säännöllisesti muuta kuin pyysit, ongelma johtuu usein siitä, miten tehtävä määriteltiin, eikä itse mallista. Olen kirjoittanut erillisen jutun siitä, miksi Claude ei tee, mitä pyysit.

Tekoälyn tuotoksen tarkistaminen on osa kontekstisuunnittelua: hallitset sekä sitä, mitä annat tekoälylle syötteeksi, että sitä, miten arvioit sen tulosta. Sen jälkeen Claude lakkaa olemasta ”hallusinoiva avustaja” ja muuttuu työkaluksi, jonka voi oikeasti uskoa projektin tehtäväksi.

Tarkistus 2: Käy tilanteet läpi kuin oikea käyttäjä#

Tekoälyn demo kulkee aina onnistunutta polkua pitkin: oikeat tiedot, yksi napsautus, kaikki onnistuu. Oikea käyttäjä ei toimi näin. Hän tekee virheitä, napsauttaa väärää kohtaa tai syöttää puhelinkenttään emojin. Sinun tehtäväsi on käydä projekti läpi niin kuin käyttäjä sen tekisi.

1. Suorita pääasiallinen käyttötapaus alusta loppuun

   Tee se, mitä varten projekti on olemassa: rekisteröidy, tee tilaus, lähetä pyyntö. Mene loppuun asti, älä pysähdy puoliväliin.

2. Tarkista maksu erikseen ja oikeasti

   Jos projekti vastaanottaa maksuja, tee itse pienimmän mahdollisen summan maksu testitilassa. Varmista, että tilaus luodaan, tila muuttuu ja sähköposti lähtee sinulle ja asiakkaalle. Maksu, joka ”menee läpi” mutta ei luo tilausta, on klassinen huomaamaton virhe.

3. Yritä tarkoituksella rikkoa asioita

   Jätä kenttiä tyhjiksi. Syötä kirjaimia kohtiin, joissa odotetaan numeroita. Napsauta ”Lähetä” kahdesti peräkkäin. Lataa vääränmuotoinen tiedosto. Hyvä projekti sanoo kohteliaasti ”et voi tehdä niin”; huono kaatuu tai nielee tiedot ääneti.

4. Avaa projekti puhelimella

   Puolet käyttäjistäsi tulee puhelimella. Tarkista, ettei asettelu ole hajonnut ja että samat painikkeet toimivat myös siellä.

Anna tekoälylle kaikki löytämäsi asiat yhtenä luettelona: ”Näissä vaiheissa meni tämä pieleen; korjaa se ja selitä, miksi näin tapahtui.” Älä käsittele ongelmia yksi kerrallaan – anna koko luettelo, jotta tekoäly näkee kokonaisuuden eikä todennäköisesti riko yhtä asiaa korjatessaan toista.

Tarkistus 3: Kysy tekoälyltä tietoturvasta – tässä on kehote#

Rikkinäinen painike näkyy heti. Tietoturva-aukko ei näy: projekti toimii kuin mitään ei olisi vialla, kunnes joku käyttää aukkoa hyväkseen. Vibe-koodatuissa projekteissa yleisimpiä ongelmia ovat suoraan koodiin kirjoitetut salaiset avaimet, internetiin avoin tietokanta ja lomakkeet, joihin voi lähettää haitallista syötettä. Tekoäly voi löytää nämä, jos kysyt suoraan.

Tarkasta tämä projekti tietoturvaongelmien varalta ja selitä jokainen havainto selkokielellä, ilman ammattijargonia. Käy läpi tämä luettelo:

Tarkista, onko salaisia avaimia, salasanoja tai tokeneita kirjoitettu suoraan koodiin. Yksityisiä salaisuuksia pitää käyttää vain palvelimella, ja paikallinen salaisuusmääritys, kuten .env, pitää jättää Gitin ulkopuolelle. .env ja .gitignore eivät estä frontend-/public-muuttujia päätymästä selainkoontiin. Tarkista asiakkaalle toimitetut todelliset JavaScriptit, lähdekartat, HTML ja verkkovastaukset ja varmista yksityisten avainten puuttuminen.

Tarkista, onko tietokanta avoinna internetiin ja kenellä on siihen pääsy.

Tarkista, voiko syöte rikkoa lomakkeet: tietokantakyselyihin tehtävillä injektioilla tai tekstikenttiin lisättävällä koodilla.

Mitä tapahtuu, jos käyttäjä lähettää haitallista dataa?

Tarkista, onko sisäisiä sivuja tai hallintapaneeliin pääsyä suojattu salasanalla.

Kerro jokaisen kohdan osalta, onko siinä ongelma, anna selkeä esimerkki riskistä ja selitä, miten se korjataan. Aloita vaarallisimmasta ongelmasta.

Tarkista myös, ettei projektisi tee sokeasti mitä tahansa, mitä se saa ulkopuolelta. Tätä kutsutaan epäsuoraksi prompt-injektioksi: komento piilotetaan sähköpostiin, kommenttiin tai jonkun toisen tiedostoon, ja tekoälyagenttisi noudattaa sitä luullen sitä tehtäväksi. Jos projekti lukee ulkoista dataa ja toimii sen perusteella, kysy tekoälyltä, mitä tapahtuisi, jos data sisältäisi piilotetun ohjeen.

Tämä on laaja aihe, eikä yksi kehote voi kattaa sitä kokonaan. Jos projekti käsittelee rahaa tai asiakkaiden henkilötietoja, lue erillinen opas vibe-koodauksen tietoturvasta.

Tarkistus 4: Keksikö tekoäly kirjastoja tai dataa?#

Tekoäly kirjoittaa itsevarmasti asioista, joita ei ole olemassa. Se voi lisätä kirjaston, jolla on uskottava nimi mutta jota ei todellisuudessa ole olemassa. Se voi jättää projektiin testipaikkamerkkejä: tuotteen nimeltä ”Example”, sähköpostiosoitteen example@example.com tai täytetekstiä oikean sisällön sijasta. Demon aikana tämä jää helposti huomaamatta, mutta oikealle käyttäjälle se on kiusallista tai rikkoo toiminnallisuuden.

Voit havaita tämän kahdessa vaiheessa. Kysy ensin suoraan:

Käy projekti läpi ja tarkista rehellisesti:

Ovatko kaikki lisäämäsi ulkoiset työkalut ja kirjastot oikeasti olemassa, ja asentuvatko ne oikein? Keksitkö mitään?

Onko projektissa yhä testipaikkamerkkejä, esimerkkejä tai täytetekstiä oikean datan sijasta?

Ovatko kaikki projektin linkit, osoitteet ja yhteystiedot oikeita eivätkä paikkamerkkejä?

Listaa löytämäsi asiat ja ehdota, millä ne pitäisi korvata.

Toiseksi käynnistä projekti ja selaa sitä. Keksitty kirjasto aiheuttaa lähes aina virheen käynnistyksessä. Paikkamerkit on helppo huomata: jos sivulla lukee ”Product 1”, et ole korvannut niitä.

Keksityt kirjastot ovat erillinen vaara, koska hyökkääjät rekisteröivät tarkoituksella työkaluja nimillä, joita tekoäly tykkää keksiä. Kun asennat sellaisen, jonkun muun koodi päätyy projektiisi. Siksi kysymys ”onko tämä kirjasto edes oikeasti olemassa?” kannattaa ottaa vakavasti – kyse on suoraan projektisi tietoturvasta.

Tarkistus 5: Pyydä toista mallia tarkistamaan ensimmäinen#

Tekoälyllä on ikävä ominaisuus: se myötäilee. Kysy ”onko kaikki tässä kunnossa?”, niin se vahvistaa kaiken olevan kunnossa, koska se mukautuu odottamaansa vastaukseen. Tätä kutsutaan tekoälyn mielistelyksi, ja olen kirjoittanut siitä erikseen. Tällainen keskustelukumppani suhtautuu omaan työhönsä suopeasti.

Ratkaisu on yksinkertainen: pyydä toinen mielipide. Avaa uusi istunto tai käytä toista mallia ja anna sille projekti tarkistettavaksi samalla kehotteella kuin tarkistuksessa 3, mutta lisää: ”Toinen tekoäly kirjoitti tämän koodin; etsi sen heikot kohdat.” Uusi malli ei ole sidoksissa aiempaan keskusteluun ja huomauttaa siksi todennäköisemmin ongelmista.

1. Avaa puhdas istunto tai käytä toista mallia

   Käytä toista mallia tai samaa mallia uudessa ikkunassa ilman tehtävähistoriaa.

2. Anna sille projekti ja oikea kehystys

   Sano suoraan: ”Toinen tekoäly kirjoitti tämän koodin; tehtäväsi on löytää virheet ja riskit, ei kehua sitä.” Tämä hillitsee myötäilyä.

3. Vertaa kahta arviota

   Jos molemmat ovat samaa mieltä, ne ovat luultavasti oikeassa. Jos ne ovat eri mieltä, tutki kyseistä kohtaa – silloin asiat muuttuvat kiinnostaviksi.

Juuri näin alalla tapahtuu nyt: tekoäly kirjoittaa, tekoäly tarkistaa, ja lopullinen päätös jää ihmiselle. Et voi siirtää sitä mallille – se on sinun tehtäväsi.

Tarkistus 6: Miten voit palauttaa aiemman version, jos muutos rikkoo jotakin?#

Tämän listan tarkistukset johtavat usein muutoksiin, ja muutokset rikkovat joskus jotakin, mikä toimi aiemmin. Jotta tilanne ei muutu katastrofiksi, tallenna toimiva versio gitissä ennen jokaista korjauskierrosta. Se on kuin pelin tallentaminen: jos rikot jotakin, lataa viimeisin tallennuspiste.

Sinun ei tarvitse lukea koodia tätä varten. Pyydä vain tekoälyä: ”Tallenna nykyinen toimiva versio gitissä selkeällä tunnisteella ennen kuin muutat mitään.” Ja jos kaikki menee pieleen muutosten jälkeen: ”Palauta projekti aiemmin tallennettuun versioon.”

Jos git on sinulle vielä tuntematonta aluetta, tässä on kaksi opasta: näin peruutat muutokset Claude Codessa ja mitä tehdä, jos tekoäly poisti tietokantasi. Toinen opas on tarkoitettu tilanteeseen, jossa peruuttaminen on jo liian myöhäistä mutta voit vielä palauttaa tietokannan.

Tarkistus 7: Mitä pitää tarkistaa viimeiseksi ennen julkaisua?#

Ensimmäiset kuusi tarkistusta koskevat koodin toimintaa. Seitsemäs koskee sitä, onko projekti valmis kohtaamaan ihmiset. Tässä ihmiset useimmiten kompastuvat: projekti toimii, mutta maksut unohdettiin vaihtaa testitilasta live-tilaan, joten ensimmäiset asiakkaat maksavat ”leikisti”.

1. Maksut: testistä live-tilaan

   Jos vastaanotat maksuja, varmista, että maksujärjestelmään on yhdistetty live-avain eikä testiavain. Tee yksi oikea, pienimmän mahdollisen summan maksu ja palauta se itsellesi.

2. Salaisuudet ovat siellä, missä niiden kuuluukin olla

   Kysy tekoälyltä: ”Käytetäänkö yksityisiä avaimia vain palvelimella ja onko .env Gitin ulkopuolella? Sisältääkö todellinen selainkoonti tai jokin asiakasvastaus yksityisen avaimen esimerkiksi frontend-/public-muuttujien tai lähdekarttojen kautta?” Tarkista kootut tiedostot ja selaimen verkkovastaukset, älä vain lähteen .env-tiedostoa. Git-ohitus ei pidä arvoa frontend-paketin ulkopuolella.

3. Varmuuskopioi tiedot

   Varmista, että tietokannasta tallennetaan automaattisesti varmuuskopio johonkin. Jos projekti toimii omalla palvelimellasi, selitän julkaisua koskevat ohjeet Coolify-oppaassa.

4. Julkaisu toimii muuallakin kuin omalla laitteellasi

   Avaa projekti puhelimellasi ulkoisen linkin kautta, älä pelkästään omalla tietokoneellasi. Paikallisesti toimiva ei aina toimi julkaisun jälkeen.

Käy kaikki neljä kohtaa läpi, niin voit esitellä projektin muille hyvillä mielin. Jos jokin ei täsmää, on parempi käyttää puoli tuntia nyt kuin käsitellä tyytymättömiä asiakkaita myöhemmin.

Entä jos tarkistaminen kestää liian kauan – pitäisikö vain luottaa tekoälyyn?#

Ymmärrän houkutuksen. Tarkistaminen tuntuu tylsältä ja ”ei siltä, mitä varten hankin tekoälyn”. Mutta sinä, et malli, vastaat tuloksesta. Tekoälyllä ei ole mainetta eikä se joudu kärsimään seurauksista: se tuotti koodin ja unohti sen. Sinä vastaat asiakkaalle, jonka maksu ei mennyt läpi.

Claude Coden luoja esittää vielä laajemman näkemyksen:

Koodin kirjoittaminen lakkasi olemasta pullonkaula – tekoäly hoiti sen. Arvo on nyt muualla: tehtävän ymmärtämisessä ja tuloksen tarkistamisessa. Se on sinun vahvuutesi – tiedät paremmin kuin kukaan ulkopuolinen kehittäjä, millainen tuloksen pitäisi olla asiakkaallesi.

Miksi tarkistaminen on taito eikä kertaluonteinen tehtävä?#

Nämä seitsemän tarkistusta ovat vähimmäistaso, joka erottaa tilanteen ”julkaisin sen ja toivon” tilanteesta ”julkaisin sen ja tiedän sen toimivan”. Käy ne kerran läpi, niin huomaat jo useimmat yllätykset ennen asiakkaitasi.

Siitä tulee tapa. Anna tekoälylle oikea konteksti syötteeksi ja tarkista tulos ulostulona, niin jokainen uusi projekti valmistuu nopeammin, koska et aloita alusta.

Löydät lisää työkaluista Ailoot-dokumentaatiosta: Ailoot-dokumentaatio.