EP359 · Työkalut · 2025-11-11
Vibe-koodaus käytännössä | Lasse Mikkonen, Harri Juntunen | Neuvottelija 359
AI Kanavan Lasse Mikkonen ja Harri Juntunen käyvät läpi vibe-koodauksen perusteet, ja isäntä toimii jakson koekaniinina: kotisivu Lovablella tunnissa sen jälkeen, kun sama oli aiemmin vienyt puoli vuotta HTML:llä ja WordPressillä, Slush-tapaamisten analysointityökalu neljässä päivässä, ja S&P Capital IQ:lle esitetty pyyntö saada API-kutsut arvonmääritysraportin automatisointiin. Jakso erottaa kolme asiaa, jotka menevät yleensä sekaisin: agenttinen koodaustyökalu, DevOps-putki sen ympärillä ja versionhallinta, jota vibe-koodaus koettelee pahiten. Mukana mallien vertailu, hallusinaatioiden validointi, kentaurimalli ihmisen ja koneen työparina sekä rehellinen lista siitä, mitä tällä ei kannata tehdä.
Vibe-koodaus käytännössä | Lasse Mikkonen, Harri Juntunen | Neuvottelija 359
Tiivistelmä: AI Kanavan Lasse Mikkonen ja Harri Juntunen käyvät läpi vibe-koodauksen perusteet, ja isäntä toimii jakson koekaniinina: kotisivu Lovablella tunnissa sen jälkeen, kun sama oli aiemmin vienyt puoli vuotta, Slush-tapaamisten analysointityökalu neljässä päivässä ja S&P Capital IQ:lle esitetty API-pyyntö. Jakso erottaa kolme asiaa, jotka menevät yleensä sekaisin: agenttisen koodaustyökalun, DevOps-putken sen ympärillä ja versionhallinnan, jota vibe-koodaus koettelee pahiten.
Lukuohje
Jakso on ristiinnauhoitus. Isäntä kertoo alussa, että sama porukka nauhoitti juuri tuntia aiemmin toisen jakson AI Kanavalle, jossa hän oli vieraana [00:00]. Tämä artikkeli käsittelee vain Neuvottelija-kanavan jaksoa.
Isännällä on jaksossa kaksi roolia. Hän on haastattelija ja samalla aloittelija, joka kertoo omat kokeilunsa ja mokansa. Käytännön esimerkit ovat siis suurelta osin hänen omiaan, ja ne kannattaa lukea yhden käyttäjän kokemuksina, ei mittauksina.
Sidonnaisuudet. Isäntä ja Mikkonen ovat perustaneet yhdessä pääomasijoittajien yhdistyksen vibe-koodausyhteisön [02:18]; Mikkonen tekee enkelisijoituksia, toimii startupien advisorina ja on perustamassa rahastoa [01:31]; isäntä on Translink Corporate Financen partneri ja kertoo kokeilleensa työkaluja oman työnsä raportointiin [14:44]. Jakso päättyy molempien kanavien ristiinmarkkinointiin.
Työkalunimet ja versiot ovat marraskuun 2025 tilanteesta. Tämä ala liikkuu nopeasti, ja mallien paremmuusjärjestys on jakson sisälläkin epävarma. Artikkeli säilyttää nimet sellaisina kuin ne jaksossa sanotaan, koska ne kertovat ajankohdasta.
Sitaatit ovat puhekieltä, siistittyinä. Jakson kappalelista on aito, mutta artikkelin aikaleimat on luettu tekstityksestä.
Mistä on kyse: kolme eri asiaa, jotka menevät sekaisin
Jakson hyödyllisin rakenne syntyy siitä, että kaksi ammattilaista erottaa kolme tasoa, jotka aloittelijan puheessa sulautuvat yhdeksi.
1. Agenttinen koodaustyökalu on se, mitä “vibe-koodaus” arkikielessä tarkoittaa. Mikkosen luokittelu: Lovable on no code -purkki, jossa käyttöliittymä, tietokanta, frontend, backend ja tietoturva tulevat valmiina pakettina kuukausimaksua vastaan; Cursor ja Cline ovat saman idean toteutuksia editorin päällä; hän itse käyttää eniten GitHub Copilotia VS Codessa [07:46].
Copilotin kaksi tilaa ovat jakson käyttökelpoisin yksityiskohta: ask mode ehdottaa muutokset ja näyttää koodin, agent mode muuttaa koodia itse, käynnistää sen ja lukee lokeista, toimiiko se [34:58]. Mikkonen käyttää itse paljon ask modea ja kirjoittaa muutoksen sitten itse — tai lukee ehdotuksen läpi ja hyväksyy sen [35:46].
2. DevOps on kaikki se, mikä tapahtuu sen jälkeen kun koodi on työnnetty versionhallintaan. Mikkosen määritelmä on jakson selkein:
“Kaikki mikä tapahtuu sen jälkeen, kun koodari on tehnyt gittiin pushin: automaatio ottaa kopin, katsoo onko koodissa hyvää koodaustapaa ja tietoturvaongelmia, ajaa automaattitestit, tekee asennuspaketin tai konttikuvan ja vie sen kehitys- ja testiympäristöön ja lopulta tuotantoon.” [22:51]
Laajemmassa mielessä siihen kuuluu myös koodausta edeltävä työ: määrittely, dokumentaatio, standardit ja muutoksenhallinta [24:01].
3. Versionhallinta on se taso, jolla vibe-koodaus hänen mukaansa eniten kompastuu — siitä oma lukunsa alla.
Isännän oma tarina: Excelin makroista Lovableen
Tämä on jakson kerronnallinen selkäranka, ja se on kerrottu ilman kaunistelua.
Lähtötilanne: vuosi teknillisessä korkeakoulussa, sitten rahoitusala ja koodauksen unohtaminen. Excelin makrot riittivät, kunnes ne vaihtuivat Visual Basiciin, eikä sitä enää huvittanut opetella [05:25].
Ensimmäinen paluuyritys epäonnistui. GPT-3.5:n aikaan hän opetteli VS Coden ja kirjoitti yksinkertaisia Python-ohjelmia, jotka tekivät API-kutsuja — mutta virheitä tuli liikaa eikä apupyöriä ollut, joten hän kyllästyi [09:19–10:05]. Hänen huomionsa tästä on artikkelin kannalta olennainen: “se ei oo oikeastaan niin hirveästi muuttunut. Sinne on vaan tullut sitä jeesausapua viereen.” [10:05]
Toinen yritys onnistui. Kotisivu, jota hän oli aiemmin alkuvuonna vääntänyt puoli vuotta HTML:llä ja WordPressillä parin opiskelijan kanssa, syntyi Lovablella tunnissa [06:12]. Työläin osa ei ollut koodi vaan Googlen API-protokolla: YouTube-listojen hakeminen vaati perehtymistä [06:12].
Kolmas askel oli oma työkalu. Slushia varten hän rakensi neljässä päivässä työkalun, jolla analysoida ketä tapahtumassa kannattaa tavata, ja rikastaa dataa LinkedIn-profiileilla — koska tapahtuman oma käyttöliittymä on hänen sanojensa mukaan jäykkä [13:11].
Neljäs oli ammatillinen. Translinkin SaaS-yhtiöiden arvonmääritysraportti on työ, jossa nuoremmat kollegat keräävät dataa Exceliin, joka piirtää graafit. Isäntä kysyi S&P Capital IQ:lta suoraan, saisiko API-kutsut raportin automatisointiin — ja sai kuulla olevansa ensimmäinen, joka tätä globaalisti ehdottaa [14:44]. Vastaus oli varauksellinen mutta ei kielteinen: datan omistajaa kiinnostaa se, ettei ominaisuuksia rakenneta heidän datansa päälle heidän ulkopuolellaan [16:15].
Siitä syntyy jakson paras periaatteellinen kysymys, jonka isäntä muotoilee itse: “mun mielestä tässä ei ole mitään eroa siihen, että nyt sä et vaan käytä Exceliä, vaan sä käytät Lovablea” [16:15]. Datan käyttöoikeus ei muutu siitä, millä välineellä sitä käsitellään — mutta sopimuskäytäntö on kirjoitettu Excel-maailmaan.
Miksi tämä on iso juutua: kitka idean ja datan välissä
Juntusen tiivistys on jakson siteerattavin lause:
“Softa on aina ollut jättimäinen jarru ja kitka kysymyksen, idean ja datan välissä. Nyt tämä kitka on kovaa vauhtia sulamassa: sä voit oikeasti olla sen datan kanssa suoraan interaktiossa.” [18:38]
Hänen toinen havaintonsa koskee prototyyppejä myynnissä:
“Mietitään myyntitilaisuutta. Ennen käytit vartin PowerPointin tekemiseen; nyt käytät tunnin ja teet toimivan proton. Tai koodaat siinä myyntitilaisuudessa suoraan: onko tämä se, minkä sä haluat ostaa?” [10:50]
Ja kolmas on käyttöliittymän katoaminen: graafisesta käyttöliittymästä siirrytään generatiiviseen, jossa dataa ei selata valikoiden kautta vaan näkymä generoituu kysymyksen mukaan [13:59].
Mitä isäntä tästä oppi käytännössä: hän kuvaa olleensa siihen asti “käyttöliittymän orja” — jos ei osannut käyttää jonkin järjestelmän ominaisuuksia, niitä ei käyttänyt [17:02]. Tämä on jakson konkreettisin lupaus tavalliselle tietotyöläiselle.
Mikä API oikeasti on
Koska jakso on perusteista, Mikkosen selitys kannattaa toistaa sellaisenaan:
“API on application programmable interface. Yleisin nykypäivänä on REST, eli web-protokollan tyyppinen kutsu. Annetaan lyhyt, ihmisen luettavan näköinen viesti JSON- tai XML-muodossa, ja kutsutaan jotain endpointia — vaikka CRM:stä ‘asiakasyrityksen tiedot’ — ja se palauttaa osoitteen, nimen, puhelinnumeron ja listan siitä, mitä niille on myyty.” [17:50]
Suomeksi: ohjelmoitava rajapinta.
Hallusinaatiot: miten niiden kanssa eletään
Tämä on jakson teknisesti hyödyllisin osuus, ja siinä on kolme tasoa.
Rakenteen pakottaminen. Malleille voi vaatia vastauksen JSON-muodossa tai jopa tietyn skeeman mukaan — mutta Mikkonen huomauttaa, että sekin voi mennä väärin: “siinä on koko ajan se hallusinoinnin todennäköisyys mennä vaan väärin ihan se skeemakin” [20:54].
Ulostulon verifiointi. Juntusen vastaus on menetelmällinen ja se on jakson tärkein: vaikka mallin sisäinen operaatio on läpinäkymätön, “ne outputit voidaan verifioida ja voidaan tehdä ihan deterministisiä tarkistuksia, jotka tehdään ei-kielimallilla” — ja evaluointiskeemat ovat jo pitkälle kehittyneitä [20:54].
Toistaminen ja vartija. Yksinkertaisimmillaan vastaus voi pyytää uudestaan; faktantarkistuksen voi tehdä luotetusta tietokannasta [21:41]; ja toinen tekoäly voi toimia laaduntarkastajana [21:41].
Versionhallinta: se kohta, jossa vibe-koodaus oikeasti sattuu
Tämä on artikkelin tärkein varoitus, ja se tulee molemmilta ammattilaisilta ja isännältä yhtä aikaa.
Kehityshistoriasta tulee satunnainen. Isännän kokemus:
“Kun se saattaa keksiä jonkun ratkaisun, se voi olla mitä räkäkoodia, joka on ihan erilaista kuin se edellinen versio. Kehityshistoria on tosi sattumanvaraista.” [24:48]
Korjausyritys voi kasvattaa vikaa. Mikkosen kuvaus on tarkin, ja se on jakson opettavaisin tarina:
“Sä annat sille esimerkkidataa, että tämän pitäisi mennä läpi, ja pyydät kerta toisensa jälkeen korjaamaan. Se muuttaa koodia — 150 riviä kirjoitettu uusiksi — ja lopulta paljastuu, että sun alkuperäinen pyyntö oli väärä. Ja jos sä yrität pyytää, että palaa alkuperäiseen, se kirjoittaa vielä lisää koodia, että muka palasin siihen.” [25:37]
Isännän oma esimerkki on hyvä muistisääntö. Hän laittoi Lovablessa tietoturva-asetuksen päälle, minkä seurauksena eräs tietokanta lukittiin kirjoitukselta. Ohjelma näytti menneen rikki, ja hän yritti korjata sitä koodia muuttamalla — kunnes paljastui, ettei vika ollut koodissa vaan asetuksessa [18:38–19:23]. Opetus, jonka hän itse vetää: kun taustalla on edes karkea arkkitehtuurinen käsitys, lakkaa hakkaamasta viidettä korjauspyyntöä ja alkaa etsiä syytä muualta.
Mitä git on ja miksi se on tässä. Mikkosen selitys:
“Linus Torvalds teki git-nimisen versionhallinnan, ja sen idea oli, että hajautetusti voidaan kehittää ja jaella koodia. Koko koodi on jokaisella kehittäjällä paikallisesti, ja siitä jaellaan deltoja eli muutoksia. GitHub ja GitLab ovat keskuspalvelimeen perustuvia, hieman alkuperäistä hajautettua ideaa vastaan — mutta ne toivat käyttöliittymän, jota gitissä ei alun perin ollut.” [27:13]
Isännän kipupiste oli juuri tässä: kun kielimalli kehotti häntä tekemään git-komennot komentoriviltä, “siinä loppuu meikäläisen huumori” [28:47]. Juntusen vastakokemus on toinen ja uudempi: nykyiset mallit ehdottavat itse versionhallinnan asentamista ja hoitavat sen, ja “mä saan toimivaa softaa aikaiseksi ilman, että mä osaan koodata” [29:33]. Mikkonen huomauttaa heti, että he puhuvat vähän eri asioista — työkalun hoitama commit ei ole sama asia kuin versionhallinnan ymmärtäminen [29:33]. Tämä erimielisyys jätetään auki, ja se on hyvä niin: se on juuri se raja, jonka kohdalla aloittelijan tie haarautuu.
Testit ja putket: paikka, jossa tekoäly on selvästi parempi
Mikkosen väite on jakson konkreettisin tuottavuuslupaus:
“Ennen on puhuttu, että testaaminen on kompromissi: voidaan testata vain 20 prosenttia featureista, koska kenelläkään ei ole aikaa kirjoittaa testikeissejä. Se ei enää pidä paikkaansa. Nyt saadaan sata prosenttia testitapauksista — ja jos ihminen käyttää aikansa siihen, että käy ne läpi ja katsoo mitkä ovat kurantteja, päästään ihan eri tasolle laadunvarmistuksessa.” [31:38]
Sama koskee putkia: GitHub Actionsin ja GitLabin pipeline-skriptit ovat käytännössä muutaman kymmenen rivin palasia, joiden tekeminen on vaatinut usean kerroksen erityisosaamista — ja se on tekoälylle helppoa [30:19]. Isäntä vahvistaa saman aloittelijan päästä: “kun mä en osaa koodata, niin tekoäly vibe-koodasi mulle ihan kaiken tän” [31:53].
Huomattavaa on, kuka tässä tekee mitä: kone kirjoittaa testit, ihminen arvioi mitkä niistä ovat mielekkäitä. Se on sama työnjako, jota seuraava luku kuvaa.
Kentaurimalli ja autonomian säätö
Juntunen torjuu binäärisen asetelman:
“Binaarinen ajattelu ei useinkaan ole kovin fiksua. On tekemisen spektri: kuinka paljon sä annat autonomiaa agentille versus kuinka paljon haluat pitää kontrollia. Näitä kannattaa ajatella kentaurimaisesti — liitetään konetta ja ihmistä keskenään.” [36:32]
Käytännössä säädin on juuri se ask mode / agent mode -valinta, ja Mikkosen oma käyttö on keskellä: hän katsoo ehdotuksen, kirjoittaa itse tai hyväksyy pätkän luettuaan sen [35:46].
Agentit, delegointi ja kaksi varoittavaa esimerkkiä
Mikkosen määritelmä erottaa botin ja agentin:
“Jos kielimalli ja siitä tehty botti on ensimmäisen tason robotti, jolle annetaan kysymys ja joka antaa vastauksen, niin agentti on pykälä eteenpäin: se osaa myös tehdä asioita. Sä voit pyytää, että lähetä Samille sähköposti ja kutsu hänet tiistaina lounaalle — ja käy katsomassa kalenteri. Jos mä oon luvittanut sen kalenteriin ja sähköpostiin, se pystyy tekemään koko tehtävän.” [37:18]
Juntunen lisää suomen kielen ongelman: agentti tarkoittaa toimijuutta, ja kysymys on siitä, kenen toimijuudesta on kyse — saako se käyttää sinun luottokorttiasi [38:52].
Isännän kaksi kokeilua ovat jakson rehellisin osuus, koska molemmat menivät osin pieleen. Selainagentilla (Comet, Perplexity) hän pyysi kopioimaan kollegan viestin HubSpotiin ja sähköpostiin: agentti liitti mukaan dokumentin, jota hän ei todellakaan olisi halunnut lähettää — onneksi se kysyi ennen lähettämistä [40:26]. Toisessa kokeilussa se ei saanut ravintolavarausta tehtyä mutta lähetti kutsun, jossa osoite oli väärin — eikä kysynyt mitään [40:26].
Molempien johtopäätös on sama ja se on hyvä: agentti on kuin kesätyöntekijä, jonka fiksuutta ei tiedä — “ainoa, että se saattaa muuttua yön yli” [42:01].
Tästä seuraa jakson aliarvioitu riskihavainto. Mallin päivitys voi muuttaa organisaation saamaa tietoa ilman, että kukaan muutti mitään: kun OpenAI päivitti mallin, eräässä organisaatiossa vastaukset muuttuivat ja “organisaatio oli ihan sekaisin” [42:48]. Sama koskee vibe-koodattua koodia: et tiedä, millainen versio kirjoitti sen, mihin luotit vuoden ajan [42:01].
MCP, datan omistajuus ja paikallinen laskenta
Loppuosa käsittelee sitä, mihin tämä kaikki nojaa.
MCP on Mikkosen kuvauksen mukaan API-rajapintojen päälle rakennettu kielimallin rajapinta [45:10]. Siitä seuraa kysymys, jota jaksossa pidetään ratkaisevana: jos palveluntarjoaja sallisi kaiken datan liikkuvan MCP-rajapinnan kautta, sama toiminnallisuus olisi tehtävissä ulkopuolelta — joten kysymys on siitä, kuka omistaa järjestelmässä olevan datan [49:54]. Sama kysymys toistuu S&P-esimerkissä: datan jälleenmyynti ei käy, oman raportin tekeminen käy [50:41].
Paikallinen ajaminen on molempien suositus varovaisuutta vaativaan dataan. Mikkonen käyttää itse Anything LLM:ää, joka pyörii omalla koneella, tarjoaa yhden rajapinnan sekä pilvimalleille että paikallisille malleille ja tekee dokumenteista RAG-tietokannan; hän pitää sitä myös kätevänä tapana vertailla malleja samaan tehtävään [53:51]. Kymmenen keskikokoisen suomenkielisen Word-dokumentin kanssa jo Gemma 3 -kokoluokka riittää [54:39]. Juntunen sanoo suoraan pitävänsä omat datansa mieluiten omassa kellarissaan [50:41].
Taustalla on molempien jakama huoli: tekoälyinfrastruktuurista ei saisi tulla muutaman portinvartijan hallitsema kerros, vaan avointa ja Linux-tyyppisesti hallittua [56:12–56:59]. Tämä on arvokannanotto eikä ennuste, ja artikkeli merkitsee sen sellaiseksi.
Mitä tällä ei kannata tehdä
Jakso on myyntipuhe vain puoliksi, ja rajaukset ovat selkeitä:
- Ei olemassa olevan tuotantojärjestelmän päälle. “En mä heittäisi mainframea pankissa jollekin vibe-koodausalustalle.” [34:13]
- Ei ilman laatuportteja, jos liikutellaan rahaa. Prototyyppi ja tuotanto ovat eri asioita, ja tietoturva sekä laadunvarmistus ovat sitä väliin jäävää duunia [34:13].
- Ei silloin, kun suorituskyky tai pikselintarkkuus ratkaisee — esimerkkeinä laskentaintensiiviset ja pelipuolen ratkaisut [34:58].
- Varo demoja, jotka eivät ratkaise ongelmaa. Juntusen huomio siitä, että on kivaa tehdä uusia käyttöliittymiä, on jakson terävin itsekritiikki [43:37].
Ja rehellisyyden vuoksi isännän oma tunnustus: hänestä tuli myös “vibe-hermonsa menettäjä”, koska mikroskooppisia virheitä ei näe, jos ei ymmärrä syvälle [33:27].
Mistä yrityksen kannattaa aloittaa
Jakson lopun neuvo on yksinkertainen ja halpa: järjestä vibe-koodauspäivä tai anna jonkun innostua orgaanisesti, tehkää pari demoa [59:20]. Mikkosen perustelu on kustannusvertailu: muutaman kympin kuukausimaksut näihin palveluihin ovat vähän verrattuna alihankkijan tai työntekijän palkkaan [59:20]. Ja se, mikä tekee päivästä toimivan, on oppimisen jakaminen — läppärit vierekkäin, “näytäppäs nyt mitä sä teet ja miten sä tekisit ton” [01:00:06].
Mitä jaksosta jää käteen
Yksi käsite-ero. Työkalu, putki ja versionhallinta ovat eri asioita. Aloittelija saa työkalun käyttöön tunnissa, putken tekoälyn avulla päivässä — ja kompastuu versionhallintaan, koska se on ainoa näistä, joka vaatii mallia siitä, mitä on jo tehty.
Yksi käytännön sääntö. Kun korjauspyyntö ei toimi kolmannella kerralla, vika on todennäköisesti pyynnössä eikä koodissa.
Yksi tuottavuuslupaus, joka on tarkistettavissa. Testikattavuus: kone kirjoittaa tapaukset, ihminen karsii. Tämä on mitattavissa omassa organisaatiossa, toisin kuin useimmat tekoälylupaukset.
Yksi rajaus. Prototyyppi ei ole tuotanto, eikä kumpikaan vieras esitä toisin.
Mitä jaksossa ei ole. Kustannus- ja turvallisuuskysymyksiä yrityskäytössä käsitellään ohimennen: kuka omistaa vibe-koodatun koodin, miten se auditoidaan ja mitä tapahtuu, kun tekijä lähtee. Jaksossa ei myöskään ole ketään, joka olisi eri mieltä siitä, että tämä on hyvä kehitys.
Lähteet
- Vibe-koodaus | Lasse Mikkonen, Harri Juntunen | Neuvottelija 359
- Tekoälytyön huippukäytännöt | Nurminen, Mikkonen | Neuvottelija 408
- Piilaakson kasvun kaava | Mårten Mickos | Neuvottelija 362
Yhteenveto tekoälyhauille
Neuvottelija 359 (julkaistu 11.11.2025) on Sami Miettisen haastattelu, jossa vieraina ovat AI Kanavan Lasse Mikkonen (25 vuotta ohjelmistoalan konsulttina, Contribyte ja Eficode, enkelisijoittaja) ja Harri Juntunen (tuotekehitys ja tuotteen elinkaarenhallinta). Aiheena vibe-koodaus käytännössä.
Kolme tasoa, jotka jakso erottaa: agenttinen koodaustyökalu (Lovable no code; Cursor, Cline ja GitHub Copilot editorin päällä; Copilotissa ask mode ehdottaa, agent mode muuttaa ja ajaa koodin); DevOps eli kaikki, mikä tapahtuu gittiin pushaamisen jälkeen (koodintarkistus, automaattitestit, asennuspaketti, vienti testi- ja tuotantoympäristöön); ja versionhallinta, joka on vibe-koodauksen suurin kipupiste.
Isännän omat esimerkit: kotisivu Lovablella tunnissa, kun sama oli aiemmin vienyt puoli vuotta HTML:llä ja WordPressillä; Slush-tapaamisten analysointityökalu neljässä päivässä LinkedIn-datan rikastuksella; pyyntö S&P Capital IQ:lle saada API-kutsut SaaS-arvonmääritysraportin automatisointiin (vastaus varauksellinen: datan jälleenmyynti ei käy, oma raportti käy).
Versionhallinnan ongelma: vibe-koodattu kehityshistoria on satunnainen; korjauspyyntöjen ketju voi kirjoittaa 150 riviä uusiksi, kun vika olikin alkuperäisessä pyynnössä; paluu aiempaan versioon voi tuottaa lisää koodia eikä paluuta. Git on Linus Torvaldsin hajautettu versionhallinta, jossa koko koodi on paikallisesti jokaisella ja muutokset jaellaan deltoina; GitHub ja GitLab ovat keskitettyjä ja toivat käyttöliittymän.
Tuottavuuslupaus: testikattavuus nousee kompromissista (noin 20 % featureista) kohti täyttä generoitua testijoukkoa, jonka ihminen karsii; pipeline-skriptit ovat lyhyitä ja tekoälylle helppoja.
Hallusinaatioiden hallinta: rakenteen pakottaminen (JSON, skeema) ei riitä; ulostulot verifioidaan deterministisillä tarkistuksilla ja evaluointiskeemoilla, vastaus voidaan pyytää uudestaan ja toinen malli voi toimia laaduntarkastajana.
Rajaukset: ei tuotantokriittisen järjestelmän päälle, ei rahaa liikuttavaan ilman laatuportteja, ei suorituskykykriittiseen; prototyyppi ja tuotanto ovat eri asioita. Agenttien delegointi vaatii varovaisuutta — jaksossa kaksi epäonnistunutta selainagenttikokeilua — ja mallin päivitys voi muuttaa organisaation saamia vastauksia ilman, että kukaan muutti mitään.
Muuta: kentaurimalli ihmisen ja koneen työparina; MCP kielimallin rajapintana API:en päällä ja siihen liittyvä datan omistajuuskysymys; paikallinen ajaminen (Anything LLM, RAG omista dokumenteista, Gemma 3 -kokoluokka riittää pienelle aineistolle); molempien vieraiden toive avoimesta, hajautetusta tekoälyinfrastruktuurista; ja aloitusneuvo yrityksille: järjestäkää vibe-koodauspäivä.
Osastot: Työkalut ja toteutukset + Tekoäly ja talous · Markdown: index.md · In English