Edellinen postaus (#8) kuvasi blogin teknisen roolin Claude Coden kontekstina. Tämä postaus käsittelee miksi koko järjestely on olemassa ja mitä se opinnäytetyönä osoittaa.

Mitä blogi todella on

Blogin ydintarkoitus on tehdä prosessista läpinäkyvä opinnäytetyön raportoinnin näkökulmasta — tuottaa muistijälkiä joihin raportissa voidaan palata. Sama kirjoitustyö palvelee tämän lisäksi kolmea muuta tarkoitusta: julkista dokumentaatiota, Claude Coden työohjeistusta ja tehtävänhallintaa.

Tähänastinen blogin rakentaminen on ollut pilottivaihe — menetelmän testausta, ei varsinaista opinnäytetyön kohdetta. Varsinainen työ on Taskukello-sovelluksen kehitys, joka käynnistyy seuraavaksi. Pilotissa on todennettu että työnkulku toimii: luonnos kirjataan, Claude Code lukee sen kontekstina, toteuttaa Astro-muutokset, ja valmis työ muotoillaan raportiksi. Tekijä ei ole käytännössä koskenut koodiin.

Blogi projektin ontologiana

Sana dokumentaatio on harhaanjohtava. Se viittaa kuvaukseen — jälkikäteen kirjoitettuun selostukseen jostain joka on jo olemassa. Blogi tässä järjestelyssä on määrittävä, ei kuvaava. Se sanoo mitä asiat ovat, ei mitä ne sattuvat olemaan. Kun agentti lukee blogia toteuttaakseen muutoksia, blogi ei kerro miten asiat tehdään vaan päättää miten ne tehdään.

Tämä on epistemologinen siirto verrattuna tavanomaiseen ohjelmistoprojektiin. Tavallisesti totuus on koodissa, dokumentaatio on parhaimmillaan totta sen suhteen. Tässä järjestelyssä totuus on blogissa, koodi on sen instanssi. Agentti välittää käännöksen.

Tekijän työn taso on käsitteellinen, ei mekaaninen. Tekijä ei ohjelmoi sovellusta agentin avulla. Tekijä määrittää projektin ontologian luonnollisella kielellä ja agentti instantioi sen koodiksi. Vaikka portaaton jatkumo IntelliSensestä Copilottiin ja Claude Codeen pätee, päässä jossa tämä työ tapahtuu, työn luonne on muuttunut kategorisesti.

Rappeutumattomuus rakenteellisena ominaisuutena

Tavallinen projektidokumentaatio rappeutuu koska sen lukemisen ja kirjoittamisen välillä on viive. Kirjoittaja siirtyy seuraavaan tehtävään, dokumentti vanhenee hiljaa, virhe paljastuu kuukausia myöhemmin kun joku yrittää käyttää sitä ohjeena. Korjauskannustin on heikko koska kärsijä on usein eri henkilö kuin kirjoittaja.

Tässä järjestelyssä palautesilmukka on tiukka. Dokumentaatio on syöte agentille joka tekee seuraavan muutoksen. Virheellinen dokumentaatio tuottaa virheellisiä toteutuksia nopeasti. Kärsijä ja kirjoittaja ovat sama henkilö, ja palaute tulee vääjäämättä.

Tarkoitus on, että dokumentaation laatu ei perustu kuriin vaan sisäänrakennettuun toiminnalliseen pakkokytkentään. Dokumentaatiota ei tarvitse muistaa ylläpitää koska se ylläpitää itse itseään käytön kautta. Sama mekanismi pitää testit ajan tasalla CI-pipelinessä: rikkinäinen testi rikkoo buildin, joten se korjataan tai poistetaan.

Sivutuotteena työnohjausjärjestelmä

Tilamalli luonnos/yksityinen/julkinen toimii postausten muuttuvana luokitteluna työn edetessä, ja tagit toimivat tilasta riippumattomina suodattimina.

Yksittäinen postaus ei ole tehtävämäärittely jonka rinnalla pidettäisiin erillistä raporttia. Sama tiedosto toimii ensin tehtäväluonnoksena, sitten keskustelumuistiona toteutuksen aikana, ja lopulta valmiina raporttina kun status vaihtuu published. Issue ei sulkeudu vaan muotoutuu. Tehtävien historia on luettavissa kronologisena kertomuksena, ei tikettilistana.

Mitä työ osoittaa

Opinnäytetyö ei demonstroi perinteistä ohjelmointitaitoa. Se demonstroi kykyä hyödyntää tekoälyagentteja tehokkaasti lopputuotteen valmistamiseen. Tämä on legitiimi osaamisen kohde vuonna 2026 ja sillä on suora työelämäarvo.

Vastaväite kuuluu: “eihän tekijä ole itse rakentanut sovellusta”. Vastaus on rakennettu menetelmään sisään. Tarkoituskaan ei ollut rakentaa itse vaan rakentaa tehokkaasti agentin kanssa ja dokumentoida prosessi niin että muut voivat oppia siitä. Lopputuotteen lisäksi syntyy aineisto työnkuluista joita ei vielä ole vakiinnutettu.

Olennaista on mitä työ kokonaisuudessaan osoittaa: ongelman pilkkomista, kontekstin rakentamista, arkkitehtuuripäätöksiä, tulosten arviointia, virheellisten suuntien katkaisua. Andrej Karpathyn “Software 3.0” -muotoilu kuvaa tätä siirtymää: ohjelmoinnin painopiste siirtyy koodin kirjoittamisesta mallien ohjaamiseen ja kontekstin hallintaan (Hurja Solutions 2025). Tämä rakentaa edellisessä luvussa kuvatun ontologisen aseman päälle — tekijä määrittää, agentti instantioi.

Miksi tämä sopii ammattikorkeakouluun

AMK-opinnäytetyön tehtävä on osoittaa työelämärelevantti osaaminen ja tuottaa hyödynnettävää tietoa. Ei tuottaa tieteellistä teoriaa. AI-avusteinen kehitystyö on juuri sitä mitä työelämä on omaksumassa parhaillaan. Dokumentoitu, rehellinen, toistettavissa oleva kuvaus toimivasta työnkulusta on suoraan käyttökelpoista materiaalia muille kehittäjille ja organisaatioille.

Akateeminen arvo ei vaadi tieteellistä uutuusarvoa tiukassa merkityksessä. Se syntyy siitä että rehellinen prosessidokumentaatio on toistettavissa, kritisoitavissa ja vertailtavissa. Se on empiiristä aineistoa työnkuluista joita kentällä vasta vakiinnutetaan.

Ajoitus

Menetelmä osuu hetkeen jolloin työkalut ovat juuri tulleet käyttökelpoisiksi mutta käytänteet eivät ole vielä vakiintuneet. Claude Code 2.x kypsyi loppuvuonna 2025, auto memory ilmestyi v2.1.59:ssä alkuvuonna 2026. Spec-driven development ja context engineering vakiintuvat termeinä juuri parhaillaan.

Arene päivitti suosituksensa huhtikuussa 2026. Arenen tekoälysuositukset (päiv. 4/2026) käsittelevät vastuullista tekoälykäyttöä organisaatio-, opetus- ja opiskelutasolla — laajemmin kuin aiempi versio — ja tunnustavat tekoälyn vaikutuksen opinnäytteisiin. Päivityskään ei kuitenkaan ohjeista agenttipohjaista toteutusta. AMK-kohtaiset ohjeet kuten Centrian ja Diakin ohjeistukset käsittelevät tekoälyä edelleen ideoinnin ja kielentarkistuksen apuvälineenä.

Työ osuu juuri siihen kohtaan trendiä, johon virallinen ohjeistus ei vielä yllä. Sama työ vuotta aikaisemmin olisi ollut spekulatiivinen. Vuotta myöhemmin ehkä jo myöhästynyt.

Mitä lähimpänä on jo tehty

Verkossa löytyy osittaisia ennakkotapauksia. Alabê Duarten context engineering -työnkulku käyttää markdown-tiedostoja (kuten SEARCH_FEATURE.md) joihin dokumentoidaan ymmärrys ja päätökset ja jotka Claude Code lukee kontekstina. Aaron Heldin Hugo-blogi käyttää Claude Codea kirjoitusprosessissa ja viittaa aikaisempiin postauksiin kontekstina. Joe Karlssonin “treat content development like your open source project” on idean tasolla samansuuntainen mutta toteutus on Claude Code -skill blogin tuottamiseen. Heeki Parkin spec-driven development -postauksessa Claude Code yritti vahingossa hakea kirjoittajan omaa blogia kontekstiksi — juuri sitä mitä tämä projekti tekee tarkoituksellisesti.

Yhdistelmää — julkinen blogi joka samanaikaisesti raportoi opinnäytetyötä, dokumentoi omaa kehitystään, toimii AI-kontekstina, käyttää statusmallia tehtävänhallintana, ja jonka kohteena oleva sovellus on rinnakkainen mutta erillinen — ei tullut hakuihin. Tämä ei tarkoita ettei vastaavaa olisi tekeillä, mutta julkisesti indeksoituna tämä kombinaatio on harvinainen. Joe Karlssonin sanoin AI-avusteinen kehitystyö on yhä “crystallization phase” -vaiheessa, jossa kentällä kokeillaan, jaetaan ja hylätään käytäntöjä.

Mitä seuraa

Pilottivaiheen päättyessä menetelmä on todennettu pienessä mittakaavassa. Seuraava vaihe on Taskukello-sovelluksen kehitys, jossa sama työnkulku altistetaan suuremmalle ja monimutkaisemmalle kohteelle. Blogi jatkaa kasvuaan kehityksen mukana, ja sama silmukka jatkuu: luonnos, konteksti, toteutus, raportti.

Opinnäytetyön lopullinen muoto rakennetaan tämän blogiaineiston päälle. Postaukset ovat raakamateriaalia, ei valmiita lukuja. Mutta ne ovat sellaista raakamateriaalia jota syntyy työn ohessa, ei sen jälkeen erikseen kerättynä.