Onko Claude orjani vai olenko minä Clauden?

Vibekoodatessa en koodaa, vaan johdan. Kuvaan Claudelle mitä haluan rakentaa ja pilkon työn osiin. Tarkistan välituloksia ja ohjaan Clauden takaisin oikeaan suuntaan, jos se harhailee. Rooli muistuttaa enemmän rakennustyömaan johtajaa kuin timpuria. Johtajan ei tarvitse naulata itse, mutta hänen täytyy tietää mitä talosta on tulossa ja missä järjestyksessä se rakennetaan.

Tätä olen joutunut opettelemaan. Juomapeliä tehdessäni pyysin kaiken yhdellä kertaa ja Claude rakensi uutta vanhan päälle. Nyt etenen askel kerrallaan ja pyydän muokkaamaan olemassa olevaa ratkaisua uuden tekemisen sijaan. Minun täytyy silti pysyä kartalla siitä, mitä kone tekee. Tärkein taito ei ole tekninen vaan kyky kuvata ongelma niin tarkasti, että kone voi ratkaista sen.

Liiketoiminnan taustastani on tässä hyötyä. Annan Claudelle dataa analysoitavaksi ja keskityn itse siihen mitä luvut tarkoittavat. Rakennan myös työnkulkuja, jotka nopeuttavat esimerkiksi Kotivarakaupan tilausten lähettämistä. Aivotutkijat Minna Huotilainen ja Mona Moisala (2018, 66 %) kutsuvat tällaista ajattelua tulevaisuuteen orientoituvaksi laiskuudeksi, jossa työntekijä kysyy jatkuvasti voisiko tehtävän tehdä helpommin. Vibekoodauksen ansiosta vastauksen voi rakentaa samana päivänä.

Valmentaja ja tietokirjailija Immo Salo (2023) puolestaan vertaa tekoälyä auton navigaattoriin. Navigaattori piirtää kartan ja näyttää suunnan, mutta sitä sokeasti seuraava voi päätyä harhaan puutteellisen kartan tai koneen virhearvion takia. Siksi ihmissilmää tarvitaan yhä, jotta kokonaisvastuu jää kapteenille. (Salo 2023, 73, 75.)

Salon kirja ilmestyi nopeasti ChatGPT:n julkaisun jälkeen ennen nykyisiä koodaavia työkaluja. Navigaattorivertaus osuu minun tapaani hyvin. Olen kapteeni, joka ei osaa lukea karttaa. Tiedän minne haluan, mutta en pysty arvioimaan onko koneen valitsema reitti hyvä vai pelkästään toimiva.

Vastaukseni otsikon kysymykseen on siis molemmat. Minä päätän mitä rakennetaan ja miksi. Claude päättää miten se rakennetaan. Ja koska en ymmärrä koodia, olen sen ratkaisujen varassa. Jos ei ymmärrä mitä kone tekee, ei voi olla sille kriittinen eikä pyytää parempaa.

Työnjohtajan rooli näkyy arjessani konkreettisesti. Yhdessä ikkunassa Claude rakentaa uutta ominaisuutta, toisessa se korjaa edellistä virhettä ja kolmannessa tekee taustatutkimusta. Välilehtiä on auki kolmisenkymmentä. Minä hypin niiden välillä, kirjoitan sähköposteja ja välillä siivoan tai pelaan PlayStationia.Työntekoni on siis aika sekavaa.

Pidän tätä osittain multitaskauksena parhaimmillaan ja osittain epäjärjestelmällisyyteni huippuna. Huotilaisen ja Moisalan (2018) mukaan tunne multitaskauksesta on kuitenkin harhaa. Aivot eivät pysty tekemään tietoisesti montaa asiaa yhtä aikaa, vaan tarkkaavaisuus pomppii tehtävästä toiseen. Kirjoittajat kutsuvat tämän hintaa tehtävänvaihtokustannukseksi. työ hidastuu, virheet lisääntyvät ja aivot kuormittuvat. Tulos on parempi, jos ihminen saa itse päättää tehtävien järjestyksen. Vastaavasti pakkotahtinen vaihtaminen kesken sujuvan työn ärsyttää. (Huotilainen & Moisala 2018, 43–45 %.)

Tunnistan tämän, kun Claude keskeyttää minut aina valmistuttuaan. Tällöin vaihto tapahtuu koneen tahdissa eikä minun. Työ tuntuu hetkessä tehokkaalta, mutta illalla olen uupunut, vaikka olisin ”vain ohjannut”. Huotilaisen ja Moisalan (2018, 43 %) mukaan kuormaa voi keventää ulkoistamalla muistia listoihin ja muistutuksiin. Henkilökohtainen assistentti -sovellukseni tekee juuri tätä. Se kokoaa kalenterin, tehtävät ja deadlinet yhteen, lähettää minulle Telegramissa aamuisin koosteen ja sunnuntaisin se lähettää puhelimeeni viikkokatsauksen. Rakensin siis tekoälyllä työkalun, joka keventää tekoälyn aiheuttamaa kuormaa.

Toinen sivuvaikutus on harhailu. Kun idean ja toimivan prototyypin välissä on vain muutama keskustelu, aloitan projekteja, joita en aamulla suunnitellut. Huotilaisen ja Moisalan (2018) mukaan aivojen palkkiojärjestelmä palkitsee meitä oppimisesta ja aikaansaamisesta. Järjestelmä koukuttuu helpoimmin, kun palkkioita tulee tiheään ja ennakoimattomasti. (Huotilainen & Moisala 2018, 23–24 %.) Vibekoodaus toimii juuri näin. Jokainen kehote tuottaa jotain ja joskus tulos yllättää. Mekanismi selittää miksi työ tuntuu välillä pelaamiselta.

Paras esimerkki on rakentamani Toiminimi. Se on yrittäjän elämäsimulaatio, jossa rakennetaan ravintolabisnestä oikeaan Tampereeseen. Pelissä viikossa on 100 tuntia ja katteet pysyvät piilossa, kunnes pelaaja rakentaa itse keinot nähdä ne. Mekaniikka on suoraan Kotivarakaupasta, jossa opin ettei komealta näyttävä myyntigraafi kerro koko totuutta, kun katteet ovat pieniä.

Salo (2023, 78) varoittaa, että ideoiden kehittely tekoälyn kanssa voi tempaista mukaansa niin, että huomaa toteuttavansa ideaa ennen kuin arvaakaan. Juuri näin kävi. En vieläkään tiedä onko Toiminimi liiketoimintamahdollisuus vai hyvin perusteltua pelaamista. Opin sitä rakentaessani ohjaamaan isoa kokonaisuutta tekoälyn kanssa, mutta jokainen peliin käytetty tunti on pois asiakastyöstä ja opinnoista.

Oma kantani on, että ohjelmistoja rakentavat yhä useammin kaupallisten ja luovien alojen osaajat ja tietoteknikoiden rooli siirtyy rakentamisesta tarkastamiseen. Vahvimpana pidän kuitenkin ”kaupallista tietoteknikkoa” joka ymmärtää koodia, osaa vibekoodata ja jolla on jonkinnäköinen kaupallinen silmä. Uskon myös UI-suunnittelijoiden merkityksen kasvavan. Tekoälyn jälki on helposti geneeristä ja UI-suunnittelija osaa ohjata sitä omaperäisempään suuntaan.

Muutos näkyy jo työmarkkinoilla. Stanfordin yliopiston taloustieteilijät Erik Brynjolfsson, Bharat Chandar ja Ruyu Chen (2025) tutkivat yhdysvaltalaista palkanmaksudataa miljoonista työntekijöistä. Tekoälylle alttiissa ammateissa, kuten ohjelmistokehityksessä 22–25-vuotiaiden työllisyys on laskenut selvästi vuoden 2022 lopun jälkeen. Kokeneempien työllisyys samoissa ammateissa on pysynyt vakaana tai kasvanut. Lasku keskittyy tehtäviin, joissa tekoäly korvaa työtä, eikä sitä näy siellä missä tekoäly täydentää ihmistä. Kirjoittajat korostavat, että tulokset ovat varhaisia viitteitä eivätkä todista syy-yhteyttä. (Brynjolfsson ym. 2025.) Aineisto on yhdysvaltalaista, joten se ei suoraan kerro Suomen tilanteesta, mutta suunta on minusta uskottava.

Tulkitsen tuloksen niin, että ensimmäisenä korvautuu juuri se työ, jonka itse ulkoistan Claudelle eli rutiininomainen koodin kirjoittaminen. Kokemus ja kyky arvioida koodia eivät ole menettäneet arvoaan. Salon (2023, 75) mukaan tekoäly ei vie työtä, mutta sitä tehokkaasti käyttävä vie niiden työt, jotka eivät osaa tai halua käyttää sitä. Olen lähes samaa mieltä Salon kanssa. Työn vie koodari joka hallitsee sekä koodin, että tekoälytyökalut. En tunne yhtään IT-opiskelijaa joka vibekoodaisi, sillä kokemusteni mukaan he suhtautuvat siihen kriittisesti.

Kokeneiden etumatka ei kuitenkaan ole itsestään selvä. Tekoälyn riskejä tutkivan METR-organisaation tutkijat Becker ym. (2026) havaitsivat, että vuoden 2025 alussa tekoäly hidasti kokeneiden avoimen lähdekoodin kehittäjien työtä 19 prosenttia. Saman vuoden lopulla samojen kehittäjien työ nopeutui noin 18 prosenttia. Tutkijat pitävät uutta tulosta heikkona näyttönä, koska yhä useampi kehittäjä ei enää suostunut työskentelemään ilman tekoälyä. Kehittäjien omat arviot nopeutuksesta olivat epäluotettavia. Ajankäyttöäkään ei voinut mitata luotettavasti, kun kehittäjät käyttivät useita tekoälyagentteja yhtä aikaa ja tekivät odottaessaan muita töitä. (Becker ym. 2026.)

Ajattelin jo ennen päivityksen lukemista, että vuoden 2025 alun tulos kuvasi työkaluja, jotka ovat sen jälkeen kehittyneet nopeasti. Uskon myös, että aloittelijalla voi olla etulyöntiasema, koska hän ei takerru koodin yksityiskohtiin. Tämä on kuitenkin myös uhka, koska sama piirre tekee aloittelijasta sokean virheille.

Ajankäytön mittaaminen tuli vastaan omassa laskutuksessani. Henkilökohtaisen assistenttini rakentamiseen meni 20–50 tuntia, kun perinteiseltä kehittäjältä vastaavaan menisi arviolta 300 tuntia. Suomalaiselle HR-ohjelmistoyritykselle tein teknisen hakukoneoptimoinnin, tekoälyhakuoptimoinnin ja niihin liittyvät muutokset sivuston koodiin. Lisäksi rakensin yritykselle Claude-skillin, jolla se voi jatkaa työtä itse. Projektiin kului 36 tuntia, joista laskutin 30. Perinteisesti samasta työstä olisi laskutettu 60–90 tuntia. Aluksi en meinannut kehdata laskuttaa tunteja, joina Claude teki töitä, kun minä pelasin vieressä. Sitten kysyin isältäni, onko ne ok laskuttaa ja hän selitti minulle hyvin, että myyn arvoa, enkä käytettyjä tunteja. Tällöin tuntipalkkani pitäisi olla oikeastaan perinteistä tekijää korkeampi.

Huotilainen ja Moisala (2018) kyseenalaistavat koko työajan mittaamisen. Heidän mukaansa liiallinen keskittyminen työpaikalla vietetyn ajan mittaamiseen on haitallista sekä työntekijälle, että työnantajalle. Sen sijaan keskittyminen työn todelliseen tarkoitukseen, kuten asiakkaan ongelman ratkaisemiseen lisää tuottavuutta ja vähentää uupumusta. (Huotilainen & Moisala 2018, 66–69 %.) Isäni sanoi saman, mutta lyhyemmin. Hinnoittelen siksi jatkossa lähtökohtaisesti arvon mukaan. Jos käytän tuntihinnoittelua, tuntihinnan on oltava korkeampi ja perusteltu.

Jos perustaisin nyt ohjelmistoyrityksen. Palkkaisin yhden koodarin ja kaksi liiketoimintaosaajaa. Liiketoimintaosaajat rakentaisivat tekoälyn avulla ja koodari varmistaisi, että lopputulos on laadukas ja turvallinen. Malli vastaa sitä, miten näen tulevaisuuden kehitystyön jakautuvan.

Omissa projekteissani kukaan ei tarkista koodia. En ole jäänyt jumiin niin, että olisin tarvinnut koodaria, mutta minua pelottaa julkaista rakentamiani sovelluksia. En tiedä niiden tietoturvasta mitään, enkä voi luvata asiakkaalle mitään koodin laadusta. Assistenttini lukee sähköpostini ja tietää missä liikun. Ja asiakkaan sivustolle tekemäni muutokset ovat julkisessa verkossa kaikkien hakkereiden tavoitettavissa. Olen vain pyytänyt Clauden analysoimaan tietoturvaa ja korjaamaan. Siihen on luotettava ja niin luottaa tuhannet muutkin maailmassa.

Salon (2023, 73) navigaattorivertaus pätee tässäkin. Tieltä eksymisen huomaa, mutta koodin virhettä ei välttämättä huomaa lainkaan. Sovellus voi toimia jokaisessa testissäni ja silti sisältää tietoturva-aukon. Vibekoodauksen perusajatus, ettei koodia tarvitse lukea, on tämän takia samaan aikaan vapauttava ja vastuuton. Sen ansiosta liiketoiminnan opiskelija pystyy rakentamaan ohjelmistoja, mutta jos sovelluksesta vuotaa tietoja, vastuu on silti tekijällä eikä tekoälyllä.

Lisäksi olen riippuvainen työkaluista, joita en omista ja joiden hintaa tai saatavuutta en hallitse. Jos Claude lakkaisi toimimasta, en pystyisi ylläpitämään yhtäkään rakentamaani järjestelmää.

Vibekoodatuille sovelluksille pitäisi mielestäni olla pakollinen tarkastus tai sertifikaatti ainakin silloin, kun ne käsittelevät asiakastietoja. Näen tässä myös liiketoimintamahdollisuuden. Palvelun, jossa tietoturva-ammattilaiset tarkastavat vibekoodatun ohjelmiston ja sertifioivat sen.

Otsikon kysymykseen en löytänyt yhtä vastausta. Minä päätän suunnan ja Claude toteutuksen. Valta jakautuu sen mukaan kumpi ymmärtää asiaa paremmin. Liiketoiminnassa ja asiakkaan tarpeissa se olen minä, koodissa Claude. Siksi en pysty olemaan sille riittävän kriittinen.

Tulevaisuuden ohjelmistokehittäjä ei mielestäni ole joko tietoteknikko tai liiketoimintaosaaja. Kaupallisten ja luovien alojen osaajat rakentavat yhä enemmän. Tietoteknikoiden työ puolestaan painottuu enemmän arvioimiseen ja tarkistamiseen. Vahvin on silti se, joka hallitsee molemmat. Lähteet tasapainottivat innostustani. Brynjolfssonin ym. (2025) tulokset tukevat ajatusta, että rutiininomainen koodaus korvautuu ensin. Becker ym. (2026) taas osoittavat, kuinka nopeasti kuva muuttuu ja kuinka epäluotettava oma tunne nopeudesta on. Huotilaisen ja Moisalan (2018, 43 %) havainto multitaskauksen harhasta kertoo saman arjen tasolla.

Pohdinta on muuttanut suunnitelmiani. Aion opiskella ohjelmoinnin perusteita opintojen ohella, jotta opin tarkistamaan koodia enkä vain tuottamaan sitä. Jos kehitän jotain julkaistavaa, teen sen mahdollisesti yhdessä koodarin kanssa. Huomaan myös, että Proakatemiassa oppimani analysointi ja raportointi tekevät minusta jo nyt paremman työnjohtajan tekoälylle. Tavoitteenani on kasvaa itse siksi kaupalliseksi tietoteknikoksi, jota pidän tulevaisuuden vahvimpana tekijänä.