Claude Opus 5 voi koodata tunteja itsekseen. Mitkä POS-järjestelmän osat vaativat edelleen muutakin kuin koodia?

POS-järjestelmän ne osat, jotka vaativat edelleen muutakin kuin koodia, ovat niitä, jotka koskettavat rahaa ja fyysistä maailmaa: maksunvälityssopimukset, PCI-yhdenmukaisuus (korttialan turvallisuussäännöt korttitietojen käsittelyyn), sertifioidut lähimaksu- ja sirupäätteet sekä kirjanpito, jonka on oltava oikein joka ainoa kerta. 24. heinäkuuta 2026 julkaistu Claude Opus 5 voi pyörittää koodaussessioita tunteja vähäisellä valvonnalla¹. Mikään noista tunneista ei kuitenkaan luo kauppiaantiliä.

Tämän kirjoituksen malliversiot ja päivämäärät ovat tarkkoja julkaisuhetkellä; pidä yksityiskohtia tilannekatsauksena.

Mitä Claude Opus 5 todella muutti?

Anthropic kuvailee mallia, joka on rakennettu pitkäkestoisille agenteille: se suunnittelee harkitusti, tarkistaa oman työnsä ja toimii pidempään ja autonomisemmin kuin aiemmat Opus-mallit². Anthropicin vaativimmassa ohjelmistotekniikan suorituskykytestissä se enemmän kuin kaksinkertaisti edeltäjänsä tuloksen¹. Ensimmäiset testaajat kertovat antaneensa sille töitä, jotka aiemmin jouduttiin jakamaan moniin pienempiin osiin, ja saaneensa takaisin valmiita tuloksia.

Tämä on todellinen muutos, ja se vahvistaa ilmiötä, jota käsittelimme silloin kun GPT-5.6 julkaistiin: muutaman kuukauden välein yhdellä kehotteella saatavan toimivan ohjelmiston määrä kasvaa. Kassanäkymä, jonka kehottaminen vei viime vuonna viikon, vie nyt iltapäivän, ja Opus 5:n myötä malli jatkaa työtä senkin jälkeen, kun poistut paikalta.

Miksi pidempi koodausaika ei vie työtä maaliin?

Koska kassajärjestelmän vaikeimmat osat eivät ole koodin muotoisia ongelmia. Autonominen malli tuottaa enemmän koodia ja paremmin tarkastettua koodia. Se ei kuitenkaan voi tuottaa riskinarviointipäätöstä, laitesertifiointia tai turvallisuustarkastusta, riippumatta siitä kuinka kauan se pyörii. Ne tulevat instituutioilta, eivät kääntäjiltä.

Toinen, hienovaraisempi raja on olemassa. Opus 5:n merkittävin taito on oman työnsä tarkistaminen, ja tarkistaminen vaatii vertailukohtaa todellisuudesta. Malli voi testata, että sen kassalaskutoimitukset täsmäävät. Se ei voi testata toimintaa todellista korttiverkkoa, todellista tilitysaikataulua (milloin korttivarat tosiasiallisesti saapuvat pankkiisi) tai todellista veroviranomaista vastaan, koska mitään näistä ei ole olemassa koodaushiekkalaatikossa. Koodi voi olla täysin sisäisesti loogista ja silti kohdata todellisuuden vasta ensimmäistä kertaa kassatiskilläsi.

Mitkä POS-järjestelmän osat vaativat edelleen muutakin kuin koodia?

Pääasiassa neljä asiaa.

• Rahan liikuttaminen. Kortin veloittaminen vaatii suhteen maksunvälittäjään (yhtiöön, joka tilittää korttivarat pankkiisi): riskinarvioinnin, tilitysaikataulut, petosten valvonnan ja reklamaatioiden käsittelyn. Mikään koodaussessio ei tuota hyväksyttyä kauppiaantiliä.

• Korttitietojen turvallisuus. PCI-yhdenmukaisuus koskee kaikkia järjestelmiä, jotka koskettavat korttinumeroita. Generoitu kassakoodi, joka käsittelee korttitietoja, jättää auditointitaakan sinulle; sertifioitu maksuinfrastruktuuri on olemassa juuri siksi, että kauppiaat välttyvät tältä taakalta.

• Korttipäätteet (Card-Present). Lähimaksu- ja sirumaksut pyörivät sertifioiduilla päätelaitteilla, joiden turvallista laiteohjelmistoa kumpikaan ei pääse kirjoittamaan ad hoc. Se on sama seinä, johon vibe-koodatut maksusovellukset törmäävät tullessaan hylätyksi App Storesta: esteinä ovat käyttöoikeudet ja sertifioinnit, eivät koodin laatu.

• Aina oikein oleva kirjanpito ja varasto. Varasto, joka kestää kaksi samanaikaista myyntitapahtumaa, sekä raportit, jotka täsmäävät (vastaavat todellisuudessa saapunutta rahaa), ovat teknisesti koodia – mutta koodia, jonka on oltava oikein aina ja ikuisesti. Kartoitimme tätä seinää artikkelissa Vibe Coding a Point of Sale. Opus 5 kirjoittaa tällaista koodia paremmin kuin mikään malli ennen sitä, mutta et silti halua sen ensimmäisen tuotantotestin tapahtuvan lauantairuuhkassasi.

Mitä Claude Opus 5:n sitten kannattaa antaa rakentaa?

Kaikkea kyseisen rajan yläpuolella: näkymät, vuon, logiikan ja toimialakohtaisen käyttäytymisen, joka saa POS-järjestelmän sopimaan yrityksellesi valmiin mallipohjan sijaan. Tämä kerros on koodia, ja Opus 5 on tällä hetkellä kiistatta vahvin työkalu siihen.

Käytännön reitti on MCP (Model Context Protocol, avoin standardi, jonka avulla tekoälytyökalut kytkeytyvät muihin ohjelmistoihin). Sen sijaan, että pyytäisit mallia rakentamaan maksut tyhjästä, yhdistät sen alustaan, jossa rahanliike, laitesertifiointi ja vaatimustenmukaisuus ovat jo olemassa, ja annat sen rakentaa kassan sen päälle. Olemme kirjoittaneet aiemmin erosta alustojen, joita tekoäly voi käyttää, ja alustojen, joiden päälle tekoäly voi rakentaa, välillä. Autonomiset mallit tekevät jälkimmäisestä kategoriasta paljon tärkeämmän, koska malli voi nyt viedä rakentamisen pitkälle ilman sinua.

Finalin Build toimii näin: rakentaja on kehotepohjainen, kuvailet haluamasi vuon tai yhdistät oman tekoälysi MCP-protokollan kautta, ja vuo otetaan käyttöön infrastruktuurissa, jossa Final Pay, sertifioidut maksupäätteet ja taustalla oleva kirjanpito on jo hoidettu. Miten käyttää Claude Fable 5:ttä toimivan POS-järjestelmän rakentamiseen käy läpi, miltä tämä näyttää Opus 5:n suuremman sisarmallin kanssa.

Mitkä POS-järjestelmän osat vaativat siis edelleen muutakin kuin koodia?

Ne, jotka päättyvät sopimukseen, sertifiointiin tai tilitykseen: maksunvälitys, PCI-yhdenmukaisuus ja korttipäätteet sekä tietueet, joiden on oltava oikein joka kerta. Claude Opus 5 muutti sitä, kuinka paljon POS-järjestelmää koodaussessiolla voi saada aikaan. Se ei muuttanut sitä, mitä koodaussessio voi tuottaa. Hyödyllinen nyrkkisääntö: jos tehtävä päättyy koodiin, anna se mallille; jos se päättyy sopimukseen, sertifiointiin tai rahan liikkumiseen, anna se infrastruktuurille.

Jos haluat nähdä, missä raja kulkee käytännössä, yhdistä oma tekoälysi Buildiin MCP:n kautta ja anna mallin tehdä se osa, jossa se on nyt erittäin hyvä.