1. Johdanto

Suurimman osan ohjelmistojen historiasta niukka resurssi oli kirjoittaminen. Kehittäjän taito mitattiin kyvyssä muuttaa aikomus oikeaksi koodiksi, ja tunnit kuluivat kirjoittamiseen, asioiden selvittämiseen, kirjastojen yhteen kytkemiseen ja niiden pienten virheiden korjaamiseen, jotka käännösvirheet ja epäonnistuvat testit paljastivat. Kyvykäs koodausagentti poistaa suurimman osan tästä. Anna sille selkeä ohje ja pääsy koodikantaan, ja se tuottaa toimivan muutoksen minuuteissa, idiomeilla jotka se on nähnyt miljoona kertaa ja joissa pohjakoodi on jo valmiiksi oikein. Puhekielinen nimi tälle työtavalle, joka yleistyi alkuvuonna 2025, on vibe coding: kuvailet mitä haluat ja annat mallin tuottaa sen, ohjaten tuloksilla etkä kirjoittamalla jokaista riviä. Se on aidosti harppaus, ja sen on helppo erehtyä luulemaan koko tarinaksi.

Se ei ole koko tarina, koska koodin ilmestyminen ei koskaan ollut ohjelmistojen vaikea osa, vain työläs osa. Vaikeat osat ovat sen päättäminen mitä rakennetaan ja sen tietäminen, että rakennettu on tosiasiassa oikein, turvallista ja ajokelpoista. Nämä eivät halpene kun tuottaminen halpenee; jos jotain, ne vaikeutuvat, koska ymmärrettävää koodia on nyt paljon enemmän, tuotettuna nopeammin kuin ihminen sen kirjoitti, tekijän toimesta joka on itsevarma silloinkin kun on väärässä. Ohjelmistokehityksen pullonkaula siirtyy. Se sijaitsi ennen tuottamisessa, siinä kuinka nopeasti tiimi pystyi kirjoittamaan oikeaa koodia. Agentin kanssa se sijaitsee todentamisessa: siinä kuinka nopeasti tiimi voi olla varma että koodi on oikein ja päästää sen läpi.

Tämä artikkeli käsittelee tuon muutoksen seurausta työkaluille, ja se on tarkoituksella konkreettinen. Jos todentaminen on rajoite, niin arvokkain asia jonka tekoälyavusteinen kokoonpano voi tehdä, ei ole tuottaa nopeammin vaan auttaa tiimiä todentamaan nopeammin ja turvallisemmin, napaten agentin virheet halvalla ja aikaisin. Kuvaamme sen täsmällisen ketjun, jota me Nashualla käytämme oman tuotteemme, Nashua 360 Enterprise Platformin, rakentamiseen ja ylläpitoon — Claude Code agenttina, GitHub versionhallittuna selkärankana ja katselmointiporttina, Vercel jokaisen muutoksen ajossa olevaa esikatselua varten, Next.js sovelluskehyksenä ja Postgres tietokantana — ja käymme läpi kuinka kukin osa tosiasiassa toimii, koska arvo on yksityiskohdissa. Kukin linkki ansaitsee paikkansa kiristämällä silmukkaa tai lisäämällä portin, ei olemalla yksinään nokkela.

Kontribuutio on argumentti ja perusteltu suositus, ei vertailumittaus. Luku 2 esittää sen mitä tekoäly muutti ja mitä se ei muuttanut, ja paikantaa pullonkaulan. Luku 3 esittelee ketjun silmukkana (Kuva 1), perustelee että agenttiavusteisessa työssä best-of-breed tarkoittaa konventionaalista, ja selittää miksi riippumattomat portit kertautuvat. Luvut 4–9 ottavat viisi osaa vuorollaan ja syventyvät niiden sisuksiin, mukaan lukien se ajonaikainen arkkitehtuuri joka julkaisulla tosiasiassa on (Kuva 2) ja se osa joka yllättää ihmiset, nimittäin että muutos voidaan nyt aloittaa ja katselmoida puhelimesta. Luvut 10–12 käsittelevät ihmisporttia ja sen vikatiloja, todelliset kustannukset sekä sen kuinka ketju toimii käytännössä. Läpikäyvä kysymys on: kun agentti osaa kerran kirjoittaa koodin, mitä tiimin tulisi asettaa sen ympärille, jottei nopea kirjoittaminen tarkoita väärän toimittamista?

2. Mitä tekoäly muutti ja mitä ei

2.1 Muutos

Agentin tuoma muutos on parasta ilmaista täsmällisesti. Kyse ei ole siitä, että kone nyt ymmärtäisi ongelman; kyse on siitä, että hyvin määritellyn muutoksen uskottavan, usein oikean, toteutuksen tuottamisen kustannus on romahtanut. Kehittäjä, joka olisi käyttänyt iltapäivän yhteen ominaisuuteen, voi saada ensimmäisen version siinä ajassa jonka sen kuvaileminen vie, ja voi heittää useita versioita pois halvalla. Työn tapa siirtyy kirjoittamisesta ohjaamiseen: aikomuksen ilmaisemiseen, tulosten lukemiseen, suunnan korjaamiseen. Tämä on todellista vipuvoimaa, ja tiimi joka kieltäytyy siitä jää jälkeen.

2.2 Ei hopealuotia

Muutos on myös rajattu, ja raja on vanha. Brooks (1987) teki erottelun joka hallitsee täälläkin yhä: ohjelmiston satunnainen monimutkaisuus, se työ jonka työkalumme ja kielemme pakottavat eikä itse ongelma, voidaan ottaa kohteeksi ja sitä voidaan vähentää, mutta olennaista monimutkaisuutta, ongelman ymmärtämistä ja oikean ratkaisun määrittelemistä, ei voida automatisoida pois, koska se on itse ongelma. Koodausagentti on voimakkain satunnaiseen monimutkaisuuteen tähän asti rakennettu hyökkäys: se imee syntaksin, pohjakoodin, API-haut ja idiomit. Olennaiselle se ei tee mitään. Sen tietäminen mitä liiketoiminta tarvitsee, oikean suunnittelun päättäminen ja sen osoittaminen, että tietty muutos tosiasiassa täyttää tarpeen rikkomatta jotakin muuta, pysyvät ihmisen työnä, ja ne ovat sitä työtä joka oli aina vaikeaa.

2.3 Todentamisesta tulee rajoite

Pane nämä kaksi yhteen ja johtopäätös seuraa. Tuottaminen, se satunnainen osa, on nyt nopeaa ja halpaa. Todentaminen, se missä olennainen asuu — että tämä muutos on oikein, että se tekee mitä haluttiin, ettei se ole rikkonut mitään, että se on turvallista julkaista — ei ole. Missä tahansa putkessa läpivirtaus määräytyy hitaimman vaiheen mukaan, ja kun tuottaminen kiihtyy todentamisen ohi, todentamisesta tulee sitova rajoite. Tiimi joka pystyy tuottamaan kymmenen muutosta päivässä mutta todentamaan kaksi, toimittaa kaksi ja kerryttää jonon todentamatonta koodia, joka on rasite, ei voimavara. Vielä pahempaa, agentti tuottaa itsevarmaa, pinnallisesti oikeaa työtä, joten alitodentamisen kustannus — oikealta näyttävän mutta vääränä olevan yhdistämisen — nousee täsmälleen samaa tahtia kuin kiusaus tehdä niin. Tämän artikkelin loppu käsittelee sellaisen ketjun rakentamista, jonka tehtävä on nostaa todentamisen kattoa ja tehdä alitodentamisesta vaikeaa.

3. Ketju, ja miksi konventionaalinen voittaa

3.1 Silmukka

Hyvä tekoälyavusteinen kokoonpano on silmukka, ei työkalu. Kuva 1 piirtää sen jota käytämme. Kehittäjä ilmaisee aikomuksen. Claude Code, agentti, muuttaa sen muutokseksi haaraan, ei elävään koodiin. Muutoksesta tulee GitHub-pull request, jossa kaksi automaattista porttia ajetaan kenenkään huomiota vaatimatta: tyyppitarkistin ja jatkuvan integraation testipaketti. Vercel rakentaa haarasta todellisen, ajossa olevan esikatselujulkaisun — täyden kopion sovelluksesta muutos elävänä, tavoitettavissa omassa URL:ssaan. Ihminen katselmoi muutoksen, lukien diffin ja klikaten esikatselun läpi, työpöydällä tai, yhä useammin, puhelimella. Vasta sitten se yhdistetään main-haaraan, jonka Vercel julkaisee tuotantoon Postgresin tukemana. Lopputulos ruokkii seuraavaa aikomusta. Kaavion pointti on se, että agentti miehittää yhden laatikon; jokainen muu laatikko on silmukan sulkeutuminen tai portin nappaaminen, ja juuri sieltä turvallisuus ja nopeus tulevat.

3.2 Best-of-breed tarkoittaa konventionaalista

Tavanomainen tapa valita työkaluja on asettaa ne tehon mukaan järjestykseen ja poimia kyvykkäin. Agenttiavusteiselle ketjulle kriteeri on toinen, ja se on tämän artikkelin yksittäinen hyödyllisin ajatus. Agentti kirjoittaa parhaiten niitä työkaluja joita se on nähnyt eniten. Sen osaaminen kehyksessä tai tietokannassa on funktio siitä, kuinka paljon tuota työkalua käyttävää oikeaa koodia oli sen koulutuksessa, ja tuo määrä seuraa työkalun suosiota, sen dokumentaatiota ja sen konventioiden vakautta. Valtavirtainen, hyvin dokumentoitu, konventiorikas työkalu ei siis ole vain turvallinen ihmisen valinta; se on se valinta jossa agentti on kyvykkäin ja epätodennäköisimmin keksii API:n jota ei ole olemassa. Vaikutus kertautuu: suositut työkalut saavat enemmän agentin tuottamaa koodia, joka toimii, mikä vahvistaa niiden suosiota. Tekoälyavusteisessa kehityksessä best-of-breed ja konventionaalisin ovat yhtyneet, ja jokainen Taulukon 1 työkalu valittiin se mielessä. Tämä on myös varoitus: se eksoottinen kehys jota ihmisasiantuntija voisi käyttää loistavasti, on usein juuri se missä agentti on heikoin, koska se on nähnyt sitä vähiten.

3.3 Miksi riippumattomat portit kertautuvat

Ketju ei luota mihinkään yksittäiseen tarkistukseen. Se todentaa muutoksen useiden porttien kautta, jotka katsovat aidosti eri asioita: tyyppitarkistin tarkistaa muodot, jatkuvan integraation testit tarkistavat käyttäytymisen, esikatselujulkaisu näyttää ajossa olevan tuloksen ja ihmiskatselmoija arvioi aikomuksen. Koska portit ovat suurelta osin riippumattomia, niiden ohitukset kertautuvat sen sijaan että ne summautuisivat: vika saavuttaa tuotannon vain jos jokainen portti epäonnistuu nappaamaan sen, joten neljä vaatimatonta porttia, joista kukin nappaa suurimman osan näkemästään, päästää läpi vain pienen murto-osan siitä, minkä ne tulona jättävät huomaamatta. Tämä on syvyyspuolustuksen periaate, joka on turvallisuustekniikassa pitkään tunnettu epätäydellisten esteiden kerrostamisena (Reason, 2000), ja sillä on terävä käytännön seuraus. Yhden portin poistaminen tai heikentäminen — esikatselun ohittaminen, strict-tyypin sammuttaminen, hyväksyminen lukematta — ei lisää vähän riskiä; se kertoo läpipääsyasteen sillä käänteisluvulla, jonka tuo portti ennen nappasi. Halvin tapa pysyä turvassa on pitää useat erilaiset, epätäydelliset portit rehellisinä, mikä on juuri se mitä ketju on järjestetty tekemään.

4. Agentti: kuinka Claude Code sopii

Claude Code on agentti: työkalu joka lukee koodikantaa, kirjoittaa ja muokkaa tiedostoja, ajaa komentoja, suorittaa testit ja avaa pull requesteja, työskennellen ohjeesta ja korjaten itseään näkemiään tuloksia vasten. Se kuinka sitä ajetaan merkitsee enemmän kuin mallin raaka kyvykkyys, ja kolme siihen liittyvää asiaa ansaitsee käytännön toimijan huomion.

Ensimmäinen on konteksti. Agentti on vain niin hyvä kuin se mitä se tietää koodikannastasi, ja yksittäinen suurimman vipuvoiman artefakti on versionhallintaan tallennettu sääntötiedosto, meidän tapauksessamme projektin CLAUDE.md, joka kertoo agentille talon säännöt: kuinka projekti on järjestetty, kuinka tyyppitarkistin ja testit ajetaan, mitä julkaistaan ja miten, mihin ei koskaan kosketa. Agentti lukee sen joka ajolla, joten kerran kirjattu korjaus lakkaa toistumasta. Sen ympärillä on laajempi pinta: uudelleenkäytettäviä skillejä toistuviin tehtäviin, hookeja jotka ajetaan työkalukutsuilla säännön mekaaniseksi pakottamiseksi, ja MCP-palvelimia jotka antavat agentille tyypitetyn pääsyn ulkoisiin järjestelmiin, GitHub niiden joukossa, niin että se voi avata ja päivittää pull requesteja ensiluokkaisina toimintoina eikä ruutua raaputtamalla. Kontekstin rakentaminen — sen päättäminen mitä agentin tulisi tietää ja osata tehdä — on agentin käyttöönoton todellinen työ, ja se on tavallista ohjelmistohygieniaa: kirjaa konventiot, tee tarkistuksista ajettavia, pidä pinta pienenä.

Toinen on se, että agentti toimii silmukassa eikä eristyksissä. Sen odotetaan ajavan tyyppitarkistin ja testit itse, lukevan mitä ne raportoivat ja korjaavan sen ennen kuin yksikään ihminen katsoo, niin että ketjun automaattiset portit ovat jo vihreällä siihen mennessä kun pull request avataan. Suurempia tehtäviä varten se voi hajauttaa työtä aliagenteille, jotka kukin kantavat omaa kontekstiaan ja raportoivat takaisin, mikä pitää pääsäikeen fokusoituneena ja kontekstin puhtaana. Kuri on antaa nopean, halvan palautteen — tyyppien ja testien — tapahtua agentin oman silmukan sisällä, ja varata hidas, kallis palaute — ihminen — loppuun.

Kolmas on se missä se ajetaan. Terminaalin lisäksi Claude Code toimii pilvi-istuntona, joka on tavoitettavissa mobiilisovelluksesta, mikä muuttaa työpäivän muotoa. Muutos voidaan aloittaa puhelimesta matkalla jonnekin, jättää ajamaan pilveen, ja sen pull request ja esikatselu katselmoida ja hyväksyä samasta puhelimesta myöhemmin. Olemme tässä tarkoituksellisia emme siksi että mobiilityö olisi uutuus vaan siksi että se lyhentää silmukkaa: väli jonkin huomaamisen ja muutoksen aloittamisen välillä, ja muutoksen valmistumisen ja sen hyväksymisen välillä, kutistuu tunneista minuuteiksi, mikä todentamissidonnaisessa maailmassa on juuri se väli jonka sulkeminen kannattaa.

5. Selkäranka: GitHub

GitHub on se ketjun osa joka tekee kaikesta muusta turvallista, ja se on vähiten säihkyvä. Se pitää hallussaan yhden totuuden lähteen, repositorion, ja se pakottaa sen säännön jonka varassa koko argumentti lepää: main-haara, se joka toimittaa tuotantoon, on suojattu ja siihen pääsee vain pull requestin kautta, jonka ihminen on hyväksynyt ja jonka vaaditut tilatarkistukset ovat läpäisseet. Agentti ei koskaan muokkaa tuotantokoodia suoraan; se ehdottaa, haarassa, ja ehdotus on diff jonka ihminen voi lukea ja kone voi testata.

Vaaditut tarkistukset ovat siellä missä automaattiset portit asuvat. Jokaisessa pull requestissa GitHub Actions ajaa sen paketin jonka vaadimme ennen kuin mitään yhdistetään: tyyppitarkistin, linter, testipaketti ja tuotantokäännös, kukin vaadittu tila joka estää yhdistämispainikkeen kunnes se on vihreä. Koska näitä pakottaa alusta eikä kenenkään kuri, niitä ei voi ohittaa kiireessä, ja koska agentti tietää niiden ajettavan, se täyttää ne ensin. Pull request on muutoksen yksikkö: pieni, itsenäinen, yksittäin katselmoitavissa ja yksittäin peruutettavissa, mikä pitää katselmoinnin halpana ja historian luettavana. Ja koska jokainen muutos on commit tekijöineen ja viesteineen, historia on jäljitysketju ja kumoaminen on täydellinen — kaikki mitä agentti teki voidaan nähdä, kohdistaa ja peruuttaa. Koodausagentti on nopea, voimakas ja erehtyväinen toimija, ja GitHub on se rakenne joka tekee sellaisen irti päästämisestä turvallista varmistamalla, ettei mikään mitä se tekee ole katselmoimatonta, testaamatonta tai peruuttamatonta.

6. Silmät: Vercel

Diffin lukeminen kertoo mikä muuttui; se ei kerro mitä muutos tekee. Vercel sulkee tuon kuilun rakentamalla jokaisesta pull requestista esikatselujulkaisun: täydellisen, eristetyn, ajossa olevan sovelluksen ilmentymän muutos sovellettuna, omassa URL:ssaan, luotuna automaattisesti ja päivitettynä jokaisella pushilla. Tämä on se portti joka nappaa sen mitä tyypit ja testit eivät — rikkoutuneen asettelun, yhden askeleen pidentyneen kulun, sen asian joka on teknisesti oikein mutta käytössä väärin — ja se on suurin osa siitä miksi ketju voi liikkua nopeasti liikkumatta sokkona. Katselmoija, ja agentti, klikkaavat läpi todellisen tuloksen sen sijaan että kuvittelisivat sen koodista.

Mikä tekee esikatselusta luotettavan on se, että se on koko pinon todellinen käännös, ei jäljitelmä (Kuva 2): sama kehys, sama ajoympäristö, omat ympäristömuuttujansa ja, hyvin tehtynä, oma eristetty tai haaroitettu tietokantansa niin, ettei sen käyttäminen voi koskettaa tuotantodataa. Julkaisut ovat muuttumattomia: kukin on erillinen, osoitettavissa oleva käännös, joten katselmoidun esikatselun ylentäminen tuotantoon on osoittimen siirto eikä uudelleenkäännös, ja huono julkaisu on välitön paluu edelliseen muuttumattomaan julkaisuun eikä kuumeinen hätäkorjaus. Kun yhdistetään main-haaraan, sama koneisto joka rakensi esikatselun rakentaa tuotannon, joten se mikä katselmoitiin on se mikä toimitetaan. Tämän ketjun mallissa esikatselujulkaisut ovat halpa, automaattinen todentamisportti, jonka nappausaste on korkea sellaiselle vikaluokalle jota mikään muu portti ei näe.

7. Saumaton gitin ansiosta: miksi nämä kolme sopivat yhteen

Syy siihen, että Claude Code, GitHub ja Vercel tuntuvat vähemmän kolmelta työkalulta ja enemmän yhdeltä järjestelmältä on se, että ne jakavat yhden rajapinnan, ja tuo rajapinta on git. Claude Coden luontainen tuotos ei ole julkaisu; se on haara ja pull request. GitHubin tehtävä on säilöä nuo commitit, ajaa tarkistukset ja pitää katselmointi. Vercel tarkkailee repositoriota ja muuttaa jokaisen haaran esikatseluksi ja main-haaran tuotannoksi. Yhdellekään niistä ei tarvinnut opettaa toisista: agentti ei koskaan opi julkaisu-API:a, se avaa pull requestin; Vercel ei koskaan opi agentista, se tarkkailee repoa. Sauma niiden välillä on git-protokolla, jota kaikki kolme jo puhuvat, minkä vuoksi agentin lisääminen ketjuun ei muuttanut mitään siinä kuinka julkaisu toimi, ja minkä vuoksi koko polulla kehotteesta tuotantoon ei ole yhtään luovutusta.

Seuraus on se, että julkaisu lakkaa olemasta askel jonka joku suorittaa ja muuttuu seuraukseksi siitä git-toiminnosta jonka he aikoivat joka tapauksessa tehdä. Push on käännös. Pull request on esikatseluympäristö, luotuna ja purettuna omin päin. Yhdistäminen main-haaraan on tuotantojulkaisu. Peruutus on paluu edelliseen. Kukaan ei aja julkaisua; he yhdistävät, ja julkaisu tapahtuu. Ei ole käännöspalvelinta vahdittavana, ei julkaisuskriptiä jonka agentti voisi tehdä väärin, ei erillistä ylennystyökalua, ei ikkunaa jossa joku on kirjoittanut koodin mutta ei vielä toimittanut sitä. Todentamissidonnaiselle tiimille tämä on juuri oikea paikka poistaa kitkaa: ainoa tarkoituksellinen, inhimillinen teko joka polulle jää on katselmointi, joka on se yksi teko jonka tulisi olla tarkoituksellinen, ja kaikki sitä ympäröivä mekaaninen on gitiä tarkkailevien työkalujen hoidossa.

Tämä on myös syy siihen miksi saumattomuus on turvallista eikä holtitonta, ja nämä kaksi ominaisuutta tulevat samasta tosiasiasta. Koska julkaisu ratsastaa gitin päällä, se perii gitin takeet: jokainen tuotantojulkaisu on sidottu tiettyyn katselmoituun committiin tekijöineen ja viesteineen; jokainen esikatselu on sidottu haaraan; ja koska julkaisut ovat muuttumattomia, paluu edelliseen on vain tuotannon osoittaminen aiemman commitin käännökseen. Sama johdotus joka antaa muutoksen virrata puhelimella kirjoitetusta kehotteesta elävälle sivustolle kenenkään koskematta julkaisukonsoliin varmistaa myös, ettei mikään saavuta tuota elävää sivustoa muuten kuin katselmoidun, kohdistettavan, peruutettavan commitin kautta. Integraatio on yhteensopiva ei siksi että toimittajat koordinoivat sitä vaan siksi että kaikki kolme rakennettiin kohtelemaan gitiä totuuden lähteenä, ja kun agentti liittyi tuohon konventioon, sen tarvitsema putki oli jo valmiina.

8. Maasto: Next.js

Agentin on navigoitava koodikannassa, ja koodikannan kehys on maasto. Next.js on vahva valinta kahdesta syystä, jotka molemmat palaavat todentamiseen. Ensimmäinen on se, että se on TypeScript, ja tyypit ovat ensimmäinen ja halvin portti. Strict-tilassa ajettuna tyyppitarkistin hylkää suuren luokan virheitä — väärän muodon, puuttuvan kentän, arvon joka saattaa olla null — sillä hetkellä kun agentti kirjoittaa sen, mikä on juuri silloin kun korjaus on halvin, ennen kuin koodi ajetaan ja kauan ennen kuin ihminen katsoo. Työnnämme saman ajatuksen ohjelman reunoille validoiden ulkoisen syötteen, pyyntöjen rungot, ympäristömuuttujat ja tietokannan rivit skeemaa vasten, niin että tyypittämätön data ulkopuolelta muuttuu tyypitetyksi ja tarkistetuksi rajalla sen sijaan että siihen luotettaisiin. Tyypit eivät ole täällä byrokratiaa; ne ovat se portti joka muuttaa agentin yleisimmän virheen — uskottavan muodon joka on hienovaraisesti väärin — punaiseksi aaltoviivaksi jonka se korjaa itse.

Toinen syy on se, että Next.js on konventionaalinen, ja sen malli, vaikka rikas, on tarpeeksi kuljettu jotta agentti kirjoittaa sitä sujuvasti. Tuosta mallista kannattaa olla konkreettinen, koska siinä elää suuri osa insinöörityöstä. App Router renderöi oletuksena palvelimella: Server Components -komponentit ajetaan palvelimella eivätkä koskaan toimita koodiaan selaimeen, pitäen datapääsyn ja salaisuudet palvelinpuolella, kun taas Client Components -komponentit, eksplisiittisesti merkittyinä, kantavat interaktiivisuuden. Mutaatiot kulkevat Server Actions -funktioiden kautta, palvelinfunktioiden joita lomake tai painike voi kutsua suoraan, ja Route Handlers tarjoaa API-pinnan. Kukin reitti valitsee kuinka se renderöi — staattisesti käännösaikaan, inkrementaalisesti aikataulun mukaan uudelleen generoituna tai dynaamisesti pyyntökohtaisesti — ja missä se ajetaan, kevyessä Edge-ajoympäristössä lähellä käyttäjää vai täyteläisemmässä Node.js-ajoympäristössä, middlewaren ajautuessa ennen pyyntöä hoitamaan esimerkiksi todennuksen ja kieliasetuksen. Näitä on paljon vipuja, mutta ne ovat julkisia, dokumentoituja, vakaita vipuja jotka agentti on nähnyt oikein käytettyinä mittakaavassa, joten se tarttuu oikeaan, ja kehys on tarpeeksi voimakas rakentamaan todellisen tuotteen pysyen samalla maastona jolla agentti on kyvykkäin, mikä luvun 3 argumentin mukaan on se yhdistelmä joka merkitsee.

9. Tila: Postgres

Kaikki yllä koskee koodia, jota on turvallista muuttaa koska se on versioitua ja peruutettavaa. Data ei ole: pudotettu sarake tai huono migraatio voi tuhota jotakin, mitä mikään commit ei voi palauttaa. Postgres on se kestävä, transaktionaalinen tila ketjun pohjalla, ja sitä ympäröivä kuri on tarkoituksella tiukempaa kuin koodia ympäröivä. PostgreSQL ansaitsee paikkansa samalla tavalla kuin muu ketju — se on konventionaalinen, taistelussa koeteltu, suurenmoisesti dokumentoitu valinta, joten agentti kirjoittaa oikeaa SQL:ää ja oikeita migraatioita sitä vasten, ja hallinnoitu instanssi poistaa operatiivisen vaivan muuttamatta mallia.

Huolellisuus kohdistuu muutokseen. Skeemamuutokset ovat migraatioita: järjestettyjä, versioituja tiedostoja jotka tallennetaan repositorioon ja katselmoidaan kuten mikä tahansa muu muutos, ajetaan esikatselua vasten ennen tuotantoa ja kirjoitetaan peruutettaviksi. Elävää tietokantaa ei voi muuttaa samalla tavalla kuin tuoretta, joten riskialtis muutos tehdään turvallisten muutosten sarjana, expand and contract -mallilla (Ambler & Sadalage, 2006): lisää uusi sarake tai taulu ja ala kirjoittaa siihen, täytä takautuvasti, siirrä luvut sen yli, ja vasta sitten, myöhemmässä julkaisussa, poista vanha muoto, niin että jokaisessa välivaiheessa ajossa oleva koodi ja skeema ovat yhteensopivia ja askel on peruutettavissa. Postgres auttaa tekemällä useimmista skeemamuutoksista transaktionaalisia, niin että epäonnistunut migraatio peruuntuu siististi sen sijaan että jättäisi tietokannan puoliksi muutetuksi. Kaksi operatiivista seikkaa merkitsee serverless-asetelmassa, jossa monet lyhytikäiset funktioinstanssit kukin haluavat yhteyden: yhteyspoolaaja ei ole valinnainen, koska tietokannalla on kova yhteysraja jonka serverless-työläisten laivasto muuten ehdyttää; ja rivitason tietoturva antaa tietokannan itse pakottaa sen kuka saa nähdä mitkäkin rivit, varavarmistus joka ei riipu siitä että sovellus saa jokaisen kyselyn oikein. Sääntö jota pidämme on yksinkertainen ja mainitsemisen arvoinen: agentti saa ehdottaa migraatiota, mutta migraatio on se yksi muutoksen laji jonka ihminen aina lukee täydellä tarkkaavaisuudella, koska se on se yksi laji jota ketju ei voi täysin kumota.

10. Ihmisportti ja kuinka se epäonnistuu

Jokainen tämän ketjun automaattinen portti on olemassa tehdäkseen ihmisportista halvan, ei poistaakseen sitä. Katselmoija pull requestin äärellä tekee sen yhden asian jota mikään portti ei automatisoi: arvioi onko muutos sitä mitä liiketoiminta tosiasiassa halusi ja onko se turvallista julkaista, kysymyksiä joihin tyypit, testit ja esikatselut antavat tietoa mutteivät vastausta. Ketjun koko tarkoitus on toimittaa tuolle katselmoijalle pieni, ajossa oleva, esitarkistettu muutos niin, että arvio on nopea ja hyvin perusteltu. Mutta portilla on sille ominaisia vikatiloja, ja niiden nimeäminen on osa ketjun hyvää käyttöä.

Ensimmäinen on kumileimasimeksi muuttuminen. Kun agentti on yleensä oikeassa, katselmoija oppii hyväksymään nopeasti, ja katselmointi rappeutuu muodollisuudeksi joka ei nappaa mitään. Puolustus on pitää muutokset pieninä, niin että niiden kunnollinen lukeminen pysyy halpana, ja kohdella esikatselua pakollisena, ei valinnaisena: katselmointi joka ei klikannut ajossa olevaa muutosta läpi ei ole katselmointi. Toinen on ylisuuri luottamus, uskomus että koska koodi läpäisi tyyppitarkistimen ja testit, sen täytyy olla oikein; nuo portit nappaavat muodot ja käyttäytymiset mutteivät aikomusta, ja ihminen on ainoa portti aikomukselle. Kolmas on mittakaavaväsymys: agentti voi avata enemmän pull requesteja kuin tiimi voi vakavasti katselmoida, ja jono puoliksi katselmoituja muutoksia on todentamissidonnaisen regiimin paluu. Vastaus ei ole katselmoida nopeammin vaan tuottaa harkitummin, antaa agentin tuottaa vain sen minkä tiimi tosiasiassa voi todentaa, koska todentamaton muutos on rasite volyymistaan riippumatta.

11. Kustannukset ja kompromissit

Ketju on joukko valintoja, ja rehellisyys vaatii toteamaan mitä ne maksavat. Ilmeisin on sidonnaisuus: Next.js ja Vercel tulevat samalta yritykseltä, ja niiden varaan rakentaminen ostaa sujuvan, integroidun polun tietynasteisen lukkiutumisen hintaan — sekä kehykseen joka liikkuu nopeasti ja rikkoo joskus yhteensopivuuden pääversioiden välillä, että isännöintialustaan jonka hinnoittelun ja primitiivit otat omaksesi. Arvioimme vaihtokaupan sen arvoiseksi nopeuden ja esikatselusilmukan laadun vuoksi, mutta se on todellinen riippuvuus, ja tiimin tulisi pitää toimialalogiikkansa ja datansa siirrettävinä niin, että kehys ja isäntä pysyvät korvattavana infrastruktuurina eivätkä tuotteena. Toinen kustannus on se kuri jota portti vaatii: ketju on vain niin turvallinen kuin se katselmointi johon se huipentuu, ja tiimillä joka antaa ihmisportin rappeutua kumileimasimeksi on nopea tapa toimittaa itsevarmoja virheitä, mikä on pahempaa kuin hidas tapa toimittaa harkittuja. Kolmas on agentin pääsy: työkalu joka voi muokata repositoriota ja laukaista julkaisuja on voimakas toimija, ja se on rajattava sellaiseksi — haarasuojauksella, vähimmän oikeuden tunnuksilla, pitämällä salaisuudet pois repositoriosta ja agentin ulottumattomista, sekä katselmoimalla oikeus- ja infrastruktuurimuutokset erityisellä huolella. Neljäs on datan peruuttamattomuus, käsiteltynä yllä: se yksi paikka jossa ketjun turvaverkossa on reikä, ja se paikka johon kannattaa käyttää eniten ihmisen huomiota. Mikään näistä ei ole syy olla ottamatta ketjua käyttöön; kukin on syy ottaa se käyttöön tarkoituksellisesti.

12. Kuinka ajamme Nashua 360 -alustaa sen varassa

Tämän artikkelin ketju ei ole ehdotus jonka olisimme teoretisoineet; se on se jonka varaan rakennamme ja jolla operoimme omaa tuotettamme. Nashua 360 Enterprise Platform on Next.js-sovellus, julkaistuna Verceliin, Postgresin tukemana, lähdekoodi GitHubissa, ja sitä kehitetään Claude Code agenttina, mukaan lukien mobiilisovelluksesta kun muutos on parempi aloittaa tai hyväksyä poissa työpöydän äärestä. Versionhallintaan tallennettu sääntötiedosto kertoo agentille talon säännöt; jokainen muutos alustaan on haara ja pull request; jokainen pull request saa tyyppitarkistuksensa, jatkuvan integraation ajonsa ja esikatselujulkaisunsa pinon eristetyssä kopiossa; mikään ei saavuta tuotantohaaraa ilman että ihminen lukee diffin ja klikkaa esikatselun läpi; ja migraatiot ovat ne muutokset jotka luemme tarkimmin. Emme koonneet tätä ketjua ollaksemme muodikkaita. Kokosimme sen siksi, että kun kerran hyväksyimme että agentti oli tehnyt tuottamisesta halpaa ja todentamisesta rajoitteen, jokainen linkki seurasi kysymyksestä kuinka todentaa nopeasti ja turvallisesti, ja siksi että sama päättely joka tekee siitä oikean meille — konventionaaliset työkalut joita agentti käsittelee hyvin, kiedottuina silmukoihin ja portteihin jotka nappaavat sen virheet — tekee siitä oikean useimmille tiimeille jotka rakentavat verkko-ohjelmistoja tänään. Se, että se myös antaa viedä vakavaa tuotetta eteenpäin puhelimesta junassa, ei ole syy miksi valitsimme sen, mutta se on oikeudenmukainen merkki siitä kuinka pitkälle työn muoto on muuttunut.

13. Vastaväitteet ja vastaukset

Tämä on vain jatkuvaa toimitusta johon on pultattu agentti. Suurelta osin, tarkoituksella. Käytännöt joiden varaan ketju lepää — versionhallinta, pienet katselmoidut muutokset, jatkuva integraatio, automaattinen julkaisu esikatseluineen ja paluineen — ovat modernin ohjelmistotoimituksen vakiintunut kuri (Humble & Farley, 2010; Forsgren et al., 2018), ja juuri se on pointti: agentti ei korvaa tuota kuria, se nostaa sen arvoa, koska juuri se kuri tuottaa sen todentamisen jota agentin nopeus nyt vaatii. Kontribuutio ei ole uusi käytäntö vaan argumentti sille miksi vanhat käytännöt merkitsevät enemmän, eivät vähemmän, kun tuottaminen kerran on halpaa.

Parempi malli tekee työkaluista tarpeettomia. Ei tee, koska työkalut käsittelevät sitä osaa jota parempi malli ei kosketa. Kyvykkäämpi agentti tuottaa nopeammin ja, todentamissidonnaisessa maailmassa, nopeammin tuottaminen ei nosta sitä mitä tosiasiassa toimitetaan; vain nopeammin todentaminen nostaa. Parempi malli myös tuottaa enemmän koodia, nopeammin, ihmisen tarkistettavaksi, mikä tekee porteista tarpeellisempia, ei vähemmän tarpeellisia. Ketju on veto todentamiseen, ja tuo veto paranee, ei huonone, tuottamisen parantuessa.

Olet lukittuna yhden toimittajan pinoon. Osittain, ja sanoimme niin. Next.js:n ja Vercelin sidonnaisuus on todellinen kustannus joka hyväksytään todellisesta hyödystä, integroidusta esikatselusilmukasta joka on keskeinen koko argumentille. Lievennys on pitää olennainen logiikka — toimialakoodi ja tietokanta — siirrettävänä, ja kohdella kehystä ja isäntää korvattavana infrastruktuurina. Tiimi jolla on erilainen riskinsietokyky voi pitää ketjun muodon — agentti, versionhallinta, eristetty esikatselu, tyypitetty kehys, katselmoitu tietokanta — muiden komponenttien päällä.

14. Rajoitukset

Tämä on käytännön toimijoille suunnattua neuvontaa, ja sen rajat tulisi todeta. Se on perusteltu suositus joka pohjautuu omaan käyttöömme, ei kontrolloitu vertailu; emme ole mitanneet ketjua vaihtoehtoja vasten. Nimenomaiset työkalut ovat ajantasaisia loppuvuodesta 2026, ja tämä on nopeasti liikkuva ala: argumentti — että todentaminen on rajoite ja että ketju tulisi lukea silmukoina ja portteina — on tarkoitettu kestämään minkä tahansa yksittäisen työkalun yli, mutta yksittäiset työkalut muuttuvat, ja lukijan tulisi pitää argumentti ja tarkastella osat uudelleen. Suositus on rajattu siihen ohjelmistolajiin jota me rakennamme, verkkosovelluksiin joissa on tietokanta, ja se kantaa vähemmän suoraan toimialoille joilla on erilaiset rajoitteet, kuten järjestelmiin joissa todentamisportin kustannus on itsessään kohtuuton, tai joissa mikään agentti ei ole nähnyt pinoa tarpeeksi ollakseen siinä luotettava. Ja ketjun turvallisuus lepää ihmisportin varassa, jonka ketju tekee halvaksi muttei voi tehdä automaattiseksi; tiimin joka ei ole halukas pitämään tuota porttia rehellisenä tulisi odottaa nopeutta ilman turvallisuutta.

15. Johtopäätös

Koodausagentti tekee ohjelmistojen kirjoittamisesta nopeaa, ja tehdessään niin siirtää vaikean osan näkyviin. Tuottaminen, se osa joka ennen hallitsi päivää, muuttuu halvaksi; todentaminen — sen päättäminen mitä rakennetaan ja sen varmistaminen että tulos on oikein — ei muutu, ja siitä tulee rajoite. Oppi työkaluille on se, että tekoälyavusteisen kokoonpanon arvo ei ole agentissa vaan sitä ympäröivässä ketjussa, joka antaa tiimin todentaa sillä nopeudella jolla agentti tuottaa ja nappaa sen virheet ennen kuin käyttäjät tekevät. Rakennamme ja ajamme Nashua 360 -alustaa tällaisen ketjun varassa: Claude Code kirjoittamaan, silmukassa tarkistusten kanssa ja tavoitettavana puhelimesta; GitHub tekemään jokaisesta muutoksesta katselmoitu, peruutettava diff suojatun haaran takana; Vercel antamaan jokaiselle muutokselle oman ajossa olevan esikatselunsa ja jokaiselle julkaisulle välittömän paluun; Next.js tyypitettynä, konventionaalisena maastona jonka tyypit ovat ensimmäinen portti; ja Postgres kestävänä tilana jota muutetaan katselmoitujen, peruutettavien migraatioiden kautta. Kukin linkki sulkee silmukan tai lisää portin, portit ovat riippumattomia niin ettei yhdenkään niistä tarvitse olla täydellinen, ja kokonaisuus on valittu tälle hetkelle ominaisella kriteerillä: että agentille konventionaalinen työkalu on se kyvykäs. Kirjoita nopeasti, todenna nopeammin, äläkä päästä mitään tuotantoon mitä ihminen ei ole nähnyt ajossa. Siinä se kaikki, ja se riittää.

Liite A. Käyttöönoton tarkistuslista

Alla olevat käytännöt ovat se mikä tekee ketjusta turvallisen eikä vain nopean. Mikään ei ole uutta; kuri on se arvo.

Lähteet

Ambler, S. W., & Sadalage, P. J. (2006). Refactoring databases: Evolutionary database design. Addison-Wesley. ISBN 978-0-321-29353-5.

Bacchelli, A., & Bird, C. (2013). Expectations, outcomes, and challenges of modern code review. In Proceedings of the 35th International Conference on Software Engineering (ICSE) (pp. 712–721). IEEE. https://doi.org/10.1109/ICSE.2013.6606617

Beck, K. (2000). Extreme programming explained: Embrace change. Addison-Wesley. ISBN 978-0-201-61641-5.

Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532

Chen, M., Tworek, J., Jun, H., et al. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374. https://arxiv.org/abs/2107.03374

Anthropic (2026). Claude Code documentation. https://code.claude.com/docs

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps: Building and scaling high performing technology organizations. IT Revolution Press. ISBN 978-1-942788-33-1.

Fowler, M. (2006). Continuous integration. martinfowler.com. https://martinfowler.com/articles/continuousIntegration.html

GitHub (2026). GitHub documentation. https://docs.github.com

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley. ISBN 978-0-321-60191-9.

Vercel (2026). Next.js documentation. https://nextjs.org/docs

Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590. https://arxiv.org/abs/2302.06590

PostgreSQL Global Development Group (2026). PostgreSQL documentation. https://www.postgresql.org/docs/

Reason, J. (2000). Human error: Models and management. BMJ, 320(7237), 768–770. https://doi.org/10.1136/bmj.320.7237.768

Sadowski, C., Söderberg, E., Church, L., Sipko, M., & Bacchelli, A. (2018). Modern code review: A case study at Google. In Proceedings of the 40th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) (pp. 181–190). ACM. https://doi.org/10.1145/3183519.3183525

Vercel (2026). Vercel documentation. https://vercel.com/docs