Tekoäly on siirtymässä ”chatbot-aikakaudesta” kohti agenttipohjaista toimintamallia. Mutta mitä tapahtuu, kun annamme tekoälytiimille vain yhden lauseen toimeksiannon ja vapaat kädet? Tässä artikkelissa puran auki kokeilun, jossa viisi autonomista agenttia rakensi, testasi ja kontitti toimivan sääsovelluksen – ja kerron, miksi se oli teknisesti vaikeampaa kuin alustavasti luulin.
Ohjelmistokehityksen maailmassa puhutaan nyt paljon agenteista (AI Agents). Erona perinteiseen ChatGPT-keskusteluun, agentti on järjestelmä, jolla on tavoite, rooli ja kyky käyttää työkaluja. Se ei vain vastaa kysymykseen, vaan se suorittaa tehtäviä.
Päätin laittaa teorian käytäntöön 30 minuutin live-demossa, yleisön edessä Sakkyn Tekoälypäivässä 24.10.25 Tavoite oli kunnianhimoinen: Rakentaa täysin toimiva Full-stack verkkosovellus (Flask + HTML/JS) käyttäen CrewAI-kehystä ja yhtä ainoaa korkean tason kehotetta.
Lopputuloksena syntyi ”Paikallinen sääappi”, joka hakee reaaliaikaista dataa OpenWeatherMapista. Matka sinne ei kuitenkaan ollut suoraviivainen. Se vaati syvällistä ymmärrystä kielimallien rajoitteista, API-rajapintojen oikuista ja siitä, miten tekoälylle annetaan ”kädet”.
Tiimin esittely: Viisi roolia, kolme eri ”aivoa”
Projektin ytimessä oli CrewAI-orkestrointikehys, jota ajettiin Python 3.11 -virtuaaliympäristössä. Sen sijaan, että olisinkoodanneet itse, loin viisi virtuaalista työntekijää.
Jokaiselle agentille määriteltiin rooli, tavoite (Goal) ja taustatarina (Backstory). Lisäksi päätin kokeilla nk. Multi-LLM -lähestymistapaa, eli käytin eri palveluntarjoajien malleja ristiin hyödyntääkseni niiden vahvuuksia.
- Kokenut Projektipäällikkö (OpenAI GPT-4 Turbo): Hänen tehtävänsä oli pilkkoa korkean tason tavoite (”Tee sääsovellus”) pienemmiksi, suoritettaviksi tehtäviksi ja delegoida ne muille.
- Senior Backend-kehittäjä (OpenAI GPT-4 Turbo): Vastuussa Python/Flask-logiikasta ja rajapintakutsuista.
- Frontend-kehittäjä (OpenAI GPT-4 Turbo): Vastuussa käyttöliittymästä (HTML/CSS/JS) ja datan esittämisestä.
- Laadunvarmistusinsinööri QA (Google Gemini 2.5 Pro / Vertex AI): Tarkoituksella eri malliperhettä edustava agentti, jonka tehtävä oli lukea muiden kirjoittama koodi ja etsiä virheitä. ”Tuoreet silmät” -periaate.
- DevOps-insinööri (OpenAI GPT-4 Turbo): Vastuussa sovelluksen paketoinnista Docker-konttiin tuotantoajoa varten.
Tekninen syväsukellus: Kun teoria kohtaa todellisuuden
Paperilla prosessi näyttää helpolta: Projektipäällikkö käskee, koodarit koodaavat ja DevOps paketoi. Todellisuudessa agentit kohtasivat neljä kriittistä ongelmaa, jotka pysäyttivät kehityksen. Nämä haasteet ja niiden ratkaisut olivat projektin tärkein oppi.
1. Agenttien ”Käsien” Luominen (I/O-ongelma)
Ensimmäinen ja ilmeisin ongelma oli, että oletusarvoisesti kielimallit (LLM) vain generoivat tekstiä. Ne ”hallusinoivat” koodia chattiin, mutta eivät osaa tallentaa sitä tiedostoksi kovalevylle. Backend-agentti saattoi luoda täydellisen main.py-tiedoston sisällön, mutta ilman työkaluja se jäi vain tekstiksi muistiin.
Ratkaisu: Meidän piti rakentaa agenteille mukautettuja työkaluja (Custom Tools).
- FileWriteTool: Kehittäjä- ja DevOps-agenteille annettiin Python-funktio, joka pakottaa ne kirjoittamaan generoidun sisällön fyysiseen tiedostoon (esim. output/main.py tai Dockerfile).
- FileReadTool: QA-agentille oli kriittistä antaa lukutyökalu. Ilman sitä se ei voisi arvioida muiden tekemää koodia, vaan joutuisi luottamaan sille kerrottuun kuvaukseen koodista.
Tämä on merkittävä ero perinteiseen koodaukseen: emme kirjoita koodia, vaan kirjoitamme työkaluja, joilla koodia kirjoitetaan.
2. Google Gemini ja API-avainten viidakko
Halusin käyttää QA-agenttina Googlen mallia (Gemini), koska sen konteksti-ikkuna on valtava ja se on osoittautunut kohtuulliseksi työkaluksi koodin analysoinnissa. Törmäsin kuitenkin sitkeään 404-virheeseen käyttäessäni tavallista Google AI Studion API-avainta langchain_google_genai -kirjaston kautta. Vaikka avain oli validi ja laskutus kunnossa, yhteys ei toiminut agentti-ympäristössä luotettavasti.
Ratkaisu: Ongelma ratkaistiin siirtymällä ”harrastelijatasolta” yritystasolle:
- Kirjasto vaihdettiin: langchain_google_genai → langchain_google_vertexai.
- Autentikaatio muutettiin: Luovuin .env-tiedoston API-avaimesta ja käytin Google Cloudin Application Default Credentials (ADC) -tunnistautumista (gcloud auth application-default login).
- Malli päivitettiin: Koska Vertex AI:n mallivalikoima eroaa AI Studiosta, lukitsin malliksi gemini-2.5-pro, joka oli projektin käyttöoikeuksien puitteissa saatavilla.
Tämä muutos mahdollisti QA-agentin toiminnan.
3. Kolmannen osapuolen eliminointi (Anthropic)
Alkuperäisessä suunnitelmassa Projektipäällikkö-agentin piti käyttää Anthropicin Claude 3 -mallia, jotta olisin saaneet aidosti ”kolmen suuren” (OpenAI, Google, Anthropic) yhteistyön.
Käytännössä tämä osoittautui pullonkaulaksi. Anthropicin API palautti toistuvasti virheitä käyttöoikeuksista jopa perusmalleilla (Claude 3 Haiku), mikä pysäytti koko ketjun heti alkuunsa.
Oivallus: Agenttijärjestelmissä ketju on yhtä vahva kuin sen heikoin lenkki. Jos PM-agentti kaatuu, kukaan ei tee mitään. Ratkaisu: Konsolidoin järjestelmän kahden luotettavimman toimittajan (OpenAI ja Google Vertex) varaan. PM-agentti siirrettiin GPT-4 Turbolle, mikä varmisti projektin käynnistymisen.
4. ”Se toimii (vain) minun koneellani” – Docker ja verkotus
Kun koodi oli valmis ja DevOps-agentti oli luonut Dockerfilen, sovellus ei silti toiminut selaimessa. Docker-kontti pyöri, mutta palautti joko 404-virheen tai ”Connection Refused”.
Tässä paljastui tekoälyn taipumus toistaa yleisiä oppikirjaesimerkkejä ilman kontekstin ymmärrystä:
- Flaskin reititys: Agentit olivat unohtaneet määritellä juurireitin (/). Sovelluksessa oli kyllä API-endpoints, mutta ei reittiä, joka tarjoilisi html-sivun käyttäjälle.
- Host-bindaus: Flask-sovellus käynnistettiin oletuksena localhost-tilassa (0.0.1), jolloin se ei näy Docker-kontin ulkopuolelle.
- Tiedostopolut: DevOps-agentti yritti kopioida tiedostoja väärästä hakemistorakenteesta (output/output/ vs output/).
Ratkaisu (Prompt Engineering): Korjasin nämä ohjeistamalla agentteja (System Prompt) tarkemmin:
- Frontend-agenttia käskettiin varmistamaan, että Flask tarjoilee HTML-sivun juurireitistä (@app.route(’/’)).
- Backend-agentille annettiin ehdoton sääntö: run(host=”0.0.0.0″, port=5000).
- DevOps-agenttia ohjeistettiin käyttämään suoraa COPY main.py . -komentoa ja huomioimaan suhteelliset polut.
Lopputulos: Autonominen toimitusputki
Näiden korjausten jälkeen ajoin komennon python run_demo.py. Seurasimme live-yleisön kanssa yhdessä videotykillä seinälle heijastetusta terminaalista, kuinka agentit keskustelivat keskenään:
- PM jakoi ensin tehtävät, kuten olin pyytänyt.
- Backend kirjoitti py:n, joka haki Kuopion säätiedot JSON-muodossa.
- Frontend loi tyylikkään HTML-sivun, joka osasi käsitellä Backendin dataa.
- QA (Gemini) luki tiedostot, huomautti puuttuvasta virheenkäsittelystä (joka korjattiin seuraavalla iteraatiolla).
- DevOps loi Dockerfilen, joka asensi riippuvuudet ja käynnisti sovelluksen.
Lopputuloksena meillä oli kansio, jonka sisällön pystyi käynnistämään yhdellä Docker-komennolla. Selain avasi näkymän: ”Kuopio 274.38 °C…”.
Mitä tämä tarkoittaa ohjelmistokehityksen tulevaisuudelle?
Tämä kokeilu osoitti (lopputuloksesta huolimatta), että olemme siirtymässä Code Generation -vaiheesta Agentic Workflow -vaiheeseen.
Emme enää käytä tekoälyä vain ”älykkäänä automaattitäydennyksenä” (kuten Copilot:ia). Sen sijaan alamme rakentaa arkkitehtuureja, joissa tekoäly vastaa prosessin suorittamisesta. Ihmisen rooli muuttuu koodaajasta arkkitehdiksi ja tuoteomistajaksi.
Tämä tuo mukanaan uusia vaatimuksia:
- Infrastruktuuri: Tarvitsemme luotettavia rajapintoja (kuten Vertex AI) harrastelijatyökalujen sijaan.
- Valvonta: Agentit tarvitsevat QA-prosessit. Gemini-agentin rooli laadunvarmistajana oli kriittinen – se oli ainoa, joka ”luki” koodia “kriittisesti” sen sijaan, että olisi vain ”kirjoittanut” sitä.
- Työkalut: Agentit ovat hyödyllisiä vain, jos niillä on pääsy tiedostojärjestelmään, komentoriviin ja verkkoon.
Seuraavat askeleet
Vaikka ”Paikallinen sääappi” on lähes toimiva demo, se ei ole vielä tuotantovalmis yritysjärjestelmä. Seuraavat kehitysaskeleet agentti-tiimillemme ovat jo suunnitteilla:
- Automaattinen yksikkötestaus: QA-agentille annetaan käyttöön esimerkiksi ShellTool, jonka avulla se voi itse ajaa pytest-komentoja ja korjata koodia testitulosten perusteella – ei vain silmämääräisesti arvioimalla.
- CI/CD-integraatio: Sen sijaan, että agentit luovat tiedostoja paikallisesti, DevOps-agentti kytketään GitHub Actionsiin. Tavoitteena on, että agentti voi avata itse Pull Requestin, jolloin ihmiskehittäjä toimii lopullisena hyväksyjänä ennen tuotantoon vientiä.
- Red Teaming –testaus: Jokainen generatiivista tekoälyä käyttävä järjestelmä, on erittäin haavoittuvainen erilaisille suojakaiteiden ohituskomennoille. Järjestelmiä pitää testata jatkuvasti, olivatpa ne ainoastaan sisäiseen tai ulkoiseen käyttöön.
(Tästä aiheesta löytyy oma esitys Teknologia 25 messuilta TIVIA Stagelta keskiviikon tallenteista TIVIA:n sivuilta.)
Tekoälyagentit eivät vie ohjelmoijan työtä, mutta ne muuttavat sen luonnetta radikaalisti. Rutiininomainen ”boilerplate”-koodaus siirtyy koneille, ja ihmiset keskittyvät ongelmanratkaisuun, arkkitehtuuriin ja siihen kaikkein vaikeimpaan: määrittelemään, mitä me oikeastaan haluamme rakentaa.
Haluatko tietää lisää?
Sytyke-lehden lukijat voivat tutustua CrewAI-kehykseen osoitteessa https://www.google.com/search?q=crewai.com tai kokeilla Google Vertex AI:n mahdollisuuksia Google Cloud Consolessa.
Jarkko Laine on pohjoissavolainen hyvishakkeri, jota kiinnostaa kaikki teknologiat ja niiden tuomat eri liiketoimintamahdollisuudet. Jarkko tekee työtä päivisin tietoturvan ja tekoälyteknologioiden parissa ja öisin metsästää virtuaalimaailman pahiksia. Paikallispolitiikka on myös yksi Jarkon harrastuksista.
