AI-avusteisesta työstä hallittuun toteutusmalliin

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. Se on kvalitatiivinen havainto suuremmasta tekemisen kapasiteetista, ei mitattu tuottavuusväite.

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

Johtamisnäkökulma: kokeilujen lopputulos ei ole uusi AI-työkalu vaan hallittu toteutusmalli työn suunnittelemiseksi AI:n ympärille.

Kun autonomia kasvaa, johtamisen paino siirtyy tavoitteisiin, kontekstiin, päätösoikeuksiin, evidenssiin, guardraileihin, verifiointiin ja human gate -kohtiin. Malli jäsentää toteutusta; enterprise-käytössä se nojaa edelleen organisaation laajempiin governance- ja päätösrakenteisiin.

Enterprise-rajaus: tuotantokäytössä tämä toteutusmalli asettuisi olemassa olevien organisaatiokontrollien sisään, kuten tietosuoja, tietoturva, sääntelyvelvoitteet, toimittajariski ja päätösoikeudet, eikä korvaisi niitä.

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.

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

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.

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ä.

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.

Investointipäätöksen analyysiTesti: 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 kvalitatiivinen havainto tekemisen leverage-vaikutuksesta, mutta ei vielä mitattu tuottavuusluku.

LeverageSuurempi tekemisen kapasiteetti on hypoteesi hyödystä, ei vielä business case ilman baselinea.

ManagementAI:n kanssa johdetaan yhä enemmän tavoitetta, kontekstia, rajoja ja kontrollipisteitä.

SelectionAgenttisuus sopii parhaiten rajattuihin, verifioitaviin ja palautettaviin tehtäviin.

ScaleOrganisaatiotason käyttöönotto vaatii mitatun pilotin ennen laajempaa rolloutia.

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ä erillinen AI-avusteinen tarkistuskierros.

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: leveragesta rajattuun end-to-end deliveryyn

Seuraava askel olisi testata mallia oikeassa työympäristössä yhden pienen, toistuvan ja palautettavan muutostyypin avulla. Tavoitteena ei olisi automatisoida koko delivery-prosessia kerralla, vaan selvittää vaiheittain, kuinka suuren osan siitä AI voi hoitaa turvallisesti ja mitattavasti ihmisten säilyttäessä päätösvastuun.

Pilotin koeasetelma

Rajattu end-to-end agentic delivery -pilotti

Pilottikohde valittaisiin mitattavan verifioitavuuden perusteella ja sitä pitäisi esiintyä riittävän usein oikean vertailun rakentamiseen — ei vain yhden demonstraation tekemiseen.

ValintakriteeriToistuvaRiittävästi vertailukelpoisia tapauksia baselinen muodostamiseen

ValintakriteeriPalautettavaRajattu blast radius ja palautettavat toimet

ValintakriteeriVerifioitavaLopputulos todennettavissa testein, säännöin tai mittarein — ei arviolla

Rajattu toimitusketjuAI toteuttaa määritellyn scopen sisällä; päätösvastuu säilyy ihmisillä

Tarvelopputulos

ImpactvaikutusalueHuman gate · impact-analyysi

DesignratkaisuHuman gate · ratkaisu / arkkitehtuuri

Buildtoteutus

Testevidence

Katselmoitu ehdokasrelease säilyy ihmiselläHuman gate · release-päätös

Rajattu toteutus: AI toimisi vain ennalta määritellyn tehtäväalueen, työkalujen, datan ja oikeuksien sisällä. Verifiointi, eskalaatiot ja jäljitettävyys määriteltäisiin etukäteen.

Enterprise-dataraja: sisäinen data vaatisi lisäksi rajatut identiteetit ja oikeudet, secrets-hallinnan, audit trailin, selkeät datarajat sekä yhteensopivat sopimus-, käsittely- ja säilytysehdot.

01BaselineMittaa riittävästi vertailukelpoisia tapauksia: läpimenoaika, tuottaminen vs. verifiointi, laatu, uudelleentyö ja kustannus per muutos.

02Bounded workflowMääritä konteksti, evidence, sallitut työkalut, kielletyt toimet, verifiointi, päätösportit ja jäljitettävyys.

03VertailuKäytä samoja perusmittareita ja lisää huomaamatta jääneet vaikutukset, myöhemmät virheet, kontrollit, eskalaatiot ja ihmisen puuttuminen.

04PäätösEtene vain, jos evidence tukee sitä. Muussa tapauksessa muuta toimintamallia tai lopeta.

Kaksi erillistä päätöstä, tässä järjestyksessäLaajempi scope ei automaattisesti tarkoita suurempaa autonomiaa.

Päätös ALaajenna scopeaLaajenna workflow'ta useampaan toimitusketjun vaiheeseen päätösportit ennallaan.

→

Päätös BNosta autonomiaaVasta siellä, missä verifiointi ja kontrollit ovat jo osoittautuneet riittävän luotettaviksi.

Johtamisoppi: tavoite ei ole maksimaalinen autonomia, vaan korkein turvallinen, verifioitava ja osoitetusti hyödyllinen autonomian taso enterprise deliveryssä. Autonomia ei ole lähtöoletus, vaan se ansaitaan evidencellä. Jos näyttö ei tue etenemistä, toimintamallia muutetaan tai pilotti lopetetaan.