Promptauksesta agenttiseen työskentelyyn

AI muutti sekä työn organisointia että sitä, kuinka paljon erilaisia ideoita pystyin viemään käytäntöön.

Alussa kontrolloin AI:n jokaista askelta. Projektien edetessä kontrolli siirtyi tavoitteeseen, kontekstiin, työn pilkkomiseen, rajoihin, verifiointiin ja lopputulokseen. Samalla pystyin kokeilemaan yhden kesän aikana useita hyvin erilaisia projekteja, joiden tekemiseen perinteisesti olisi kulunut olennaisesti enemmän aikaa.

7 erilaista caseasovelluskehitys, 3D, palvelu, deterministinen tarkistus, päätösanalyysi, context engineering ja MCP

Yksi agentti → subagentittyön pilkkominen planner-, implementer- ja reviewer-rooleihin

Prompt → working systemkonteksti, tool-use, execution loop, guardrailit ja review

Speed → evidencesuurempi tekemisen kapasiteetti ei poista tarvetta todentaa lopputulos

Oppimiskaari

Tämä ei ole kypsyysmalli tai arvosana, vaan kronologinen kuvaus siitä, miten oma työskentely muuttui projektien aikana.

AlkuPrompt & vastaus

Yksittäiset pyynnöt.

Seuraava vaiheAI pair worker

Steppi ja hyväksyntä kerrallaan.

Repo-työAgentti kokonaistehtävään

Monitiedostomuutokset, testit ja diff.

Hallittu autonomiaWorkflow + guardrails

Tavoite, rajat, konteksti ja human gate.

MyöhemminSubagent orchestration

Tehtävän pilkkominen eri agenttirooleille.

Projektit oppimisympäristöinä

Projektien määrä itsessään ei ole onnistumismittari. Arvo oli siinä, että AI:n avulla pystyin viemään seitsemän erilaista ideaa käytännön tasolle ja testaamaan samoja periaatteita hyvin erilaisissa ongelmissa.

AjokeliTesti: API-rajapinnat, datan käsittely, karttavisualisointi ja käyttöliittymä.Oppi: “perinteinen” data-/web-sovellus oli hyvä baseline sille, miten agentti hoitaa tavallisen full-stack-työn päästä päähän.

SatsiTesti: Cloudflare D1, tietokantaschema, auth, domain-mallinnus ja viivakoodilukijan vaatima datarakenne.Oppi: agentti pystyy viemään myös persistentin datakerroksen sisältävän sovelluksen end-to-end, kun schema ja hyväksymiskriteerit ovat eksplisiittisiä.

PDF CheckerTesti: ulkoinen veraPDF-engine, Docker-runtime ja JSON-raportointi.Oppi: agentin pitää ymmärtää lähdekoodin lisäksi runtime, ulkoiset riippuvuudet ja se, mikä lopputuloksessa voidaan todentaa deterministisesti.

GhostlightTesti: kolme erillistä kehityskierrosta: V1 mitä AI:lla saa aikaan, V2 syvällisempi suunnittelu ja V3 tarkoituksellinen yritys ylittää aiempi taso.Oppi: tekninen verifiointi ei riitä; suunnittelu, iterointi ja visual/UX review muodostavat oman laatukerroksensa.

Blender + MCPTesti: MCP- ja harness-osaamisen vieminen eteenpäin kytkemällä agentti ulkoiseen 3D-työkaluun.Oppi: tool-use lisää toimintakykyä, mutta samalla oikeus-, data-, konteksti- ja luottamusrajat muuttuvat osaksi toteutuksen suunnittelua.

Rovo / Project SourcesTesti: persistentti konteksti, decision log, evidence/status rules.Oppi: kontekstikerros on agentin työmuisti ja governance, ei vain dokumenttivarasto.

TontinlunastusTesti: RFP, rahoitusanalyysi, laskuri ja päätösmateriaali.Oppi: fakta, laskenta ja tulkinta pitää erottaa. Agenttisuus toimii myös knowledge workissa.

Throughput-oppi: AI mahdollisti useiden erilaisten projektien etenemisen ideasta toimivaksi artefaktiksi saman kesän aikana. Tämä on vahva kvalitatiivinen havainto tekemisen leverage-vaikutuksesta, mutta ei vielä mitattu tuottavuusluku.

Visuaalinen evidence

Kuvat eivät korvaa teknistä arviointia, mutta ne tekevät yhdellä silmäyksellä näkyväksi, että caset olivat keskenään erilaisia ja etenivät toimiviksi artefakteiksi asti.

Ghostlight · V3Kolmannen kehityskierroksen 3D/visual-tulos. ghostlight.watisdis.com

SatsiFull-stack + Cloudflare D1 + schema/domain modelling. satsi.watisdis.com

AjokeliAPI-data → käsittely → karttavisualisointi → UI. ajokeli.watisdis.com

PDF Accessibility Checker -tarkistuksen tulos

PDF Accessibility CheckerveraPDF-engine, Docker-runtime ja deterministisesti raportoitava koneellisen sääntöjoukon tulos. Koneellinen tarkistus kattaa vain osan PDF/UA-vaatimuksista. pdf.watisdis.com

Blender-projekti, jossa rig, 3D-hahmo ja skripti näkyvät samassa työympäristössä

Blender + MCPTool-use ja harness tutkimuskohteena: agentti kytketty ulkoiseen 3D-sovellukseen.

GitHub-repot Ghostlight, Satsi, Ajokeli ja PDF Accessibility Checker

GitHub / repo-aware developmentProjektit versionhallinnassa; repo, branch, diff ja testit muodostivat agenttityön turvallisen työympäristön.

Workflow evolution: neuvovasta AI:sta työkaluihin kytkettyyn agenttiin

Selkein käytännön muutos ei tapahtunut mallin nimessä vaan siinä, mitä agentti pystyi tekemään ympäristössä. Ensimmäisissä projekteissa moni konfiguraatio oli käsityötä; myöhemmin repo- ja tool-integraatiot sekä erillisissä caseissa MCP tulivat osaksi samaa execution loopia.

1 · ManualAI neuvoo

Koodi ja ratkaisut syntyivät AI-avusteisesti, mutta GitHub-, domain-, subdomain- ja Cloudflare-konfiguraatiot tein itse.

2 · Repo-awareGitHub osaksi työketjua

Repo, branch, tiedostot, testit ja diff-review toivat muutokset hallittuun ja palautettavaan työympäristöön.

3 · Tool-enabledTool access + MCP

GitHub- ja Cloudflare-pääsy tuli natiivien integraatioiden, CLI/API-työkalujen tai addonien kautta. MCP:tä käytin erikseen esimerkiksi Blenderin kytkemiseen agentin työkaluksi.

4 · Harness-drivenYksi hallittu looppi

Tutki → muuta → testaa → versionhallinta → konfiguroi/deploy → verifioi, human gate kriittisiin kohtiin.

Mitä tekisin nyt toisin: olisin tuonut GitHub- ja Cloudflare-tool accessin mukaan aikaisemmin. Manuaalisen ja integroidun tavan kokeminen peräkkäin teki kuitenkin eron konkreettiseksi: agentin arvo kasvaa, kun se ei vain neuvo vaan pystyy toimimaan rajatusti oikeassa ympäristössä.

AjokeliAPI + data + visualization + UIBaseline perinteisemmälle full-stack/data-työlle.

Satsi+ D1 + schema + domain modellingPersistentti data ja mallinnus nostivat kompleksisuutta.

PDF Checker+ external engine + Docker/runtimeAgentin piti huomioida myös ajoympäristö ja deterministinen verifiointi.

Ghostlight V1→V3+ deliberate iteration + visual reviewFokus siirtyi “toimiiko” → “kuinka paljon laatua workflow’lla voidaan nostaa”.

Blender + MCP+ external tool-useMCP ja harness itsessään muuttuivat tutkimuskohteeksi.

Rovo / Project Sources+ persistent context + evidence governanceLopulta fokus siirtyi myös siihen, mitä agentti tietää ja mihin se saa luottaa.

Yksi tärkeä epäonnistuminen: hyvä rakenne ei pelasta väärää evidenceä

Rovo / Project Sources

Yhdessä työvaiheessa design-dokumenttiin perustuva väite päätyi liian vahvaan “confirmed”-statukseen. Ongelma ei ollut kielimallin sujuvuus vaan evidence hierarchy: design-dokumentti kuvasi suunniteltua ratkaisua, ei todistettua tuotantokäyttäytymistä.

Mitä tästä muuttui

Claimin vahvuus ei saa ylittää lähteen vahvuutta. Design, toteutus, testitulos ja tuotantohavainto pitää erottaa toisistaan. Tämä johti evidence/status-sääntöjen tarkentamiseen ja vahvisti ajatusta siitä, että agentin kontekstikerros tarvitsee eksplisiittisen luotettavuusmallin.

Keskeinen oppi: agentti voi olla sisäisesti täysin looginen ja silti päätyä väärään varmuustasoon, jos lähteiden auktoriteetti tai statusmalli on väärä.

Yhdestä agentista agenttitiimiin

Subagentit tulivat mukaan vasta myöhemmissä projekteissa. Niiden arvo ei ollut “enemmän AI:ta”, vaan työn jakaminen tarkoituksenmukaisiin rooleihin.

Planner / researcher

Tutkii ennen toteutusta

Selvittää vaihtoehdot, riippuvuudet ja riskit ennen implementointia. Vähentää liian aikaista lukittumista ensimmäiseen ratkaisuun.

Implementer

Rajattu toteutusvastuu

Saa selkeän tehtävän, tarvittavan kontekstin ja hyväksymiskriteerit. Fokus pysyy toteutuksessa.

Reviewer / verifier

Riippumaton tarkistus

Arvioi diffiä, testejä ja vaatimusten täyttymistä erillään toteuttajasta. Käytännössä AI-avusteinen four-eyes-periaate.

Milloin auttaa

Kun työ voidaan oikeasti jakaa

Rinnakkaiset, toisistaan riippumattomat tutkimus- tai toteutustehtävät
Eri roolit: tutkimus, implementointi, testaus, review
Tarve rajata yhden agentin kontekstikuormaa
Tarve riippumattomalle toiselle arviolle

Milloin ei auta

Orkestrointi itsessään maksaa

Pieni tai lineaarinen tehtävä
Paljon samaa muuttuvaa tilaa ja synkronointia
Handoffit hävittävät enemmän kontekstia kuin tuovat hyötyä
Roolit tai vastuut ovat epäselviä

Mistä luotettava agenttinen työ käytännössä rakentuu?

Tämä on käytännön muistilista, ei formaali kypsyysmalli. Mallin älykkyys on vain yksi osa kokonaisuutta.

Context

Mitä agentti tietää

Nykytila, backlog, päätökset, evidence, sanasto, repo ja tehtävän rajaus. Vanhentunut tai väärä konteksti skaalautuu nopeasti vääräksi tekemiseksi.

Harness / execution environment

Miten agentti toimii

Agentin ympärillä oleva ajoympäristö ja tool-loop: miten konteksti syötetään, työkalut kutsutaan, palaute käsitellään, tila säilytetään ja suoritus jatkuu.

Verification & control

Miten tiedetään että tulos kelpaa

Testit, diff, visual review, evidence hierarchy, rajatut oikeudet ja human gate riskin mukaan.

Context and control layers in practice Kaikkea ei kannata tunkea samaan prompttiin. Muuttuva projektitila, uudelleenkäytettävät työohjeet, toiminnan rajat ja evidenssin luotettavuus ovat eri asioita.

Project context

Mitä tässä projektissa tiedetään nyt

Nykytila, backlog, päätökset, changelog, avoimet asiat ja domain-kohtainen tieto.

Reusable instructions / skills

Miten tietynlainen työ tehdään

Toistuvat suunnittelu-, toteutus-, review- ja verifiointikäytännöt erillään muuttuvasta projektitilasta.

Guardrails

Mitä agentti saa tehdä

Scope, oikeudet, hyväksymiskriteerit, human gate -kohdat ja asiat, joita ei saa muuttaa.

Evidence

Mihin väitteeseen saa luottaa

Lähteen auktoriteetti, status ja varmuus. Väite ei saa olla lähdettään vahvempi.

Käytännön toteutus: omissa projekteissa persistentti konteksti tarkoitti esimerkiksi project state-, backlog-, changelog- ja decision-rakenteita. Pointti ei ollut tiedostonimissä vaan siinä, ettei agentin tarvinnut päätellä joka sessiossa uudelleen, missä projekti on ja miten siinä kuuluu toimia.

Heuristinen kokonaisuus: model + context + execution harness + tools + guardrails + verification. Yhdenkin heikon kerroksen vaikutus näkyy helposti lopputuloksessa.

Autonomia: kaksi eri kysymystä

Verifioitavuus ja palautettavuus määrittävät, kuinka paljon tehtävää voidaan delegoida. Riski määrittää, kuinka korkea kontrollikynnys tarvitaan.

Helposti verifioitava / palautettava

Vaikeasti verifioitava / palautettava

Matala riski

Korkea autonomia mahdollinen

Esim. rajattu tutkimus tai koodimuutos, jossa testit ja rollback ovat selkeät.

Rajattu autonomia

Agentti voi valmistella, mutta ihminen tarkistaa tuloksen ennen etenemistä.

Korkea riski

Autonomia + vahva human gate

Automaatio voi tehdä paljon, mutta päätös- tai julkaisuportti pysyy ihmisellä.

Vahva human control

AI voi tukea analyysiä, mutta ei tehdä lopullista päätöstä tai peruuttamatonta toimenpidettä.

Failure modes, jotka opin ottamaan vakavasti

Agenttisen työn ongelmat eivät rajoitu hallusinaatioihin. Kun agentti saa työkaluja ja pidemmän työketjun, myös virheiden pinta-ala kasvaa.

Vanhentunut / väärä konteksti

Oikein toteutettu tehtävä voi perustua väärään nykytilaan.

Itsevarma väärä tulos

Sujuva selitys ei ole evidenceä.

Silent regression

Yksi tavoite täyttyy samalla kun muu toiminta rikkoutuu.

Test gaming

Agentti voi muuttaa testin vastaamaan toteutusta eikä toteutusta vaatimusta.

Spec drift

Pitkä suoritus voi etääntyä alkuperäisestä tavoitteesta.

Shared state / handoff

Rinnakkaisten agenttien tieto tai muutokset voivat mennä ristiriitaan.

Prompt injection

Ulkoinen web-, dokumentti- tai tool-sisältö voi yrittää ohjata agenttia pois alkuperäisestä tehtävästä.

Liian laajat oikeudet

Tool-use lisää sekä kyvykkyyttä että vahingon mahdollisuutta.

Runaway cost / loops

Useampi agentti tai pitkä retry-ketju ei automaattisesti paranna laatua.

Workflow, johon tekeminen konvergoitui

Määritä käyttäjätulos

Mitä käyttäjän tai liiketoiminnan pitää saada aikaan?

Anna oikea konteksti ja evidence

Repo, nykytila, backlog, päätökset, data, sanasto ja lähteiden auktoriteetti.

Määritä guardrailit

Scope, oikeudet, hyväksymiskriteerit ja mitä ei saa muuttaa.

Pilko työ ja valitse agenttiroolit

Yksi agentti, rinnakkaiset subagentit vai planner → implementer → reviewer.

Eristä muutos

Haara / työtila, jotta palautettavuus säilyy.

Delegoi toteutus

Agentti tai agentit tutkivat, toteuttavat, testaavat ja iterovat rajatussa vastuussa.

Verifioi riippumattomasti

Build, lint, testit, UX/use case, evidence tai erillinen reviewer.

Human gate riskin mukaan

Kriittinen päätös, merge tai tuotantotoimenpide ihmisellä.

Päivitä projektimuisti

Päätökset, tila, changelog ja avoimet asiat takaisin persistenttiin kontekstiin.

What next: leverage pitää muuttaa mitattavaksi vaikutukseksi

Kesän projektit osoittivat kvalitatiivisesti, että AI lisäsi tekemisen kapasiteettia. Seuraava askel on testata samaa periaatetta rajatussa oikeassa työprosessissa niin, että vaikutus voidaan mitata.

Ensimmäinen ehdokas

Change impact -analyysi

Sopiva pilotti, koska tehtävä on rajattavissa, toistettavissa ja sen lopputulosta voidaan verrata nykyiseen tapaan ilman että AI:lle tarvitsee antaa päätösvaltaa. Yrityksen sisäistä dataa käytettäessä pilotti vaatisi lisäksi rajatut identiteetit ja oikeudet, secrets-hallinnan, audit trailin sekä selkeät datarajat. Käytännön käyttöönotossa pitäisi arvioida myös kustannus per käyttötapaus sekä varmistaa, että AI-palvelun sopimus-, käsittely- ja säilytysehdot sallivat kyseisen datan käytön.

1 · Baselineläpimenoaika, ihmistyö, löydettyjen vaikutusten laatu

2 · Agentic workflowproject context, evidence rules, agenttiroolit ja review

3 · Comparesama tehtävä, sama arviointitapa

4 · Decideskaalaa, muuta tai hylkää tuloksen perusteella

Seuraava tavoite: ei rakentaa lisää demoja, vaan oppia missä agenttinen työ tuottaa organisaatiolle mitattavaa hyötyä ja millä kontrollimallilla sitä voidaan käyttää turvallisesti.