1.3 miljoona riviä, 630 PR:ää viikossa: Näin pidämme vibe-koodatun koodipohjan ylläpidettävänä

Heinäkuussa 2026 Robert C. Martin kirjoitti, ettei hän enää lue koodia, jonka hänen koodausagenttinsa tuottavat.

Tämä lausunto herätti paljon huomiota. Koko kirjoitus on kuitenkin tärkeämpi hänen työskentelytapansa ymmärtämiseksi. Martin ympäröi agentit yksikkötesteillä, Gherkin-hyväksymistesteillä, QA-prosesseilla, mutaatiotestauksella, kattavuustarkistuksilla ja laatumittareilla. Koodi ansaitsee hänen luottamuksensa läpäisemällä tämän järjestelmän.

Hän oli tehnyt saman huomion muutamaa kuukautta aiemmin. Toteutuksen tarkastelun sijaan hän katsoo testikattavuutta, riippuvuusrakennetta, syklomaattista kompleksisuutta, moduulien kokoa ja mutaatiotestauksen tuloksia. Kun ihmiset tulkitsivat tämän tarkoittavan tarkastuksesta luopumista, hän täsmensi: "Tarkastan paljon — en vain koodia."

Hänen kommenttinsa kuvaavat käytännön ongelmaa tekoälypainotteisessa ohjelmistokehityksessä. Koodausagentit voivat tuottaa muutoksia nopeammin kuin ihmiset ehtivät lukea niitä. Kun tekoälyn tuottaman koodin määrä ylittää tiimin tarkastuskapasiteetin, rivikohtainen tarkastus ei voi enää olla ainoa luottamuksen lähde.

Olemme kohdanneet saman ongelman vm0:ssa viimeisen kahdeksan kuukauden ajan. Suurin osa toteutuksesta repositoriossamme on agenttien kirjoittamaa — vibe-koodausta, kuten nykyään sanotaan — ja kuusi insinööriä on vastuussa siitä, mitä koodi tekee tuotannossa.

Tiivistelmä

vm0 on vibe-koodattu koodipohja: agentit kirjoittavat suurimman osan toteutuksesta, ja kuusi insinööriä omistaa sen tuotantokäyttäytymisen. Kahdeksan kuukauden jälkeen repositoriossa on 1,329,170 riviä ja 630 pull requestia yhdellä viikolla. Viisi mekanismia kantaa laatutaakan, jota rivikohtainen tarkastus ei enää yksin kanna.

• Yhtenäiset ympäristöt. Insinöörit ja agentit työskentelevät samassa kehityskontissa, ja jokaisella pull requestilla voi olla oma tietokantahaara. Komento, joka toimi agentilla, toimii myös ihmisellä.
• Suoritettavat rajoitteet. Tiukka TypeScript, noin 135 tyypitettyä API-sopimusmoduulia, Oxlint, ESLint ja arkkitehtuurisäännöt, CI ei hyväksy varoituksia. Sääntö, jonka voi tarkistaa koneellisesti, ei jää tarkastuksen varaan.
• Rajapainotteiset testit. Testaustrofee pyramidin sijaan: integraatiotestit julkisten moduulirajojen kautta, oikea PostgreSQL ja oikeat migraatiot, mokkaukset vain ulkoisissa järjestelmissä. Testikoodi on noin 36 prosenttia repositoriosta.
• Täydelliset palautesilmukat. Agentit käynnistävät sovelluksen ja tietokannan, ajavat migraatiot ja käyttävät oikeaa selainta, sitten raportoivat suorittamansa komennot, testatun polun ja kuvakaappaukset. Mediaani pull request yhdistyy noin 53 minuutissa.
• Jatkuva siivous. Knip poistaa kuolleen koodin deterministisesti, päivittäiset työnkulut siivoavat tekoälyjätteen, jota mikään linteri ei tunnista, ja usein toistuva kaava nostetaan lint-säännöksi tai tyyppijärjestelmään.

Mitä vibe-koodaus ja agenttikoodaus oikeasti tarkoittavat

Vibe-koodaus tarkoittaa, että LLM:lle annetaan kehotteita, ajetaan sen tuottamaa koodia, pyydetään muutoksia eikä kiinnitetä huomiota itse generoituun koodiin. Martin Fowler määrittelee tämän tarkoituksella kapeasti ja korostaa ilmaisua "unohda, että koodi edes on olemassa." Se sopii prototyyppeihin, kertakäyttöohjelmistoihin ja pieniin työkaluihin, joilla on rajalliset seuraukset.

Agenttikoodaus, jonka Fowler kutsuu agenttipohjaiseksi ohjelmoinniksi, on sitä, mitä tiimit tekevät, kun tulosta aiotaan ylläpitää. Agentti lukee repositorion, muokkaa tiedostoja, ajaa testejä ja työskentelee itsenäisesti pitkään, kun taas ihmiset omistavat rakenteen ja käyttäytymisen sekä tarkastavat suorituksen tuottaman näytön: testitulokset, laatumittarit, esikatselut ja tuotantokäyttäytymisen.

Ero ei ole siinä, kuinka paljon koodia malli kirjoittaa, vaan siinä, mihin ihmisen huomio kohdistuu.

	Vibe-koodaus	Agenttikoodaus
Agentin autonomia	Kehote, ajo, uusi kehote	Lukee repositorion, muokkaa, testaa, iteroi
Kuka lukee koodin	Kukaan	Ihmiset lukevat riskialttiit kohdat
Mitä varmennetaan	Näyttääkö tulos oikealta	Tyypit, sopimukset, testit, esikatselut, tuotantosignaalit
Paras käyttökohde	Prototyypit ja kertakäyttötyökalut	Ohjelmisto, jolla on ylläpito-odotuksia
Tyypillinen epäonnistuminen	Koodi, jota kukaan ei ymmärrä	Varmennus liian heikko volyymille

Agentit, jotka muokkaavat repositoriota, ovat osa laajempaa muutosta; tarkastelimme ei-kehittäjäpuolta erikseen.

Kutsumme vm0:aa usein vibe-koodatuksi projektiksi, koska termi on vakiintunut kuvaamaan pääosin tekoälyn kirjoittamaa ohjelmistoa. Fowlerilla se on lähempänä agenttikoodausta. Insinöörimme kirjoittavat vähemmän toteutusta kuin ennen, mutta omistavat edelleen arkkitehtuurin, ylläpitokustannukset ja tuotantokäyttäytymisen.

Kun koodin generointi nopeutui, yhä suurempi osa vastuusta siirtyi kehitysympäristöön, tyyppijärjestelmään, testipakettiin ja automatisoituihin ylläpitotyönkulkuihin.

Kahdeksan kuukauden kasvu vibe-koodatussa koodipohjassa

vm0-repositorio luotiin marraskuussa 2025. Viimeisimmän viikkokohtaisen insinööriskaalaraportin aikaan se oli noin kahdeksan ja puoli kuukautta vanha.

Repositoriossa oli:

Mittari	Määrä
Ei-tyhjät loogiset rivit	1,329,170
Tuotantorivit	850,913
Testirivit	478,257
Lähdetiedostot	5,549
Testitiedostot	1,327
Paketointiyksiköt	44
Commitit päähaarassa	14,005

Nämä luvut ovat viikkoraportista viikolta 20–26, 2026, mitattu suoraan monoreposta. Testikoodi muodosti noin 36 prosenttia mitatusta koodipohjasta. Tämä on osuus koodimäärästä, ei testikattavuus, mutta antaa käsityksen siitä, kuinka paljon toteutusta on kertynyt varmennuksen ympärille.

Kolmen viimeisimmän täyden viikon aikana kuusi insinööriä teki 541, 640 ja 631 committia. Viikolla 20–26 GitHub kirjasi 630 yhdistettyä pull requestia. Kuusi insinööriä kirjoitti niistä 556, julkaisuautomaatiot loput 74.

Mediaaniaika pull requestin avaamisesta yhdistämiseen oli noin 53 minuuttia. 90. prosenttipiste oli noin 7.4 tuntia.

Tällä muutostahdilla ihmistarkastus on edelleen hyödyllistä, mutta ei voi kantaa koko laatuketjua. Tarvitsemme itsenäisiä signaaleja useissa muutoksen elinkaaren vaiheissa.

Nykyinen lähestymistapamme toistaa viittä teemaa: yhtenäiset ympäristöt, suoritettavat rajoitteet, rajapainotteiset testit, täydelliset palautesilmukat ja jatkuva siivous.

Kehitysympäristön yhtenäistäminen dev-konteilla

Monet vaikeasti toistettavat virheet johtuvat tilasta, joka ei näy pull requestissa.

Kehittäjällä voi olla dokumentoimaton ympäristömuuttuja, globaalisti asennettu työkalu, vanha konfiguraatiotiedosto tai kuukausia pyörinyt tietokanta. Ihmiset tottuvat näihin yksityiskohtiin. Agentit eivät yleensä näe niitä.

Lopetimme vähitellen isäntäkoneen pitämisen standardina kehitysympäristönä. Insinöörit ja agentit työskentelevät kehityskontissa. Kehityskuva sisältää projektin työkaluketjun, PostgreSQL:n, pgvectorin, Chromen ja selainautomaatiotyökalut.

CI ajaa versioituja työkalukuvia, jotka rakennetaan samasta monivaiheisesta Dockerfile-perheestä. Kehitys- ja CI-kuvilla on eri tarkoitukset, ja tuotannolla on oma käyttöönottonsa. Tärkeä ominaisuus on konvergenssi: työkalujen versiot, riippuvuudet ja ajo-olettamukset ovat eksplisiittisiä ja versioituja.

Tämä antaa meille selkeän odotuksen. Komennot, joita agentti ajaa, tulee olla toistettavissa insinöörin toimesta samassa kehityskontissa. Tarkistukset, jotka menevät läpi kehityksessä, tulee ajaa lähes identtisessä työkaluketjussa CI:ssä.

Sovellamme samaa ajatusta dataan. Jokaisella pull request -esikatselulla voi olla oma tietokantahaara ja oikeat migraatiot sekä seed-vaiheet. Agentti voi luoda dataa, muuttaa sitä ja toistaa tuhoavia testejä lainaamatta kehittäjän tietokantaa tai perimättä tilaa toisesta pull requestista.

Ympäristömuutokset kulkevat repositorion kautta. Työkalupäivitykset, selainversiot ja tietokantalaajennukset tarkastetaan ja viedään eteenpäin samalla tavalla kuin sovelluskoodi.

Insinööristandardien muuttaminen suoritettaviksi tyypeiksi ja lint-säännöiksi

Kirjalliset standardit auttavat ymmärtämään suunnittelupäätöksiä. Ne eivät kuitenkaan takaa, että jokainen muutos noudattaa niitä, varsinkaan pitkissä agenttisessioissa.

Vakiinnutetut säännöt siirretään tyyppijärjestelmään, linttereihin ja CI:hin aina kun sääntö voidaan ilmaista luotettavasti.

vm0 käyttää tiukkoja TypeScript-asetuksia, mukaan lukien strict ja noUncheckedIndexedAccess. Joissain paketeissa on lisätarkistuksia käyttämättömille arvoille ja implisiittisille palautuksille.

API käyttää skeemapohjaista tyypitettyä REST-sopimuskerrosta, joka on rakennettu tRPC:n tyyppikoneistolla ja Zod-skeemoilla. Drizzle yhdistää tietokantakäytön TypeScript-tyyppeihin. Tämän katsauksen aikaan repositoriossa oli noin 135 sopimusmoduulia.

Nämä valinnat eivät estä vääriä tuoteratkaisuja. Ne kuitenkin paljastavat rajapintojen muutokset varhain. Kun kenttä tai vastaus muuttuu, siihen liittyvät kutsut yleensä epäonnistuvat staattisessa analyysissä. Tuloksena oleva virhe on yleensä riittävän tarkka, jotta agentti voi käyttää sitä seuraavassa iteraatiossa.

Linttaus kattaa toisen sääntöryhmän. Alusta ajaa Oxlintin, tyyppitietoiset tarkistukset ja ESLintin sekä projektikohtaiset arkkitehtuurisäännöt. CI ei hyväksy varoituksia. Varoitukset, jotka voivat jäädä pysyviksi, muuttuvat helposti taustakohinaksi, jonka sekä ihmiset että agentit ohittavat.

Kun ongelma toistuu, pohdimme, mihin tarkistus kuuluu:

1. Voiko tyyppijärjestelmä ilmaista sen?
2. Voiko linteri tai rakennetarkistin havaita sen tarkasti?
3. Vaatiiko se semanttista harkintaa koko repositoriossa?

Ensimmäiset kaksi antavat nopean, deterministisen palautteen jokaisesta muutoksesta. Kolmas ryhmä hoidetaan toistuvilla työnkuluilla, jotka kuvataan myöhemmin tässä artikkelissa.

Virhealttiiden mallien rajaaminen tekoälyn tuottamassa koodissa

Jotkin kieliominaisuudet ovat perusteltuja, mutta esiintyvät usein myös hauraassa agenttikoodissa.

try/catch voi hämärtää virherajaa. Kun agentti kohtaa virheen, catch-lohkon ja varatoiminnon lisääminen on helppo tapa jatkaa nykyistä polkua menettämällä alkuperäinen virhe. Promise .then() ja .catch() yhdistäminen async/await:n kanssa voi hajottaa ohjausvirran useaan tyyliin.

Reactin useEffect aiheuttaa vastaavan ongelman tilanhallinnassa. Sitä käytetään usein tilan kopiointiin, kahden totuuden lähteen synkronointiin tai järjestysriippuvuuden koodaamiseen, jota on vaikea nähdä datamallista.

Ydinsovellusalusta rajoittaa näitä malleja oletuksena. Perusteltu poikkeus voi jäädä, kunhan sen yhteydessä on selkeä selitys.

Ydinsovellusalustan tuotantokoodissa ei tällä hetkellä ole useEffect:tä. Käytämme ccstatea ja muita sivuvaikutuksettomia malleja riippuvuuksien ja sivuvaikutusten mallintamiseen eksplisiittisemmin. Pieni määrä tuotannon useEffect-kutsuja on edelleen muualla monorepossa, lähinnä jaetussa käyttöliittymä- ja työpöytäkoodissa, joten väitteen laajuus on tärkeä.

Nämä säännöt ovat syntyneet toistuvista epäonnistumisista tässä repositoriossa. Kun malli aiheuttaa toistuvasti saman ylläpito-ongelman, siirrämme sen tarkastusohjeesta suoritettavaan rajoitteeseen.

Testaaminen moduulirajoilla: testaustrofee, ei pyramidi

vm0 ei noudata perinteistä testipyramidia. Testausohjeemme kuvaa testaustrofeen: staattinen analyysi pohjalla, integraatiotestit pääkerroksena ja pieni määrä end-to-end-testejä kriittisille käyttäjäpoluille.

Yksikkötestit ovat suhteellisen harvinaisia. Käytämme niitä valikoidusti tietoturvaan, algoritmeihin ja tilakoneisiin. Suurin osa liiketoimintakäyttäytymisestä testataan moduulin julkisen rajan kautta.

API-testit kutsuvat oikeaa sovellusta sopimustensa kautta. Testidata valmistellaan tuotantopäätepisteiden kautta, kun mahdollista, ja väitteet tehdään julkisen käyttäytymisen kautta. Testit välttävät suoraa pääsyä sisäiseen palveluun tai tietokantatauluihin, koska se sitoo ne nykyiseen toteutukseen.

Sisäinen infrastruktuuri pidetään oikeana aina kun kustannus on kohtuullinen:

• PostgreSQL ja pgvector
• tietokantamigraatiot
• tiedostojärjestelmä
• sisäiset palvelut
• mokkaukset ulkoisissa järjestelmissä

Nämä integraatiotestit ovat hitaampia kuin eristetyt yksikkötestit ja vaativat täydellisemmän ympäristön. Ne myös pienentävät kuilua "testi meni läpi" ja "sovellus osaa suorittaa tämän operaation oikealla tietokannalla" välillä.

Rajatestit mahdollistavat suuret sisäiset refaktoroinnit. Agentti voi järjestellä moduuleja uudelleen, jakaa palvelun tai muuttaa tietokantakerrosta, kunhan julkinen käyttäytyminen pysyy suojattuna.

Uncle Bob suosii toista yhdistelmää, jossa painotetaan yksikkötestejä, Gherkiniä ja mutaatiotestausta. Yhteinen periaate on riippumaton varmennus. Prosessi, joka tuotti koodin, ei saa olla ainoa taho, joka väittää sen toimivan.

Koodausagenteille täydellinen palautesilmukka

Varhaiset koodausagenttien ajot päättyivät usein tuttuun raporttiin: koodi muutettiin ja TypeScript meni läpi; käynnistä sovellus ja tarkista sivu.

Tämä jättää puolet kehityssilmukasta insinöörille. Jonkun on silti valmisteltava tietokanta, ajettava palvelut, avattava selain, luotava dataa, havaittava virhe ja kuvattava se agentille.

Agentit hallitsevat nyt kehitysympäristöä riittävästi tehdäkseen enemmän tästä työstä. Ne voivat käynnistää sovelluksen ja tietokannan, ajaa migraatiot, luoda testidataa, vierailla pull request -esikatselussa ja suorittaa oikeita selaininteraktioita.

Selainvarmennus havaitsee ongelmia, joita tyyppitarkistukset ja API-testit eivät kata hyvin: rikkinäinen navigointi, lataustilat jotka eivät koskaan pääty, käyttöoikeusvirheet jotka ilmenevät vain täydellisessä kulussa ja visuaaliset regressiot.

Ajokerran lopuksi agentti raportoi suorittamansa komennot, testatun polun ja havainnot. Käyttöliittymämuutoksissa se voi liittää kuvakaappauksia. Insinööri voi tarkastaa tämän näytön ennen kuin päättää avata esikatselun itse.

Kuvakaappaus ei ole testi eikä todista muiden vikojen puuttumista. Se kuitenkin helpottaa agentin kontekstin palauttamista. Pienessä käyttöliittymämuutoksessa toistettavat vaiheet ja lopullinen kuvakaappaus ovat paljon hyödyllisempiä kuin viesti "muutoksen pitäisi olla korjattu".

Agentin työn laatu riippuu vahvasti siitä palautteesta, jonka se saa ilman ihmistä.

Haarojen pitäminen lyhyinä trunk-pohjaisella kehityksellä

Nopea koodin generointi voi tuottaa suuren määrän haaroja.

Pitkäikäiset ominaisuusharjat keräävät yhdistämiskonflikteja, päällekkäistä työtä ja vanhentunutta kontekstia. Kun pull requestit kasvavat, tarkastus hidastuu ja vaikeutuu. Käytämme trunk-pohjaista kehitystä pitääksemme haarat lyhyinä ja integroimme jatkuvasti main ympärillä.

Päähaaran säännöt vaativat:

• pull requestit muutoksille
• lineaarinen historia ja squash-merge
• yhdistämisjono
• Turbo-, Rust- ja tietoturvatarkistukset
• ei rutiiniohitus vaadituille porteille

Automaatio kulkee samaa polkua. Agentti voi luoda pull requestin, ja jotkin vähäriskiset ylläpitotehtävät voivat mahdollistaa automaattisen yhdistämisen, mutta muutos kulkee silti CI:n ja yhdistämisjonon läpi.

Pull requestien koko ja elinikä selittävät, miten 630 niistä voi yhdistyä viikossa. Pieni muutos sisältää vähemmän kontekstia, on helpompi varmentaa ja todennäköisemmin välttää ristiriidat tuotekehityksen tai muun automaattisen korjauksen kanssa.

Knip roskien kerääjänä: kuolleen koodin poisto

Koodin generointi lisää luonnostaan tiedostoja ja abstraktioita. Poisto vaatii usein erillisen kehotteen.

Refaktoroinnin jälkeen vanhat tiedostot voivat jäädä repositorioon. Ominaisuuden poisto voi jättää jälkeensä exportteja, riippuvuuksia ja sisääntulopisteitä. Nämä artefaktit eivät yleensä riko testejä, mutta vaikeuttavat koodipohjan hahmottamista ajan myötä.

Käytämme Knipiä löytämään käyttämättömät tiedostot, exportit, riippuvuudet ja sisääntulopisteet. TypeScript voi varmistaa, että koodi on validia; Knip kysyy, osallistuuko se enää järjestelmään.

Jäännöksellä on lisäkustannus koodausagenteille. Repositorio on yksi niiden tärkeimmistä kontekstin lähteistä. Vanhentunut apuri tai hylätty toteutus voi näyttää hyväksytyltä mallilta seuraavalle agentille. Tämän kontekstin puhtaanapito on konteksti-insinöörityön arkea: mitä agentti lukee repositoriosta, on yhtä tärkeää kuin sille annettu kehote.

Kuolleen koodin poisto parantaa myös tulevien ajokertojen syötteitä. Knip hoitaa deterministisen osan tästä työstä riittävän nopeasti ollakseen säännöllinen laatutarkistus.

Toistuvat tekoälyjätteen siivoustyönkulut

Knipillä ja ESLintillä on selvät rajat. Monet rappeutumisen muodot vaativat projektikontekstia ja semanttista harkintaa.

Käytämme "tekoälyjätettä" käytännöllisenä nimityksenä tälle jäännökselle: tarpeettomat varatoiminnot, päällekkäiset abstraktiot, testit jotka ohittavat julkisen rajan tai puolustavat mahdottomia tiloja. Yksittäinen tapaus voi näyttää harmittomalta. Yhdessä ne vaikeuttavat repositorion ymmärtämistä ja antavat seuraavalle agentille huonoja esimerkkejä.

Useat toistuvat vm0-työnkulut etsivät näitä malleja aikataulun mukaan.

Päivittäinen tekoälyjätteen siivous etsii uutta jäännöstä ja valitsee pienen joukon varmoja, vähäriskisiä korjauksia. Muut työnkulut tarkastavat API-testit, jotka menevät sisäisiin palveluihin, React- ja ccstate-antimallit sekä teknisen velan, joka voidaan hoitaa turvallisesti.

Jokainen työnkulku pitää muutoksensa kapeina. Se avaa pull requestin ja luottaa normaaleihin tyyppitarkistuksiin, lint-sääntöihin, testeihin ja yhdistämisjonoon. Automaattiseen yhdistämiseen konfiguroitu pull requestkin joutuu läpäisemään samat portit.

Agenttien ajaminen aikataulun mukaan ei ole ilmaista, ja olemme kirjoittaneet erikseen kustannusten hallinnasta. Työnkulut eivät yritä poistaa kaikkea teknistä velkaa kerralla. Pieni päivittäinen erä on helpompi varmentaa ja vähemmän häiritsevä kuin suuri siivous muutaman kuukauden välein.

Kun toistuva työnkulku löytää saman mallin riittävän usein, harkitsemme tarkistuksen siirtämistä ESLintiin, Knipiin tai tyyppijärjestelmään. Semanttinen työnkulku toimii paikkana havainnoida ja hioa sääntöä ennen kuin siitä tehdään halvempi deterministinen tarkistus.

Epävakaiden testien automaattinen korjaus

Toinen työnkulkuryhmä alkaa GitHub Actionsin epäonnistumisista.

Kun testi epäonnistuu päähaarassa tai yhdistämisjonossa, työnkulku lukee lokit, etsii viitteitä epävakaudesta ja tarkistaa uudelleenkäynnistykset, ajoitukset ja ympäristötekijät. Jos todisteet tukevat tiettyä korjausta, se päivittää testin tai toteutuksen, avaa pull requestin ja ajaa koko CI-polun uudelleen.

Uudelleenkäynnistyksellä läpäisy ei tee alkuperäisestä epäonnistumisesta harmitonta. Tiimit, jotka luottavat retry-nappiin, menettävät vähitellen luottamuksen punaisiin buildeihin. Kun näin käy, epäonnistuneet tarkistukset muuttuvat taustakohinaksi.

Automaattinen korjaustyönkulku muuttaa satunnaisen epäonnistumisen jäljitettäväksi koodimuutokseksi. Diagnoosi, korjaus ja varmennus pysyvät näkyvillä pull requestissa. Insinöörit voivat tarkastaa riskialttiimmat muutokset, kun taas kapeat, vahvasti perustellut korjaukset voivat edetä yhdistämisjonossa.

Laatujärjestelmässämme on tällä hetkellä kolme kerrosta:

Vaihe	Mekanismit	Tyypilliset huolet
Kirjoittaessa	TypeScript, sopimukset, Drizzle, ESLint	tyyppivirheet, rajapintamuutokset, tunnetut koodimallit
Ennen yhdistämistä	Knip, integraatiotestit, oikeat tietokannat, esikatselut, yhdistämisjono	kuollut koodi, moduulikäyttäytyminen, täydelliset ajotulokset
Yhdistämisen jälkeen	ajastetut ja tapahtumapohjaiset vm0-työnkulut	tekoälyjäte, semanttiset antimallit, epävakaat testit, arkkitehtuurin rapautuminen

Kerrokset ruokkivat toisiaan. Työnkulkujen löytämistä ongelmista voi tulla staattisia sääntöjä. CI:ssä tai tuotannossa löytyneistä vioista voi tulla testejä ja uusia insinööriohjeita.

Mihin ihmisen huomio kohdistuu tekoälyn tuottaman koodin tarkastuksessa

vm0-insinöörit lukevat edelleen koodia, erityisesti arkkitehtuurimuutoksissa, tietoturvakriittisessä työssä, maksuissa ja tietokantamigraatioissa. Emme ole tehneet "älä koskaan lue koodia" -säännöstä tiimille.

Mikä on muuttunut, on huomion jakautuminen kooditarkastuksessa. Koodin lukeminen on yksi signaali muiden joukossa: sopimukset, testirajat, esikatselukäyttäytyminen, kuvakaappaukset, laatumittarit ja työnkulkujen diagnostiikka.

Useat päätökset vaativat edelleen kokeneen harkintaa:

• onko vaatimus kattava
• missä moduulirajat kulkevat
• mitkä virheet ovat palautettavissa
• kuinka suuri liiketoimintavaikutus viasta voi syntyä
• onko tietoturvamalli sopiva
• mikä uusi vikamalli jää nykyisten sääntöjen ulkopuolelle

Vastaava muutos tapahtui suunnittelupuolella, jossa design-as-code siirsi visuaaliset päätökset samaan repositorioon ja tarkastuspolkuun. Insinöörit ylläpitävät myös agenttien ympäristöä. Kun ongelma toistuu, päätämme lisätäänkö tyyppirajoite, lint-sääntö, testi vai toistuva työnkulku. Kehitysjärjestelmästä on tullut tärkeä insinöörityön artefakti.

Luettava koodi on edelleen tärkeää. Seuraava lukija voi olla insinööri tai toinen agentti. Sotkuinen koodi kuluttaa enemmän kontekstia, laajentaa tulevien muutosten laajuutta ja heikentää varmennuksen luotettavuutta.

Tietoturva ja muutokset, jotka eivät nopeudu

Nopeus ei jakaudu tasaisesti. vm0 pitää lyhyttä listaa muutoksista, jotka etenevät omaa tahtiaan: tietoturvakriittinen työ, maksut, tietokantamigraatiot ja arkkitehtuuripäätökset. Insinööri lukee nämä rivi riviltä, riippumatta siitä, kuka tai mikä ne kirjoitti.

Tekoälyn tuottaman koodin tietoturvariski on kokemuksemme mukaan harvemmin eksoottinen haavoittuvuus, useammin uskottava koodi, jolla ei ole omistajaa. Tärkeimmät kontrollit ovat tavallisia, mutta johdonmukaisesti sovellettuja:

• Yksikkötestejä, joita muuten käytämme säästeliäästi, käytetään tarkoituksella tietoturvakriittiseen logiikkaan, algoritmeihin ja tilakoneisiin.
• Testit mokkaavat vain ulkoisissa järjestelmissä. Sisäinen infrastruktuuri pidetään oikeana, joten sisäisen sopimuksen rikkova muutos epäonnistuu CI:ssä, ei tuotannossa.
• Agentit työskentelevät dev-kontissa pull request -kohtaisella tietokantahaarella, eivät kehittäjän koneella tai jaetussa tietokannassa.
• Yhdistämisjono ja vaaditut tarkistukset eivät salli rutiiniohitusta, mukaan lukien agentin avaama ja automaattiseen yhdistämiseen merkitty pull request.
• try/catch on oletuksena rajoitettu, joten agentin lisäämä varatoiminto ei todennäköisesti peitä virhettä.

Tunnusten käsittely on erillinen suunnitteluongelma, johon on oma ratkaisunsa: kuvasimme välittäjäkaavan, joka pitää tokenit poissa agentin ulottuvilta omassa artikkelissaan.

Mikään näistä ei tee generoituja koodia itsestään turvalliseksi. Se rajaa muutokset, joissa ihmisen päätös on ainoa kontrolli, ja tekee tästä joukosta eksplisiittisen.

Mitä nämä luvut eivät kerro

Viikkoraportti osoittaa repositorion laajuuden ja toimitusnopeuden. Se ei itsessään osoita tuotannon luotettavuutta.

Vaikutuksen arviointi ajonaikaiseen laatuun vaatii saatavuutta, tuotantovirheiden määrää, tapausten määrää, muutosten epäonnistumisprosenttia, palautusten tiheyttä ja keskimääräistä palautumisaikaa. Vihreä CI-ajo kuvaa vain osan toimitusprosessista.

Kokoamme edelleen näitä tulosmittareita. Insinöörikäytännöt selittävät, miten järjestelmä hallitsee riskiä; tuotantodata kertoo, kuinka hyvin hallinta toimii.

UKK

Mitä on vibe-koodaus? Vibe-koodaus tarkoittaa, että LLM:lle annetaan kehotteita, ajetaan sen palauttamaa koodia, pyydetään muutoksia eikä lueta generoituja rivejä. Martin Fowlerin määritelmä on tarkoituksella kapea: kehittäjän on tarkoitus "unohtaa, että koodi edes on olemassa." Se sopii prototyyppeihin, kertakäyttöohjelmistoihin ja työkaluihin, joilla on rajalliset seuraukset.

Mitä on agenttikoodaus? Agenttikoodaus on pidempikestoinen tekoälyavusteisen kehityksen muoto, jossa agentti lukee repositorion, muokkaa tiedostoja, ajaa testejä ja iteroi itsenäisesti pitkään. Ihmiset omistavat edelleen arkkitehtuurin ja käyttäytymisen, ja tarkastavat ajon tuottaman näytön, eivät jokaista riviä.

Mikä ero on vibe-koodauksella ja agenttikoodauksella? Huomio, ei kirjoittajuus. Vibe-koodauksessa koodia ei tarkasteta lainkaan. Agenttikoodauksessa agentti työskentelee itsenäisesti, kun insinöörit tarkastavat sen ympärillä olevan näytön: testitulokset, laatumittarit, esikatselut ja tuotantokäyttäytymisen. vm0 kuvataan yleensä vibe-koodatuksi; Fowlerin termein kyse on agenttikoodauksesta.

Mitä on tekoälyjäte? Tekoälyjäte on tekoälyn tuottaman koodin jättämä jäännös: tarpeettomat varatoiminnot, päällekkäiset abstraktiot, testit jotka ohittavat julkisen rajan, puolustavat haarat mahdottomille tiloille. Yksittäinen tapaus näyttää harmittomalta. Yhdessä ne vaikeuttavat repositorion ymmärtämistä ja antavat seuraavalle agentille huonoja esimerkkejä.

Miten tarkastatte tekoälyn tuottaman koodin 630 pull requestin viikkotahdilla? Ei rivi riviltä. vm0:ssa ihmistarkastus kohdistuu kohtiin, joissa vaaditaan harkintaa: arkkitehtuuri, tietoturvakriittinen työ, maksut, tietokantamigraatiot. Kaiken muun kantavat mekanismit: tiukat tyypit ja sopimukset, integraatiotestit moduulirajoilla, oikeat tietokannat pull request -esikatseluissa, selainvarmennus, Knip ja yhdistämisjono, jota mikään muutos ei rutiininomaisesti ohita.

Mitkä ovat parhaat käytännöt laajamittaisessa vibe-koodauksessa? Viisi on pitänyt pintansa kahdeksan kuukautta vm0:ssa: yhtenäistä kehitysympäristö niin, että agentit ja ihmiset ajavat samoja komentoja; tee standardeista suoritettavia tyypeissä, linttereissä ja CI:ssä dokumenttien sijaan; testaa moduulirajoilla oikeaa infrastruktuuria vasten; anna agenteille täydellinen palautesilmukka mukaan lukien selain; ja siivoa jatkuvasti, ei satunnaisilla suurilla kerroilla.

Mitkä ovat tekoälyn tuottaman koodin tietoturvariskit? Yleisin riski ei ole eksoottinen haavoittuvuus vaan uskottava koodi, jolla ei ole omistajaa. vm0 pitää tietoturvakriittisen työn, maksut ja tietokantamigraatiot ihmistarkastuksessa, käyttää yksikkötestejä tarkoituksella tähän logiikkaan, pitää sisäisen infrastruktuurin oikeana testeissä, rajoittaa malleja kuten try/catch jotka peittävät virheitä, eikä salli rutiiniohitusta vaadituille tarkistuksille.

Luoeko tekoälyn tuottama koodi teknistä velkaa? Se luo tietynlaista: koodia, joka yhä kääntyy ja läpäisee testit, mutta ei enää osallistu järjestelmään, sekä semanttista jäännöstä, jota mikään linteri ei tunnista. Knip poistaa deterministisen osan. Toistuvat työnkulut hoitavat loput pienissä päivittäisissä erissä, ja riittävän usein toistuva malli muuttuu lint-säännöksi tai tyyppirajoitteeksi.

Kuinka suuri osa vm0:n koodipohjasta on tekoälyn kirjoittamaa? Suurin osa toteutuksesta. Kuusi insinööriä kirjoitti 556 630:stä viikolla 20–26, 2026 yhdistetystä pull requestista, julkaisuautomaatiot loput, ja agentit kirjoittivat suurimman osan näiden pull requestien koodista. Insinöörit omistavat arkkitehtuurin, rajoitteet ja tuotantokäyttäytymisen.

Mikä on testaustrofee ja miksi ei testipyramidi? Testaustrofee asettaa staattisen analyysin pohjalle, integraatiotestit pääkerrokseksi ja pienen määrän end-to-end-testejä huipulle. vm0 käyttää sitä, koska moduulin julkisen rajan kautta kirjoitetut testit suojaavat käyttäytymistä, vaikka agentti järjestelisi toteutuksen uudelleen, mitä laaja yksikkötestikerros ei tee.

Miten löydätte kuolleen koodin tekoälyn kirjoittamassa repositoriossa? Koodin generointi lisää tiedostoja ja abstraktioita; poisto vaatii yleensä erillisen kehotteen. vm0 ajaa Knipiä säännöllisesti löytääkseen käyttämättömät tiedostot, exportit, riippuvuudet ja sisääntulopisteet. TypeScript varmistaa, että koodi on validia; Knip kysyy, osallistuuko se enää järjestelmään, mikä on kuolleen koodin kannalta olennaista.

Onko vibe-koodattu koodi turvallista ajaa tuotannossa? Se riippuu siitä, mikä sen varmentaa, ei siitä, kuka sen kirjoitti. Vaaditut signaalit eivät ole muuttuneet: tyypit ja sopimukset, testit julkisten rajojen kautta, oikea infrastruktuuri ja pipeline, jonka on oltava vihreä. Tämän artikkelin luvut kuvaavat repositorion laajuutta ja toimitusnopeutta. Saatavuus, virheprosentit ja muutosten epäonnistumisprosentit ovat tuotantokysymyksen mittareita, ja kokoamme niitä edelleen.

Kahdeksan kuukautta takana

Kahdeksan kuukautta on liian lyhyt aika lopullisen menetelmän julistamiseen. Mallit, agenttityökalut ja repositorio muuttuvat yhä, ja säännöt sekä työnkulut muuttuvat niiden mukana.

Yksi muutos on jo selvä. Kun koodin generointi nopeutui, ympäristö, rajoitteet, testit ja palautesysteemi ottivat suuremman osan laatutaakasta. Insinöörit käyttävät vähemmän aikaa toteutuksen kirjoittamiseen ja enemmän käyttäytymisen määrittelyyn, rajojen suunnitteluun ja varmennuksen parantamiseen.

vm0:n koodipohja kasvaa edelleen. Knip poistaa deterministisen jäännöksen. Staattiset säännöt estävät jo ymmärretyt vikamallit. Integraatiotestit suojaavat moduulikäyttäytymistä. Toistuvat työnkulut hoitavat rappeutumisen, jota emme vielä osaa ilmaista koneellisesti.

Koodi on yhä tärkeää. Tämän artikkelin parhaat käytännöt eivät koske sen kirjoittamisen vähentämistä, vaan sen päättämistä, mitä on oltava totta ennen kuin muutos kuuluu päähaaraan. Käytämme nyt enemmän koneellisesti todennettavaa näyttöä päättääksemme, kuuluuko muutos päähaaraan ja pitäisikö sen toteutuksen jäädä repositorioon.