Agenttinen ohjelmistokehitys harrasteprojektin moottorina – case Polkuopas.fi

Agenttinen ohjelmistokehitys on ollut tänä vuonna kuuma peruna monissa keskusteluissa, koska se on täysin uudenlainen tapa rakentaa ohjelmistoja. Kokeneiden koodareidenkin fiilikset vaihtelevat, osa pitää sitä aivan liian rohkeana ja riskialttiina tapana tehdä asioita, toiset taas näkevät sen aivan uudenlaisena mahdollisuutena tehdä isoja ohjelmistoja pienillä tiimeillä.

Polkuopas.fi:n tarina on ehkä hieman toisenlainen, koska tekijänä ei ole koodari, vaan innokas harrastaja, jolla on kuitenkin taustaa ohjelmistoprojektien johtamisesta ja digimarkkinoinnin toteutuksesta. Simo Parviainen avaa Vierityspalkin haastattelussa sitä, miten Polkuopas.fi syntyi ja miten sitä kehitetään hänen toimestaan. Kyse on harrasteprojektista, mutta hyvin kunnianhimoisesta sellaisesta.

Lopputulos on kenen tahansa arvioitavissa osoitteessa polkuopas.fi. Palvelu on laaja ja monipuolinen karttapalvelu, josta voi löytää hyviä laavuja ja retkireittejä, ja näistä saa myös tarkat koordinaatit talteen, jotta maastossakin pystyy sitten suunnistamaan tarkasti.

Yksinkertaisimmillaan palvelu on karttapalvelu, jossa on rikas käyttöliittymä kartan navigointiin ja kohteiden tutkimiseen. Lisäksi palveluun voi kirjautua ja kohteita tallentaa itselleen muistiin. Taustalla on siis paljon sovelluslogiikkaa ja tietokantoja. Kirjautumisten ja käyttäjäkohtaisten tietojen tallentaminen vaatii myös huolellisuutta. Täten mistään ”peruswebbisaitista” ei todellakaan ole kysymys.

Tietokoneellakin käytettäessä sovellus toimii isolla ruudulla ja on hyvin ammattimaisesti tehty sovellus, vaikka ei olekaan maksullinen palvelu. Polkuopas.fi on siis käytännössä hyvin monipuolinen web-sovellus, joka vaatii myös taustasovelluksilta laatua ja suorituskykyä. Moni voisi sanoa, että eihän tällaista nyt voi pelkällä tekoälyllä koodata, varsinkaan jos ei ole koodaritaustaa itsellä. Noh, koodattu on, ja hyvin toimii.

Ehkä keskeisintä tässä casessa on ymmärtää, että Parviainen ei todellakaan tehnyt tätä yksin. Kuten hänen LinkedIniin jakama kuva hyvin kertoo, hänellä oli melkoinen tiimi apunaan. Tiimi tosin viittaa tässä tapauksessa agentteihin, joilla on jokaisella hyvin tarkkaan määritellyt roolit.

Onko tässä ohjelmistoalan tulevaisuus, yksi projektipäällikköihminen komentaa yli kymmenen agentin tiimiä? Vai pitäisikö puhua vain nykyisyydestä? Kuten tapana on sanoa, tulevaisuus on täällä, se vain ei ole laskeutunut vielä joka paikkaan.

Polkuopas.fi:n toteutus nojaa vahvasti MCP-yhteyksiin, joiden kautta agentit käyttävät kehityksen aikana suoraan tietokantaa, tikettijärjestelmää, analytiikkaa ja muita palveluita. Ihmisen rooli on avata yhteydet ja määrittää tavoitteet, ja agentit tekevät käytännön työn niiden kautta. Itse palvelu toki käyttää toimiessaan tavallisia rajapintoja.

Tällainen konsepti haastaa monia asioita, ei vähiten sitä miten integraatioita rakennetaan ja ylläpidetään. Polkuoppaan malli onkin monella tapaa ”all in”, eli kun agenttiseen kehitykseen on lähdetty, sitä on pyritty noudattamaan melko äärimmäisellä tavalla. Tällainen malli vaatii luottamusta agenttien toimintaan.

Palvelu rakentuu useista teknisistä komponenteista, ja taustalla on myös palveluita, jotka palvelevat palvelun kehityksessä ja johtamisessa. Haastattelussa Parviainen avaa tarkemmin eri komponenttien rooleja.

Vailla haasteita ei tietysti tällainenkaan tekeminen ole. Parviainen avaa haastattelussa toteutuksen aikana vastaan tulleita ongelmia. Agenttien käytös voi esimerkiksi muuttua, kun otetaan käyttöön uusi tekoälymallin versio. Valvontaa ja testausta tarvitaan paljon.

Eli vaikka koodaustyön tekevät agentit, tarvitaan tällaisessa harrastusprojektissakin paljon ihmistyötä, jotta valmista tulee. Pelkkä idea ei riitä tällaisessakaan tekemisessä vielä mihinkään toimivaan versioon.

Toki työmäärä on suhteellista, vaikka Parviainen arvioi käyttäneensä jopa useamman kuukauden tähän projektiin, voi työmäärää ajatella myös vähäisenä. Vastaavanlaisen palvelun toteutus isolla ihmistiimillä olisi varmasti vaatinut useamman kuukauden yhteistyötä ja kustannuksissa olisi puhuttu sadoista tuhansista euroista.

Tosin syntyy kustannuksia tekoälytiimistäkin ja kymmenistä eri taustapalveluista. Toistaiseksi polkuoppaan kohdalla puhutaan kuitenkin pienistä summista, suurin osa taustapalveluista pyörii vielä ilmaisversioilla. Tosin tässäkin on ehkä todettava, että näin ei välttämättä ole loputtomiin. Tällä hetkellä kilpailu on kovaa monella alueella, eikä vähiten tekoäly-yhtiöiden välillä. Joten tässäkin tapauksessa voinee sanoa, että palvelun toteutusta on tukenut epäsuorasti myös moni riskisijoittaja, joka mahdollistaa Clauden ja monien muiden työkalujen alhaisen hinnoittelun juuri nyt.

Joka tapauksessa, elämme ehdottomasti outoa aikaa, kun agentillinen ohjelmistokehitys mullistaa asioita, ja tekee sen vielä erittäin kustannustehokkaasti. Nyt on selvästi hyvä aika kokeilla asioita, kuten Polkuoppaan case hyvin havainnollistaa.

Vierityspalkin kysymyksiin vastasi Simo Parviainen.

1. Aloitetaan perusasioista: mikä Polkuopas.fi oikeastaan on, kenelle se on suunnattu ja mistä idea kumpusi? Miksi juuri tämä projekti sai sinut lähtemään AI-avusteisen koodauksen syvään päähän? Mikä on oma taustasi, oletko koodari taustaltasi vai enemmän liiketoimintaihminen?

Polkuopas on retkeilykartta koko Suomeen. Siellä on tällä hetkellä yli 20 700 kohdetta ja yli 10 000 reittiä, muun muassa laavuja, telttailupaikkoja, autiotupia, nuotiopaikkoja ja näköalapaikkoja. Niistä voi koota omia kokoelmia ja viedä ne GPS-laitteeseen. Palvelu on tarkoitettu kaikille retkeilijöille, myös niille, jotka retkeilevät lähimetsässä eivätkä Lapissa. Lähiretkeily on sekin retkeilyä.

Idea syntyi omasta tarpeesta. Olen innokas retkeilijä, vähintäänkin penkkiretkeilijä, ja ongelma oli aina sama. Miten omat merkinnät saa kulkemaan kätevästi mukana? Garmin-laitteiden ja reittipisteiden siirtelyn kanssa tuli tuskailtua sen verran, että päätin tehdä siihen ratkaisun itse.

Se on kuitenkin vain puolet totuudesta. Halusin myös kokeilla, miten pitkälle tekoälytyökaluilla oikeasti pääsee, kun kaikki osat ovat paikallaan. Tavoitteena ei ollut pelkkä sovellus, vaan myös sitä tukeva sivusto ja hakunäkyvyys. Siksi Polkuopas on verkkopalvelu eikä natiivisovellus, sillä halusin kokeilla optimointia myös sivustopuolella.

Taustaltani olen markkinoija. Olen työskennellyt pitkään digitaalisen markkinoinnin tehtävissä ja tehnyt aikanaan paljon verkkosivuprojekteja strategina ja projektipäällikkönä. Sitä kautta tiimin ja asiantuntijoiden merkitys on tullut selväksi. Kukaan ei osaa kaikkea itse, mutta on tiedettävä, keitä tarvitsee ja mitä heiltä kysytään.

Toistan nyt käytännössä samaa asetelmaa agenttien kanssa. Teen agenteista asiantuntijoita, konsultoin niitä ja toimin itse edelleen projektipäällikkönä ja strategina keskellä. Olen siis enemmän liiketoimintaihminen kuin tekninen ihminen. Lähden liikkeelle tavoitteista ja pyrin ymmärtämään kokonaiskuvan.

Ohjelmoida en kuitenkaan osaa, en lainkaan. En näe enkä ymmärrä kaikkea, mitä teen. Ymmärrän logiikan ja luotan pitkälti siihen, mitä tekoäly tekee, mutta koodia en pysty tarkastamaan. Tämä on jutun kannalta olennainen tieto, ja se selittää monta myöhempää valintaa.

2. Mitkä ovat mielestäsi palvelun parhaita toimintoja? Mistä toiminnosta tai ominaisuudesta olet eniten ylpeä?

Ykkönen on omat merkinnät ja niiden vienti käsilaitteeseen. Kartalle tehdään omia merkintöjä, niistä kootaan kokoelma, ja kokoelman voi ladata GPX-tiedostona laitteeseen tai avata suoraan Garmin Explore -sovelluksessa, jos laite tukee sitä.

Siitä olen ylpein ehkä siksi, että juuri sitä lähdin alun perin tekemään, ja se valmistui vasta lanseerauksen jälkeen. Rakensin siis sivussa kokonaisen karttasovelluksen ennen kuin tein sen alkuperäisen toiminnon. Sitä on mietitty paljon, ja nyt se toimii niin kuin ajattelin.

Kakkonen on yhteiset kokoelmat. Teet itsellesi kartan, merkitset siihen omia paikkoja ja kutsut ystävät samalle kartalle. Hekin voivat lisätä sinne omia merkintöjään, joten rakennatte yhdessä yhteistä kokonaisuutta. Kartta on vain teidän käytössänne tai kaikkien, joilla on linkki.

3. Kuvasit LinkedInissä rakentaneesi koko projektille ’oman käyttöjärjestelmän’ Claude Coden sisään. Miten tämä ajatus syntyi ja mikä oli se hetki, jolloin tajusit tarvitsevasi tällaisen keskitetyn ohjaamon yksittäisten työkalujen sijaan? Millainen se sinun ”ohjaamo” on käytännössä?

Ohjaamo oli itsessään yksi syy koko kokeiluun.

Olin aiemmin rakentanut pienempiä työkaluja omaan ja yrityksen käyttöön, mutta ne syntyivät aina irrallaan, ilman varsinaista prosessia. Kun perehdyin aiheeseen vähitellen tarkemmin, totesin, että aika on kypsä rakentaa oma käyttöjärjestelmä, eli yksi paikka, josta koko projektia ajetaan. Lähdin liikkeelle sprintti- ja tikettiajattelusta ja mietin, mitä kaikkea tarvittaisiin. Siitä edettiin oman agenttitiimin määrittelyyn, ja vähitellen mukaan tuli muuta, kuten analytiikka.

Käytännössä ohjaamossa on kolme kerrosta. Neljätoista agenttia, joilla kullakin on oma vastuualueensa: arkkitehti, frontend, backend, UX, copywriter, SEO, laadunvarmistus, juridiikka ja niin edelleen. Kahdeksan komentoa toistuville rituaaleille, kuten sprintin avaukselle ja sulkemiselle, ideasparraukselle, moniagenttiauditoinnille, viikkoanalytiikalle, valvomattomalle yöajolle ja itsenäiselle tuotantoajolle. Lisäksi muistikerros, johon kertyvät sekä pysyvät säännöt että se, mikä on juuri nyt kesken.

Komennot eivät syntyneet suunnittelupöydällä vaan tekemisen kautta. Kun huomasin tekeväni saman asian kolmannen kerran, siitä tuli komento. Se on halvin tapa tehostaa työtä, koska mitään uutta ei tarvitse keksiä. Riittää, että kirjaa ylös sen, minkä jo tekee.

Varsinainen oivallus tuli myöhemmin. Ohjaamo oli rakennettu Claude Codeen, ja se asui omalla koneellani. GitHub oli käytössä, mutta koko käyttöjärjestelmä ja repositorio olivat koneella. Jossain vaiheessa halusin siitä kannettavan version ja siirsin koko käyttöjärjestelmän pilveen GitHubin repositorioon.

Siitä syntyi ahaa-elämys. Nyt voin tehdä tätä käytännössä milloin ja missä tahansa, puhelimella tai kannettavalla, koska kaikki toimii selaimen tai Clauden oman sovelluksen kautta. Samalla kaikki agentit ja kaikki liitetyt palvelut ovat suoraan käytettävissä.

Claude on ollut tässä ainoa käyttöliittymä. Alussa se vaati jonkin verran määrittelyä, mutta kun se on tehty, työskentely on hauskaa.

4. Voitko avata käyttämääsi palettia tarkemmin, mitkä ovat työkaluja joita käytät tuotteen kehityksen johtamiseen ja ohjaamiseen? Mitkä ovat taas työkaluja ja sovelluksia joihin web-sovellus nojaa konkreettisesti?

Ohjauspuolella kaiken pohja on Claude Code. Muu rakentuu sen päälle.

Wispr Flow on sanelua varten. Kirjoitan toki myös, mutta suuri osa ideoista, toiminnoista ja pohdinnoista syntyy puhumalla. Se on listan yllättävin työkalu ja ehkä tärkein, koska se madaltaa kynnystä. Idea ei jää kirjaamatta sen takia, ettei näppäimistö ole käsillä.

Agentit purkavat sanelun ideoiksi ja muuntavat ne tiketeiksi. Tiketit menevät Jiraan, ja sprintin avauskomento nostaa niistä sprinttiin sopivat kokonaisuudet. Confluence on pitkä muisti, erityisesti projektin alusta, jolloin tehtiin laaja kilpailija- ja kohderyhmäkartoitus, positiointi ja brändi. Sinne palataan, kun pitää muistaa, mitä oltiin tekemässä ja miksi.

Claude Design on brändi-identiteettiä ja käyttöliittymää varten. Kaikki näkymät rakennettiin siellä, ja niitä on iteroitu matkan varrella. Kuvitukset syntyvät omalla skriptillä Geminin rajapintaa vasten, jotta sisällöille saadaan brändin mukaista kuvitusta.

Olennaista on, etteivät Jira, Confluence ja muut ole erillisiä käsityökaluja. Ne on kytketty samaan ohjaamoon MCP-yhteyksillä, eli Claude käyttää niitä suoraan.

Tuotantopuolella sovellus nojaa Supabaseen, jossa ovat tietokanta, kirjautuminen ja rajapinnat samassa paketissa. Kartta on MapLibre. Se on se yksittäinen kirjasto, joka tekee tästä karttasovelluksen: se piirtää karttatiilet, hoitaa zoomauksen ja panoroinnin ja näyttää tuhannet merkinnät kartalla niin, että selain jaksaa sen. Itse sovellus on tehty Next.js:llä, ja se ajetaan Vercelissä. Sähköpostit kulkevat Brevon kautta, ja karttatiilet tulevat avoimista lähteistä.

Mittaukseen ja hakuun käytän PostHogia analytiikkaan, Google Search Consolea hakudataan, Bing Webmaster Toolsia toisen hakukoneen seurantaan ja DataForSEO:ta hakusana-analyysiin. Hakusana-analyysin pohjalta sisällöt kirjoitetaan. Nekin on kytketty samaan ohjaamoon: en kirjaudu niihin erikseen, vaan kysyn Claudelta.

5. Kuinka paljon sinulla on mennyt aikaa tuon nykyisen polkuopas.fi-palvelun ensimmäisen version toteutukseen? Millaisia kustannuksia sinulle on tullut perustamisesta ja mitä palvelun käyttökustannukset ovat kuukaudessa suurinpiirtein?

Kalenteriaikaa on kulunut kuukausia. Aloitin keväällä, ja teen tätä pääosin iltaisin ja viikonloppuisin, sen verran kuin muulta ehtii. Sanelu auttaa, koska idean voi puhua talteen vaikka lenkillä. Tämä ei siis ollut yhden viikonlopun vibe coding -suoritus. Siihen kului pitkä aika, ja matkalla oli paljon opettelua. Kyse olikin opetteluprojektista, ja halusin tehdä sen kunnolla. Rakennan ja parannan palvelua edelleen koko ajan, eikä työ varmaan koskaan lopu.

Tunteina en osaa sanoa tarkasti. Kymmeniä tunteja, ehkä yli sata. On kuitenkin tärkeää sanoa, että agentit tekevät suurimman osan työstä. Minun osuuteni on arviointia, ideointia ja ohjeiden antamista, ja agentit hoitavat omat tehtävänsä sillä välin.

Ehkä seuraavat luvut kertovat enemmän kuin tuntimäärä. Sprinttejä on takana 76, tikettejä reilut 1 200, tietokantamigraatioita yli 190 ja automaattitestejä yli 11 000.

Kustannuksista suurin on Claude-tilaus. Aloitin pienimmästä, noin parinkymmenen euron tilauksesta, nostin sen jossain vaiheessa keskimmäiseen, ja se riitti yllättävän pitkälle. Nykyään minulla on suurin tilaus, mutta se johtuu siitä, että projekteja on useita. Yhteen projektiin pieninkin tilaus riittää tiettyyn pisteeseen asti, mutta suosittelisin vähintään keskimmäistä, koska tutkimusajot kuluttavat paljon.

Muu infrastruktuuri oli pitkään käytännössä ilmainen. Verkkotunnukset ja GitHub maksoivat noin kuusi euroa kuussa. Hosting, tietokanta, analytiikka ja sähköposti pyörivät ilmaistasoilla, ja niihin mahtuu paljon ennen kuin pitää alkaa maksaa. Elokuussa tietokanta ja hosting piti nostaa maksullisille tasoille. Pelkän Polkuoppaan infrastruktuuri maksaa nyt noin viisikymppiä kuussa, kun Claude-tilausta ei lasketa mukaan.

Kuvien generointi tapahtuu yksittäisillä rajapintakutsuilla ja on edullista. Lounaan hinnalla olen tuottanut satoja kuvia.

Markkinointiin on käytetty nolla euroa.

6. Käytät MCP-yhteyksiä paljon eri sovellusten välillä. Miten tämä on toiminut käytännössä? Olet varmaan pystyttänyt palvelut ja integraatioyhteydet kuitenkin manuaalisesti, ja luonut tarvittavat avaimet ja muut perusasiat, mutta onko sen jälkeen kaikki toiminut MCP-yhteyksien avulla? Oletko törmännyt rajoitteisiin tai yllätyksiin?

MCP-yhteydet ovat agenttisen rakentamisen tärkein yksittäinen asia. Ne ovat syy siihen, että tämä ylipäätään toimii.

Niistä on tullut myös valintaperiaate. Työkalu valitaan sen mukaan, onko siihen MCP-yhteys tai jokin muu rajapinta. Jos ei ole, työkalua ei käytetä. Se ei ole mieltymys vaan arkkitehtuuripäätös: jos ihmisen pitää käydä klikkaamassa jotain käsin, se kohta jää tekemättä.

Pystytykset, tilit ja asetukset on tehty käsin. API-avaimia ja tunnuksia on pitänyt luoda paljon, ja se on ollut raskasta. Avaimet säilytetään ympäristömuuttujissa eri paikoissa, koska lähdekoodiin niitä ei laiteta. Niiden tekeminen oli minulle täysin uutta, enkä rehellisesti sanottuna osannut tai ymmärtänyt sitä. Se oli yksi matkan tuskallisimmista vaiheista. Kun ne on kerran tehty, ne ovat kuitenkin valmiina. Välillä yhteydet katkeilevat ja pitää aloittaa uusi istunto tai kirjautua uudelleen, mutta suuri työ on tehty kertaalleen.

Yksi asia auttoi enemmän kuin mikään muu, ja sen voi kopioida kuka tahansa. Rakensin Claudeen protokollan, joka pakottaa sen kirjoittamaan selkokieliset vaiheittaiset ohjeet aina, kun minun pitää tehdä jotain itse. Ohjeessa pitää olla suora ja täydellinen osoite eikä pelkkä “mene asetuksiin”, numeroidut vaiheet, tarkat arvot kenttiin, se, mitä lokissa pitäisi näkyä onnistuessa ja epäonnistuessa, sekä yksi virhetilanne ja ohje siihen reagoimiseen. Se on ollut kullanarvoinen.

Yllätyksiä on ollut kahdenlaisia. Ensimmäinen on se, että Claude sanoo, ettei se pysty tekemään jotain. Kun vastaan, että kyllä pystyt, se toteaa olleensa väärässä ja tekee asian. Yleensä riittää, että on eri mieltä.

Toinen on mieluisampi. Alussa ajoin GitHubissa käsin koeajot aina, kun tietokantamuutoksia vietiin Supabaseen. Käynnistin niitä yksi kerrallaan, ja se vei paljon aikaa. Jossain vaiheessa kysyin, pystyisikö Claude tekemään tämän puolestani. Vastaus oli, että pystyy, kunhan muutama API-oikeus laitetaan kuntoon. Sen jälkeen suuri osa käsityöstä katosi prosesseista.

Sitä kannattaa kysyä useammin kuin kerran.

7. Kun keskustelet Clauden kanssa, miten huolehdit siitä, että se muistaa kaiken aiemmin tehdyn ja ehdottaa sinulle juuri sinun tilanteeseesi sopivia valintoja? Oletko tehnyt jotain erityisiä ”manifesteja” tai peruskirjoja projektillesi, joita ei saa olla huomioimatta? Tai onko sinulla joku erillinen arkkitehti-agentti, joka tarkistaa kaikki uudet tekniset päätökset tai avaukset?

Muisti on kahdessa kerroksessa, ja kerrosten työnjako on kirjattu sääntöön.

Pitkä muisti on Confluencessa ja tikettihistoria Jirassa. Lyhyt muisti on repositoriossa Clauden omina muistitiedostoina. Sääntö on kirjoitettu ylös: jos päätös vaikuttaa yli viiden sprintin päähän, se kirjataan Confluenceen. Jos se kuvaa nykytilaa tai lähitulevaisuuden tekemistä, se kirjataan repositorion muistiin. Jos se on aidosti molempia, repositorion tiedosto linkittää Confluenceen.

Myönnän, että Jira ja Confluence laahaavat hieman perässä, ja niitä täydennetään Clauden muistin perusteella ristiin. Se ei haittaa niin paljon kuin voisi luulla, koska ideat puretaan tiketeiksi nopeasti ja tiketit ovat yksittäisten agenttien kirjoittamia ja siksi melko tarkkoja. Aiheeseen pystyy aina palaamaan.

Peruskirjoja on kolmenlaisia.

Ensinnäkin kuusi CLAUDE.md-tiedostoa, yksi juuressa ja loput eri hakemistoissa. Ne latautuvat automaattisesti jokaisessa istunnossa ja sisältävät säännöt, joista ei neuvotella: kieliprotokolla, ei salaisuuksia versionhallintaan, kaikki käyttäjädataa käsittelevät palvelut EU-alueella ja kolmannen osapuolen avaimet vain palvelinpuolella.

Toiseksi protokollatiedosto, jonka otsikko on kirjaimellisesti “lue ennen kuin toimit”. Siinä on seitsemän numeroitua sääntöä, ja ensimmäinen niistä on “delegoi ennen kuin kirjoitat koodia”.

Kolmanneksi yli 40 palautetiedostoa. Ne ovat opittuja sääntöjä, jotka ovat syntyneet minun korjauksistani. Kun sanon saman asian toisen kerran, siitä kirjoitetaan sääntö. Ne kattavat esimerkiksi manuaaliohjeiden muodon, autonomian rajat ja sen, missä muodossa päätökset esitetään minulle.

Istunnon alussa on pakotettu lukujärjestys, jotta mikään ei jää sen varaan, että joku muistaisi lukea oikeat tiedostot.

Ja kyllä, arkkitehtiagentti on olemassa. Sen nimi on system-analyst. Kysymys menee ensin sille, se konsultoi asiaan liittyviä asiantuntija-agentteja, agentit antavat oman näkemyksensä, ja system-analyst kokoaa vastauksen ja palauttaa sen minulle ehdotuksena. Asiantuntijoita siis haastatellaan, ja sitä kautta asia etenee.

8. Miten validoit, että Clauden tuottama koodi on oikeasti laadukasta etkä vain hyväksy toimivalta näyttävää lopputulosta? Millaisia automaattitarkistuksia tai portteja olet rakentanut esimerkiksi GitHubiin tätä varten?

Lähdetään siitä, etten osaa itse tarkistaa koodia lainkaan. En pysty sanomaan, onko koodi hyvää vai huonoa.

Aiemmissa projekteissa, ei siis tässä, huomasin tekeväni arkkitehtuuria sattumanvaraisesti enkä osannut varmistaa sitä mitenkään. Ainoa tarkistus oli käsin annettu auditointipyyntö tyyliin “auditoi koodi”, ja sitten mentiin eteenpäin. Valmista tuli, mutta olen edelleen sitä mieltä, että se koodipohja on melko heikoilla kantimilla.

Siksi tähän projektiin rakennettiin oikea tarkistusjärjestelmä. Koska en pysty lukemaan koodia, tarkistuspisteet piti rakentaa niin, etteivät ne vaadi minua lukemaan sitä.

GitHubissa on tarkistusputki, joka ajetaan jokaisesta muutosehdotuksesta. Se katsoo ensin, muuttuiko sovelluskoodi lainkaan, koska pelkät dokumenttimuutokset saavat ohittaa raskaan osuuden. Jos muuttui, ajetaan neljä tarkistusta. Ensimmäinen on koodityyli, tyyppitarkistukset neljälle projektin osalle, yksikkötestit ja koko sovelluksen käännös. Testejä on yli 11 000. Toinen on selainajo, jossa Playwright käy läpi sekä julkiset sivut että kirjautuneen käyttäjän polut oikeassa selaimessa. Kolmas on saavutettavuusportti, joka ajaa axe-coren ja kaatuu, jos sivulta löytyy vakavia saavutettavuusvirheitä. Neljäs on tietokannan terveystarkistus, joka varoittaa mutta ei estä muutosta. Jos yksikin kolmesta ensimmäisestä kaatuu, muutos ei mene läpi.

Lisäksi on agenttien tarkistuspisteet, ja niissä on kiinnostavampi idea. Laadunvarmistaja-agentti tarkistaa tiketin ennen sen sulkemista, ja sen ohjeissa sanotaan erikseen, ettei se luota kehittäjäagentin omaan arvioon. Ylläpidettävyyttä vahtiva agentti auditoi rakennetta, luettavuutta ja nimeämistä ja palauttaa arvosanallisen raportin konkreettisine korjauksineen. Juridiikka- ja tietosuoja-agentti tekee ensitarkistuksen.

Näiden lisäksi on komento, joka ajaa moniagenttisen terveystarkastuksen. Se etsii jokaisen agentin, lähettää kaikille saman katselmusohjeen, kerää raportit ja tuottaa niistä yhteenvedon. Siinä on yksi sääntö, josta olen jälkikäteen pitänyt eniten. Se ei saa korjata mitään. Ongelmat löydetään ja kirjataan, ja korjaukset tehdään erillisessä ajossa. Muuten katselmus ja tekeminen sekoittuvat, eikä kukaan enää tiedä, mitä oikeasti löytyi.

Lopputulos on, etten edelleenkään pysty sanomaan, onko koodi hyvää vai huonoa. Luotan kuitenkin siihen, että agentit ja tarkistuspisteet pitävät laadun tietyllä tasolla.

9. Missä kohtaa Claude on pettänyt pahiten tai vienyt projektia väärään suuntaan? Kerro joku konkreettinen moka ja miten huomasit sen ennen kuin se ehti tuotantoon. Luotatko Clauden koodin laatuun vai tarkistatko kaiken perusteellisesti ennen julkaisua?

Suurin pettymys on liittynyt uusiin mallipäivityksiin. Claude alkaa harhailla ja viedä tehtävää omille poluilleen. Se on ajoittain turhauttavaa, koska työ pitää pysäyttää ja kysyä, mitä se oikein on tekemässä.

Konkreettinen esimerkki. Annoin sille pienen korjaustehtävän. Palasin asiaan parin tunnin päästä, ja se teki yhä samaa tehtävää. Näkyvissä oli, että noin 30 prosenttia työstä oli tehty. Kysyin, mitä se oikein tekee, koska kaikki tämä kuluttaa tokeneita. Silloin se havahtui ja myönsi lähteneensä harhapoluille, koska prosessi oli liian raskas näin pieneen asiaan.

Toinen iso ongelma on logiikan puute. Se lähtee ratkaisemaan asiaa raskain keinoin, vaikka muutos voisi olla vain se, että asia tehdään toisella tavalla tai jätetään kokonaan tekemättä.

Sitten se, mitä ei ole tapahtunut. Koodipohja ei ole kadonnut, päivien tai viikkojen työ ei ole hävinnyt, eikä mikään virhe ole aiheuttanut vakavia seurauksia. Virheitä on toki dokumentoitu, ja osa on ehtinyt tuotantoon asti, mutta mittakaavaltaan ne ovat pieniä.

Luotanko koodin laatuun? Alussa, ennen oikeita käyttäjiä, iteroin käytännössä suoraan tuotannossa. Se oli tehokasta: annoin sen tehdä valmiiksi ja katsoin sitten tuloksen. Enää en toimi niin.

10. Puhut esimerkiksi Linkedin-päivityksissä projektijohtajan ja orkestroijan roolista. Mikä on mielestäsi se osaaminen, jota ihmiseltä nyt oikeasti vaaditaan tällaisessa asetelmassa – onko se enemmän arkkitehtuurin hahmottamista, priorisointia vai jotain aivan muuta?

Sanoisin, että viisi asiaa, eikä arkkitehtuuri ole niistä ensimmäinen.

Ensimmäinen on visio. Pitää olla käsitys siitä, mitä ollaan tekemässä ja kenelle.

Toinen ja suurin on asiantuntijoiden määrittely. Orkestroijan pitää pystyä määrittämään, mitä taitoja asiantuntijoilla on. Vaikkei itse tietäisi, pitää osata selvittää, millainen on hyvä backend-kehittäjä juuri tähän projektiin. Yleinen UX/UI-suunnittelija-agentti ei välttämättä ole paras. Se pitää rakentaa vision ja kontekstin ympärille: mitä ollaan rakentamassa ja kenelle. Perusasioiden pitää olla kunnossa kaikilla tiimiläisillä, ja kokonaisuutena se on orkestroijan vastuulla.

Arkkitehtuuria ei mielestäni tarvitse osata. Pitää olla avoin arkkitehtuurin rakentamiselle, jos se ei ole oma vahvuus.

Kolmas on priorisointi ja tiekartta. Tässä on havainto, joka on mielestäni koko asetelman tärkein: tekoäly tuntuu tasapäistävän kaikki päätökset. Kaikki tehtävät näyttävät suunnilleen samanarvoisilta. Se ei pidä paikkaansa. Pitää ymmärtää, mitkä asiat ovat loppukäyttäjälle tärkeitä, mihin aikaa ja kapasiteettia käytetään ja mikä on minkäkin arvoista. Varsinkin kun uusia ideoita tulee koko ajan, pitää ymmärtää niiden riippuvuudet, eli mitä rakennetaan ensin ja mitä sen jälkeen.

Neljäs on ristikkäisvaikutuksista huolehtiminen. Pitää muistaa nostaa esiin asioita, kuten että informaatioarkkitehtuurin muutoksen jälkeen myös kaikki sisäiset linkitykset on päivitettävä. Ne eivät aina ole itsestään selviä, vaikka voisi ajatella, että tekoäly hoitaa ne. Se ei välttämättä muista.

Viides on maku ja laatustandardit, ja tästä on hyvä esimerkki.

Ennen kuin kuvageneraattori kytkettiin käyttöön, sivupohjat ja designjärjestelmä tehtiin Claude Designilla. Claude Design ei osaa luoda kuvia. Se teki silti jonkinlaisia glyyfimäisiä pikselipiirroksia ja oli täysin vakuuttunut siitä, että ne ovat erinomaisia. Minusta ne näyttivät siltä kuin lapsi olisi piirtänyt ne vasemmalla kädellä. Kun huomautin asiasta, Claude myönsi, ettei se pysty tekemään kuvia ja että tähän tarvitaan toinen työkalu.

Tekoälyllä on liian vahva usko omaan osaamiseensa, eikä sillä ole omia laatustandardeja. Orkestroijan tehtävä on sanoa, milloin lopputulos ei kelpaa, mitä pitää vielä parantaa ja mihin suuntaan työtä viedään.

11. Missä AI-tiimisi on parhaimmillaan, ja missä asioissa taas sinulta tarvitaan eniten työpanosta? Osaako sovellus ehdottaa sinulle uusia toimintoja?

Parhaimmillaan tiimi on toteutuksessa ja villeimpien ideoideni purkamisessa.

Se toimii näin. Asiantuntija-agentit odottavat valmiina, kullakin oma osa-alueensa. Annan niille idean uudesta toiminnosta, tutkimusidean, hypoteesin tai pitkän sanelun ja käynnistän ideointikomennon. Sen jälkeen alkaa työnkulku, jossa koko tiimi purkaa asian.

Ensin idea toistetaan minulle yhdellä tai kahdella lauseella, ja varmistetaan, että se ymmärrettiin oikein. Vaihe on pieni, mutta se säästää eniten aikaa, koska sanelu on harvoin niin selkeä kuin sanelija luulee. Sitten valitaan, mitä näkökulmia idea tarvitsee, ja asiantuntijat ajetaan rinnakkain. Ne eivät siis jonota, vaan analysoivat saman asian yhtä aikaa omista näkökulmistaan, eikä kukaan näe muiden vastauksia ennen kuin on itse vastannut. Samalla kirjataan yhdestä kolmeen terävintä kysymystä, joihin vain minä voin vastata. Sitten tulevat yhteenveto ja kysymykset, ja niiden jälkeen tiivis määrittely.

Viimeinen vaihe on tärkein. Minä valitsen lopputuloksen. Säännöissä lukee, ettei mitään toteuteta, viedä tuotantoon tai kirjata tiketiksi ennen sitä. Sparraus päättyy päätökseen, ei koodiin.

Tässä agentit ovat erinomaisia. Ne pystyvät konkretisoimaan vapaamuotoisen puheeni, purkamaan sen osiin, tutkimaan osat, palaamaan yhteenvedon kanssa ja tuomaan faktat pöytään päätettäviksi. Juuri siinä olen itse heikoimmillani.

Minua tarvitaan ideoinnissa. Agentit eivät mielestäni osaa ideoida tai ehdottaa uusia toimintoja tyhjästä. Se on niille vaikeaa. Jotta ne edes yrittäisivät, taustalle tarvitaan paljon tutkimusta ja vertailutietoa, esimerkiksi siitä, miten alan yritykset toimivat vastaavassa tilanteessa. Silloin ne voivat ehkä yrittää katsoa asiaa toisesta näkökulmasta. Kovin hyvin ne eivät siinä kuitenkaan onnistu.

Suora vastaus kysymykseen on siis ei: sovellus ei osaa ehdottaa uusia toimintoja, ainakaan tyhjästä.

12. Onko sinulle agentteja myös sisällöntuotantoon? Esimerkiksi copywriter-työhön tai hakukoneoptimoinnin huomioimiseen. Annatko näiden agenttien toimia vapaasti, eli tuottavatko ne automaattisesti myös sisältöä esimerkiksi hakukoneita varten?

On. Tiimissä on copywriter-agentti ja SEO-asiantuntija, jotka työskentelevät tarvittaessa rinnakkain, ja välillä mukana on myös UX-agentti.

Ne eivät toimi vapaasti. Emme tee laajamittaista ohjelmallista hakukoneoptimointia. En pidä sitä järkevänä tämänkokoiselle sivustolle, koska kyse ei ole tuhansista sivuista. Sisältösivuja on yli 200, ja nekin rakennetaan harkiten. Alueelliset sivut ovat suurin ohjelmallinen osuus, mutta niissäkin tavoitteena on tuoda aidosti lisätietoa ja viitata omaan karttadataan.

Roolijako on selvä. Copywriter vastaa sävystä ja visiosta. SEO-asiantuntija vastaa hakupuolesta ja tekee myös hakusana-analyysin, jonka pohjalta päätetään, mistä ylipäätään kirjoitetaan. Sisältö syntyy näiden yhdistelmänä. Sivupohjissa auttaa UX-agentti, ja pohjatyyppejä on useita. Osa on opasmaisia ja kertoo laajemmin retkeilystä, osa vastaa suoraan hakuihin, kuten telttapaikkoihin ja laavuihin, joita etsitään yllättävän paljon.

Ennen julkaisua on kielenhuollon tarkistuspiste. Se käy listana läpi tietyt asiat: yhdyssanat, ajatusviivan ja yhdysmerkin eron, lukujen kirjoitusasun, rektion, sijamuodot, kömpelöt rakenteet ja lähitoiston. Samalla varmistetaan, ettei kielikorjaus heikennä hakunäkyvyyttä, ja jos ne ovat ristiriidassa, SEO-asiantuntija päättää.

Tarkistuspiste on rakenteellinen, ja siihen on syy. Yhdessä sprintissä tekstin kirjoittanut agentti ajoi kielentarkistuksen omaan tekstiinsä, totesi sen virheettömäksi ja piti tarkistusta läpäistynä. Ei vilpillisesti, vaan huomaamattaan. Kun varsinainen tarkistus ajettiin erikseen, se löysi vielä kaksi virhettä, ja toinen niistä oli lupaus, jota tuote ei pidä: laskeutumissivun alku lupasi karttadataa, jota emme toimita.

Siitä tuli sääntö. Tarkistuksen ajaa eri agentti kuin se, joka kirjoitti tekstin. Oman tekstin tarkistaminen on hyödyllistä esityötä, mutta se ei kelpaa tarkistuspisteeksi.

Sen lisäksi luen itse tärkeimmät sisällöt ja sanon, jos jokin näyttää tai kuulostaa kömpelöltä.

13. Miten analytiikka on mukana kehitystyössä, onko sinulla joku analytiikka-agentti joka automaattisesti tuottaa sinulle havaintoja? Tai onko jollain agentilla jopa lupa muotoilla automaattisesti kehitysehdotuksia analytiikan havaintojen perusteella?

Analytiikka on vahvasti mukana, mikä johtuu varmasti taustastani. Olen toiminut markkinointijohtajana ja olen aina ollut erittäin kiinnostunut analytiikasta. Se on myös osa itse kokeilua: miten analytiikan saa käännettyä tuotekehitykseksi nopealla aikataululla niin, että näkee, mikä toimii ja mikä ei.

Seuraan jatkuvasti, mistä liikennettä tulee ja mitä ihmiset tekevät. Ennen kaikkea seuraan sitä, mitä he eivät tee, eli missä kohdassa he poistuvat ja missä he lähtevät saman tien pois. Sen pohjalta yritetään löytää seuraavat askeleet: miten ihmiset viipyisivät pidempään, miten he palaisivat ja miten he rekisteröityisivät. Se on seuraava ratkaistava ongelma, eikä sitä ole vielä ratkaistu.

Tätä varten on oma komento. Se kokoaa läpileikkauksen kolmesta lähteestä: tietokannasta rekisteröityneet käyttäjät ja sisältömäärät, tuoteanalytiikasta kävijät, istunnot, kesto ja poistumisprosentti sekä Search Consolesta klikkaukset, näyttökerrat ja hakusijainnit.

Lähteitä kiinnostavampaa on se, että komentoon on kirjoitettu säännöt siitä, miten lukuja saa tulkita. Lukuja saa olla viisi tai kuusi, ei enempää, ja jos mittari ei muuta mitään päätöstä, se jätetään pois. Absoluuttiset luvut esitetään prosenttien rinnalla, koska pienillä volyymeilla suhdeluvut heittelevät. Hakudata tulee muutaman päivän viiveellä, joten viimeisten päivien pudotuksesta ei tehdä johtopäätöksiä.

Sen on ajanut maanantaiaamuisin ajastus ilman, että kukaan pyytää. Se ei kuitenkaan johda mihinkään itsenäisiin toimenpiteisiin. Komennon viimeinen rivi on kirjaimellisesti sääntö: hae luvut, kirjoita raportti, lopeta, äläkä aloita jatkotöitä havaintojen perusteella ilman perustajan pyyntöä. Teknisesti jatkaminen olisi mahdollista, sillä työkalut riittäisivät viemään havainnosta tikettiin ja tiketistä koodiin. Se on erikseen kielletty kirjoitetulla säännöllä.

Käytännössä luen raportin ja lähden keskustelemaan siitä. Claude on oppinut analysoimaan sitä oikeaan suuntaan ja tekee ehdotuksia, esimerkiksi että ihmiset katsovat kohteen mutta eivät jatka siitä eteenpäin. Sitä kehitämme nyt.

Yksi esimerkki siitä, miksi tämä ei ole suoraviivaista. Kesällä data näytti mallin, jota kukaan ei ollut suunnitellut. Tallennuksia oli moninkertaisesti käyntimerkintöihin verrattuna, eli ihmiset käyttävät Polkuopasta retkien suunnitteluun eivätkä retkipäiväkirjana. Ennen kuin annoimme havainnon ohjata sprintin teemaa, se tarkistettiin, ja tarkistus paljasti vian mittarissa. Kolme tallennuspolkua kirjoitti tietokantaan mutta ei lähettänyt analytiikkaan mitään. Havainto piti paikkansa, mutta se piti mitata uudelleen korjatulla mittarilla ennen kuin siihen saattoi luottaa.

Tässä on myös se toinen kokeilu, josta harvoin kysytään. Koko markkinointikoneisto pyörii samasta paikasta. Sama ohjaamo, joka rakentaa sovelluksen, hakee hakudatan, tekee hakusana-analyysin, tuottaa sisältösivut ja hoitaa mittauksen. Markkinointiin ei ole käytetty euroakaan, ja hakunäkyvyys on rakennettu kokonaan tätä kautta. Se on ehkä koko projektin kiinnostavin sivujuoni, vaikka se ei varsinaisesti ole ohjelmistokehitystä.

14. Jos joku toinen henkilö haluaisi rakentaa vastaavan AI-ohjatun setupin harrastusprojektilleen, mitkä ovat asioita jotka ehkä tekisit heti alussa toisin kuin sinä teit?

Neljä asiaa. Kolmessa niistä kyse on siitä, että tekisin jotain enemmän, ei siitä, että olisin tehnyt väärin.

Jälkikäteen katsottuna turhaa työtä oli Atlassian-ympäristö eli Jira ja Confluence. Olen sen jälkeen tehnyt uusia projekteja, joissa olen jättänyt ne kokonaan pois ja rakentanut saman toiminnon suoraan repositorioon. Alussa ne olivat kuitenkin mielestäni hyvä valinta, koska ne ovat visuaalisesti selkeitä. Pystyin silmäilemään tikettejä helposti ja katsomaan työjonoa ja pitkää muistia Confluencesta.

Syy on kiinnostavampi kuin itse johtopäätös. Jira ja Confluence toivat yhden hyödyn: pystyin itse silmäilemään tilannetta. Kun lakkasin käymästä niitä itse läpi ja aloin luottaa siihen, että agentit käyvät ne paremmin, hyöty katosi mutta kustannus jäi. Jäljelle jäi yhteys, joka pitää määrittää ja joka voi hajota. Repositoriossa sama tieto on agenttien käytettävissä ja paremmin löydettävissä. Luovuin siis ihmisen käyttöliittymästä, en työkalusta.

Kaksi asiaa tekisin alussa vahvemmin. Ensimmäinen on pohjatiedon, positioinnin ja tutkimusten määrä sekä niistä johdetut havainnot. Mitä enemmän niitä on, sitä paremmin alku lähtee käyntiin ja sitä kokonaisvaltaisemman kuvan pystyy muodostamaan siitä, mitä ollaan tekemässä ja mitkä ovat kantavat toiminnot. Se vaatii paljon mielikuvitusta ja ajattelua, mutta mitä perusteellisemmin sen tekee, sitä parempi.

Toinen on näkymien suunnittelu. Ennen kuin kehitystyö alkaa, kannattaa laittaa UX-agentit työhön ja pyytää niitä tekemään näkymät oikeasti konkreettisesti valmiiksi. Silloin ne voi käydä läpi ennen kuin kehitystyötä tehdään. Kumpikaan näistä ei ole pakollinen, ja eteenpäin pääsee ilmankin, mutta molemmat maksavat itsensä takaisin.

Sprinttirytmistä pidin ja pidän edelleen. Se pakottaa pitämään yhden kokonaisuuden kontekstissa. Se on helpompaa kuin yrittää tehdä koko sovellus kerralla, jolloin työ alkaa rönsyillä ja yhtäkkiä huomaa usean päivän työn jälkeen, että koko istunto on täynnä sekamelskaa. Minulla yksi sprintti on nykyään yksi istunto, ja se pitää senkin kasassa.

Oikea päätös alusta asti oli tehdä tämä puhtaasti agenttisesti, Claude pääohjaamona. Alun vaivalloisin vaihe on yhteyksien ja avainten määrittäminen. Se vaatii keskittymistä, mutta kun se on tehty, autuus koittaa.

>> Tutustu Polkuopas.fi-palveluun

PS. Tilaa Vierityspalkin noin kerran kuukaudessa ilmestyvä uutiskirje.