1. Innledning

Gjennom det meste av programvarens historie var det skrivingen som var den knappe ressursen. En utviklers håndverk ble målt i evnen til å gjøre en intensjon om til korrekt kode, og timene gikk med til å taste, slå opp ting, koble biblioteker sammen, rette de små feilene som kompileringsfeil og feilende tester avslørte. En kompetent kodeagent fjerner det meste av dette. Gi den en klar instruks og tilgang til en kodebase, og den vil produsere en fungerende endring på minutter, i idiomer den har sett en million ganger, med standardkoden allerede korrekt. Det dagligdagse navnet på å arbeide slik, popularisert tidlig i 2025, er vibe coding: å beskrive hva du vil ha og la modellen produsere det, styrt av resultater snarere enn ved å skrive hver linje. Det er genuint et sprang, og det er lett å forveksle det med hele historien.

Det er ikke hele historien, fordi å få kode til å dukke opp aldri var den vanskelige delen av programvare, bare den arbeidskrevende. De vanskelige delene er å bestemme hva som skal bygges, og å vite at det som ble bygd faktisk er riktig, sikkert og egnet til å kjøre. Disse blir ikke billigere når generering blir det; om noe blir de vanskeligere, fordi det nå finnes langt mer kode å forstå, produsert raskere enn et menneske skrev den, av en forfatter som er selvsikker selv når den tar feil. Flaskehalsen i programvareutvikling flytter seg. Den pleide å sitte ved generering, hvor raskt et team kunne skrive korrekt kode. Med en agent sitter den ved verifisering: hvor raskt et team kan være sikker på at koden er riktig og slippe den gjennom.

Denne artikkelen handler om konsekvensen av det skiftet for verktøy, og den er bevisst konkret. Hvis verifisering er begrensningen, er det mest verdifulle et KI-assistert oppsett kan gjøre ikke å generere raskere, det er å hjelpe et team å verifisere raskere og tryggere, og fange agentens feil billig og tidlig. Vi beskriver den spesifikke kjeden vi i Nashua bruker til å bygge og drive vårt eget produkt, Nashua 360 Enterprise Platform, Claude Code som agenten, GitHub som den versjonskontrollerte ryggraden og gjennomgangsporten, Vercel for en kjørende forhåndsvisning av hver endring, Next.js som applikasjonsrammeverket, og Postgres som databasen, og vi går inn i hvordan hver bit faktisk fungerer, fordi det er i detaljen verdien ligger. Hvert ledd gjør seg fortjent til sin plass ved å stramme en sløyfe eller legge til en port, ikke ved å være smart i seg selv.

Bidraget er et argument og en bearbeidet anbefaling, ikke en referansemåling. Avsnitt 2 redegjør for hva KI endret og hva det ikke gjorde, og lokaliserer flaskehalsen. Avsnitt 3 presenterer kjeden som en sløyfe (Figur 1), framfører argumentet for at best-of-breed for agentassistert arbeid betyr konvensjonell, og forklarer hvorfor uavhengige porter forsterker hverandre. Avsnitt 4 til 9 tar de fem bitene etter tur og går inn i deres indre, inkludert kjøretidsarkitekturen en utrulling faktisk har (Figur 2) og den delen som overrasker folk, at en endring nå kan startes og gjennomgås fra en telefon. Avsnitt 10 til 12 behandler den menneskelige porten og dens feilmoduser, de reelle kostnadene, og hvordan kjeden kjører i praksis. Spørsmålet gjennom hele er: når en agent først kan skrive koden, hva bør et team sette rundt den slik at å skrive raskt ikke betyr å sende ut feil?

2. Hva KI endret, og hva det ikke gjorde

2.1 Skiftet

Endringen en agent bringer uttrykkes best presist. Det er ikke at maskinen nå forstår problemet; det er at kostnaden ved å produsere en plausibel, ofte korrekt, implementasjon av en veldefinert endring har kollapset. En utvikler som ville brukt en ettermiddag på en funksjon kan ha en første versjon på den tiden det tar å beskrive den, og kan kaste flere versjoner billig. Arbeidsmåten forskyves fra å forfatte til å dirigere: å uttrykke intensjon, lese resultater, korrigere kursen. Dette er reell innflytelse, og et team som avviser den vil bli forbigått.

2.2 Ingen mirakelkur

Endringen er også begrenset, og grensen er gammel. Brooks (1987) trakk skillet som fortsatt styrer her: den tilfeldige kompleksiteten i programvare, arbeidet pålagt av våre verktøy og språk snarere enn av problemet, kan angripes og reduseres, men den vesentlige kompleksiteten, å forstå problemet og spesifisere en korrekt løsning, kan ikke automatiseres bort, fordi den er problemet. En kodeagent er det kraftigste angrepet på tilfeldig kompleksitet som hittil er bygd: den absorberer syntaksen, standardkoden, API-oppslagene, idiomene. Den gjør ingenting med vesenet. Å vite hva forretningen trenger, å bestemme den riktige utformingen, og å fastslå at en gitt endring faktisk oppfyller behovet uten å ødelegge noe annet, forblir menneskelig arbeid, og det er arbeidet som alltid var vanskelig.

2.3 Verifisering blir begrensningen

Sett de to sammen og konklusjonen følger. Generering, den tilfeldige delen, er nå rask og billig. Verifisering, som er der vesenet bor, at denne endringen er riktig, at den gjør det som var ønsket, at den ikke har ødelagt noe, at den er trygg å eksponere, er det ikke. I enhver pipeline settes gjennomstrømningen av det tregeste trinnet, og når generering akselererer forbi verifisering, blir verifisering den bindende begrensningen. Et team som kan generere ti endringer om dagen men verifisere to vil sende ut to, og vil akkumulere et etterslep av uverifisert kode som er en belastning, ikke et aktivum. Verre, en agent produserer selvsikkert, overfladisk korrekt arbeid, så kostnaden ved å under-verifisere, ved å flette inn det som ser riktig ut og ikke er det, stiger akkurat idet fristelsen til å gjøre det stiger. Resten av denne artikkelen handler om å bygge en kjede hvis jobb er å heve verifiseringstaket og å gjøre underverifisering vanskelig.

3. Kjeden, og hvorfor konvensjonell vinner

3.1 Sløyfen

Et godt KI-assistert oppsett er en sløyfe, ikke et verktøy. Figur 1 tegner den vi bruker. En utvikler uttrykker en intensjon. Claude Code, agenten, gjør den om til en endring på en gren, ikke på den levende koden. Endringen blir en GitHub pull request, der to automatiserte porter kjører uten noens oppmerksomhet: typesjekkeren og suiten for kontinuerlig integrasjon. Vercel bygger grenen til en reell, kjørende forhåndsvisningsutrulling, en fullstendig kopi av applikasjonen med endringen live, tilgjengelig på sin egen URL. Et menneske gjennomgår endringen, leser diffen og klikker seg gjennom forhåndsvisningen, på en stasjonær maskin eller, i økende grad, på en telefon. Først da flettes den inn i main-grenen, som Vercel ruller ut til produksjon, støttet av Postgres. Utfallet mater den neste intensjonen. Poenget med diagrammet er at agenten opptar én boks; hver annen boks er en sløyfe som lukkes eller en port som fanger, og det er der sikkerheten og hastigheten kommer fra.

3.2 Best-of-breed betyr konvensjonell

Den vanlige måten å velge verktøy på er å rangere dem etter kraft og velge det mest kapable. For en agentassistert kjede er kriteriet annerledes, og det er den enkeltstående mest nyttige ideen i denne artikkelen. En agent skriver verktøyene den har sett mest, best. Dens kompetanse på et rammeverk eller en database er en funksjon av hvor mye korrekt kode som brukte det verktøyet som fantes i treningen dens, og den mengden følger verktøyets popularitet, dokumentasjonen og stabiliteten i konvensjonene. Et mainstream, veldokumentert, konvensjonstungt verktøy er derfor ikke bare et trygt menneskelig valg; det er valget agenten er mest kapabel på og minst tilbøyelig til å finne opp et API som ikke finnes. Effekten forsterker seg selv: populære verktøy får mer agentgenerert kode, som virker, som forsterker populariteten deres. For KI-assistert utvikling har best-of-breed og mest-konvensjonell konvergert, og hvert verktøy i Tabell 1 ble valgt med det i tankene. Dette er også en advarsel: det eksotiske rammeverket en menneskelig ekspert kunne håndtert glimrende er ofte nettopp der en agent er svakest, fordi den har sett minst av det.

3.3 Hvorfor uavhengige porter forsterker hverandre

Kjeden stoler ikke på noen enkelt sjekk. Den verifiserer en endring gjennom flere porter som ser på genuint forskjellige ting: typesjekkeren sjekker former, testene for kontinuerlig integrasjon sjekker atferd, forhåndsvisningsutrullingen viser det kjørende resultatet, og den menneskelige gjennomgåeren bedømmer intensjon. Fordi portene i stor grad er uavhengige, multipliseres bommene deres snarere enn å adderes: en defekt når produksjon bare hvis hver port unnlater å fange den, så fire beskjedne porter som hver fanger det meste av det de ser slipper gjennom bare en liten brøkdel av produktet av det de bommer på. Dette er prinsippet om dybdeforsvar, lenge kjent i sikkerhetsteknikk som lagdelingen av ufullkomne barrierer (Reason, 2000), og det har et skarpt praktisk korollar. Å fjerne eller svekke én port, å hoppe over forhåndsvisningen, å slå av en streng type, å godkjenne uten å lese, legger ikke til litt risiko; det multipliserer rømningsraten med den resiproke av det den porten pleide å fange. Den billigste måten å holde seg trygg på er å holde flere forskjellige, ufullkomne porter ærlige, som er nettopp det kjeden er innrettet til å gjøre.

4. Agenten: hvordan Claude Code passer inn

Claude Code er agenten: et verktøy som leser kodebasen, skriver og redigerer filer, kjører kommandoer, utfører testene, og åpner pull requests, og arbeider ut fra en instruks og korrigerer seg selv mot resultatene det ser. Hvordan den kjøres betyr mer enn modellens rå evne, og tre ting ved den fortjener en praktikers oppmerksomhet.

Det første er kontekst. En agent er bare så god som det den vet om kodebasen din, og det enkeltstående artefaktet med høyest innflytelse er en innsjekket konvensjonsfil, i vårt tilfelle en prosjekt-CLAUDE.md, som forteller agenten husreglene: hvordan prosjektet er lagt opp, hvordan man kjører typesjekkeren og testene, hva som skal rulles ut og hvordan, hva man aldri skal røre. Agenten leser den ved hver kjøring, så en korreksjon skrevet ned én gang slutter å gjenta seg. Rundt den sitter en bredere flate, gjenbrukbare skills for repeterte oppgaver, hooks som kjører på verktøykall for å håndheve en regel mekanisk, og MCP-servere som gir agenten typet tilgang til utenforliggende systemer, GitHub blant dem, slik at den kan åpne og oppdatere pull requests som førsteklasses handlinger snarere enn ved skjermskraping. Kontekst-engineering, å bestemme hva agenten bør vite og kunne gjøre, er det virkelige arbeidet med å ta en i bruk, og det er alminnelig programvarehygiene: skriv ned konvensjonene, gjør sjekkene kjørbare, hold flaten liten.

Det andre er at agenten kjører i sløyfen snarere enn isolert. Den forventes å kjøre typesjekkeren og testene selv, lese hva de rapporterer, og rette det, før noe menneske ser på det, slik at kjedens automatiske porter allerede er grønne i det en pull request åpnes. For større oppgaver kan den fordele arbeid ut til subagenter som hver bærer sin egen kontekst og rapporterer tilbake, noe som holder hovedtråden fokusert og konteksten ren. Disiplinen er å la den raske, billige tilbakemeldingen, typer og tester, skje inne i agentens egen sløyfe, og å reservere den trege, kostbare tilbakemeldingen, mennesket, til slutten.

Det tredje er hvor den kjører. Utover terminalen kjører Claude Code som en skyøkt tilgjengelig fra en mobilapp, noe som endrer formen på arbeidsdagen. En endring kan startes fra en telefon på vei et sted, overlates til å kjøre i skyen, og dens pull request og forhåndsvisning gjennomgås og godkjennes fra den samme telefonen senere. Vi er bevisste på dette ikke fordi mobilt arbeid er en nyhet men fordi det forkorter sløyfen: gapet mellom å legge merke til noe og å starte endringen, og mellom at en endring er klar og at noen godkjenner den, kollapser fra timer til minutter, som i en verifiseringsbundet verden er nettopp gapet verdt å lukke.

5. Ryggraden: GitHub

GitHub er den delen av kjeden som gjør alt annet trygt, og den er den minst glamorøse. Den holder den eneste kilden til sannhet, repositoriet, og den håndhever regelen som hele argumentet hviler på: main-grenen, den som sendes ut, er beskyttet, og kan bare nås gjennom en pull request som et menneske har godkjent og hvis påkrevde statussjekker har bestått. Agenten redigerer aldri produksjonskode direkte; den foreslår, på en gren, og forslaget er en diff et menneske kan lese og en maskin kan teste.

De påkrevde sjekkene er der de automatiske portene bor. På hver pull request kjører GitHub Actions suiten vi insisterer på før noe flettes inn: typesjekkeren, linteren, testsuiten, og et produksjonsbygg, hver en påkrevd status som blokkerer innflettingsknappen til den er grønn. Fordi disse håndheves av plattformen snarere enn av noens disiplin, kan de ikke hoppes over i et hastverk, og fordi agenten vet at de vil kjøre, tilfredsstiller den dem først. Pull requesten er endringsenheten: liten, selvstendig, individuelt gjennomgåbar og individuelt reverserbar, som er det som holder gjennomgang billig og historikk lesbar. Og fordi hver endring er en commit med en forfatter og en melding, er historikken et revisjonsspor og angringen er total, alt agenten gjorde kan ses, tilskrives og reverseres. En kodeagent er en rask, kraftig og feilbarlig aktør, og GitHub er strukturen som gjør det trygt å slippe en løs, ved å sikre at ingenting den gjør er ugjennomgått, utestet eller irreversibelt.

6. Øynene: Vercel

Å lese en diff forteller deg hva som endret seg; den forteller deg ikke hva endringen gjør. Vercel lukker det gapet ved å bygge hver pull request til en forhåndsvisningsutrulling: en fullstendig, isolert, kjørende instans av applikasjonen med endringen anvendt, på sin egen URL, opprettet automatisk og oppdatert ved hver push. Dette er porten som fanger det typer og tester ikke gjør, layouten som brakk, flyten som ble ett trinn lengre, tingen som er teknisk korrekt og feil i bruk, og den er det meste av hvorfor kjeden kan bevege seg raskt uten å bevege seg blindt. En gjennomgåer, og agenten, klikker seg gjennom det faktiske resultatet snarere enn å forestille seg det fra koden.

Det som gjør forhåndsvisningen pålitelig er at den er et reelt bygg av hele stakken, ikke en mock (Figur 2): det samme rammeverket, den samme kjøretiden, dens egne miljøvariabler, og, gjort riktig, dens egen isolerte eller forgrenede database slik at det å utøve den ikke kan røre produksjonsdata. Utrullinger er uforanderlige: hver er et distinkt, adresserbart bygg, så å forfremme en gjennomgått forhåndsvisning til produksjon er en pekerforflytning snarere enn et ombygg, og en dårlig utgivelse er en øyeblikkelig tilbakerulling til den forrige uforanderlige utrullingen snarere enn en febrilsk hurtigretting. Ved innfletting til main-grenen bygger det samme maskineriet som bygde forhåndsvisningen produksjon, så det som ble gjennomgått er det som sendes ut. I denne kjedens modell er forhåndsvisningsutrullinger en billig, automatisk verifiseringsport med en høy fangstrate for en klasse defekter ingen annen port ser.

7. Sømløs ved git: hvorfor de tre passer sammen

Grunnen til at Claude Code, GitHub og Vercel føles mindre som tre verktøy og mer som ett system er at de deler ett enkelt grensesnitt, og det grensesnittet er git. Claude Codes naturlige utdata er ikke en utrulling; det er en gren og en pull request. GitHubs jobb er å lagre de commitene, kjøre sjekkene og holde gjennomgangen. Vercel overvåker repositoriet og gjør hver gren til en forhåndsvisning og main-grenen til produksjon. Ingen av dem måtte læres om de andre: agenten lærer aldri et utrullings-API, den åpner en pull request; Vercel lærer aldri om agenten, den overvåker repoet. Sømmen mellom dem er git-protokollen alle tre allerede snakker, som er grunnen til at det å legge en agent til kjeden ikke endret noe om hvordan utrulling fungerte, og hvorfor hele stien fra en ledetekst til produksjon ikke har noen overleveringer i seg.

Konsekvensen er at utrulling slutter å være et trinn noen utfører og blir en konsekvens av git-handlingen de likevel skulle gjøre. En push er et bygg. En pull request er et forhåndsvisningsmiljø, opprettet og revet ned av seg selv. En innfletting til main-grenen er en produksjonsutrulling. En revert er en tilbakerulling. Ingen kjører en utgivelse; de fletter inn, og utgivelsen skjer. Det finnes ingen byggserver å passe på, ikke noe utrullingsskript for agenten å gjøre feil, ikke noe separat forfremmelsesverktøy, ikke noe vindu der noen har skrevet koden men ennå ikke sendt den ut. For et verifiseringsbundet team er dette nettopp det rette stedet å fjerne friksjon: den eneste bevisste, menneskelige handlingen som er igjen i stien er gjennomgangen, som er den ene handlingen som bør være bevisst, og alt mekanisk rundt den håndteres av verktøyene som overvåker git.

Dette er også grunnen til at sømløsheten er trygg snarere enn uvøren, og de to egenskapene kommer fra det samme faktum. Fordi utrulling rir på git, arver den gits garantier: hver produksjonsutrulling er knyttet til en spesifikk gjennomgått commit, med en forfatter og en melding; hver forhåndsvisning er knyttet til en gren; og fordi utrullinger er uforanderlige, er tilbakerulling bare å peke produksjon mot et tidligere commits bygg. Den samme koblingen som lar en endring flyte fra en telefon-tastet ledetekst til et levende nettsted uten at noen rører en utrullingskonsoll sikrer også at ingenting når det levende nettstedet unntatt gjennom en gjennomgått, tilskrivbar, reverserbar commit. Integrasjonen er en match ikke fordi leverandørene koordinerte den men fordi alle tre ble bygd for å behandle git som kilden til sannhet, og da agenten sluttet seg til den konvensjonen var pipelinen den trengte allerede der.

8. Terrenget: Next.js

Agenten må navigere en kodebase, og kodebasens rammeverk er terrenget. Next.js er et sterkt valg av to grunner som begge kommer tilbake til verifisering. Den første er at det er TypeScript, og typer er den første og billigste porten. Kjørt i streng modus avviser typesjekkeren en stor klasse feil, en feil form, et manglende felt, en verdi som kan være null, i det øyeblikket agenten skriver den, som er nettopp når en korreksjon er billigst, før koden kjører og lenge før et menneske ser på den. Vi presser den samme ideen til programmets ytterkanter, og validerer ekstern input, forespørselskropper, miljøvariabler, databaserader, mot et skjema slik at utypede data utenfra blir typet og sjekket ved grensen snarere enn å stoles på. Typer er ikke byråkrati her; de er porten som gjør agentens vanligste feil, en plausibel form som er subtilt feil, om til en rød bølgestrek den retter selv.

Den andre grunnen er at Next.js er konvensjonelt, og modellen dens, om enn rik, er godt opptråkket nok til at agenten skriver den flytende. Det er verdt å være konkret om den modellen, fordi det er der mye av ingeniørarbeidet bor. App Router rendrer på tjeneren som standard: Server Components kjører på tjeneren og sender aldri koden sin til nettleseren, og holder datatilgang og hemmeligheter på tjenersiden, mens Client Components, merket eksplisitt, bærer interaktiviteten. Mutasjoner går gjennom Server Actions, tjenerfunksjoner et skjema eller en knapp kan kalle direkte, og Route Handlers gir API-flaten. Hver rute velger hvordan den rendrer, statisk ved byggetid, inkrementelt regenerert etter en tidsplan, eller dynamisk per forespørsel, og hvor den kjører, den lette Edge-kjøretiden nær brukeren eller den fyldigere Node.js-kjøretiden, med middleware som kjører før forespørselen for å håndtere ting som autentisering og lokalisering. Dette er mange spaker, men de er offentlige, dokumenterte, stabile spaker agenten har sett brukt riktig i stor skala, så den griper etter den rette, og rammeverket er kraftig nok til å bygge et reelt produkt mens det forblir terrenget agenten er mest kapabel på, som, ved argumentet i avsnitt 3, er kombinasjonen som betyr noe.

9. Tilstanden: Postgres

Alt ovenfor gjelder kode, som er trygt å endre fordi den er versjonert og reverserbar. Data er det ikke: en droppet kolonne eller en dårlig migrering kan ødelegge noe ingen commit kan gjenopprette. Postgres er den varige, transaksjonelle tilstanden i bunnen av kjeden, og disiplinen rundt den er bevisst strengere enn rundt kode. PostgreSQL gjør seg fortjent til sin plass på samme måte som resten av kjeden, det er det konvensjonelle, kamptestede, utmerket dokumenterte valget, så agenten skriver korrekt SQL og korrekte migreringer mot det, og en administrert instans fjerner det operasjonelle slitet uten å endre modellen.

Omsorgen går inn i endring. Skjemaendringer er migreringer: ordnede, versjonerte filer sjekket inn i repositoriet og gjennomgått som enhver annen endring, kjørt mot forhåndsvisningen før produksjon, og skrevet for å være reversible. En levende database kan ikke endres slik en fersk kan, så en risikabel endring gjøres som en sekvens av trygge, expand and contract-mønsteret (Ambler & Sadalage, 2006): legg til den nye kolonnen eller tabellen og begynn å skrive til den, fyll på bakover, flytt lesingene over, og først da, i en senere utrulling, fjern den gamle formen, slik at på hvert mellomtrinn er den kjørende koden og skjemaet kompatible og trinnet er reverserbart. Postgres hjelper ved å gjøre de fleste skjemaendringer transaksjonelle, slik at en feilet migrering rulles rent tilbake snarere enn å etterlate databasen halvveis endret. To operasjonelle poenger betyr noe i en serverløs setting, der mange kortlivede funksjonsinstanser hver vil ha en tilkobling: en tilkoblingspool er ikke valgfri, fordi en database har en hard tilkoblingsgrense som en flåte av serverløse arbeidere ellers vil tømme; og radnivåsikkerhet lar databasen selv håndheve hvem som kan se hvilke rader, et sikkerhetsnett som ikke avhenger av at applikasjonen får hver spørring riktig. Regelen vi holder er enkel og verdt å uttrykke: agenten kan foreslå en migrering, men en migrering er den ene typen endring et menneske alltid leser med full oppmerksomhet, fordi det er den ene typen kjeden ikke fullt ut kan angre.

10. Den menneskelige porten og hvordan den svikter

Hver automatisk port i denne kjeden finnes for å gjøre den menneskelige porten billig, ikke for å fjerne den. Gjennomgåeren ved pull requesten gjør den ene tingen ingen port automatiserer: å bedømme om endringen er det forretningen faktisk ville ha og om den er trygg å eksponere, spørsmål som typer, tester og forhåndsvisninger opplyser men ikke besvarer. Kjedens hele formål er å levere den gjennomgåeren en liten, kjørende, forhåndssjekket endring slik at dommen er rask og velbegrunnet. Men porten har karakteristiske feilmoduser, og å navngi dem er en del av å bruke kjeden godt.

Den første er stempling. Når agenten vanligvis har rett, lærer gjennomgåeren å godkjenne raskt, og gjennomgangen degenererer til en formalitet som fanger ingenting. Forsvaret er å holde endringer små, slik at det å lese dem ordentlig forblir billig, og å behandle forhåndsvisningen som obligatorisk, ikke valgfri: en gjennomgang som ikke klikket seg gjennom den kjørende endringen er ikke en gjennomgang. Den andre er overtillit, troen på at fordi koden bestod typesjekkeren og testene må den være riktig; de portene fanger former og atferder men ikke intensjon, og mennesket er den eneste porten på intensjon. Den tredje er skalatretthet: en agent kan åpne flere pull requests enn et team kan gjennomgå seriøst, og et etterslep av halvgjennomgåtte endringer er det verifiseringsbundne regimet som gjør seg gjeldende på nytt. Svaret er ikke å gjennomgå raskere men å generere mer bevisst, å la agenten produsere bare det teamet faktisk kan verifisere, fordi uverifisert endring er en belastning uansett volum.

11. Kostnader og avveininger

Kjeden er et sett valg, og ærlighet krever at man sier hva de koster. Den mest åpenbare er kobling: Next.js og Vercel kommer fra det samme selskapet, og å bygge på dem kjøper en jevn, integrert sti til prisen av en viss grad av innlåsing, både til et rammeverk som beveger seg raskt og noen ganger bryter kompatibilitet mellom hovedversjoner, og til en vertsplattform hvis prising og primitiver du adopterer. Vi dømmer handelen verdt det for hastigheten og kvaliteten på forhåndsvisningssløyfen, men det er en reell avhengighet, og et team bør holde domenelogikken og dataene sine portable slik at rammeverket og verten forblir utskiftbar infrastruktur snarere enn produktet. Den andre kostnaden er disiplinen porten krever: kjeden er bare så trygg som gjennomgangen den kulminerer i, og et team som lar den menneskelige porten forfalle til stempling har en rask måte å sende ut selvsikre feil på, som er verre enn en langsom måte å sende ut gjennomtenkte på. Den tredje er agentens tilgang: et verktøy som kan redigere repositoriet og utløse utrullinger er en kraftig aktør, og den må gis omfang som en, med grenbeskyttelse, med lavest-privilegium-legitimasjon, med hemmeligheter holdt utenfor repositoriet og utenfor agentens rekkevidde, og med tillatelses- og infrastrukturendringer gjennomgått med særlig omhu. Den fjerde er dataenes irreversibilitet, behandlet ovenfor: det ene stedet kjedens sikkerhetsnett har et hull, og stedet å bruke mest menneskelig oppmerksomhet. Ingen av disse er en grunn til å ikke ta kjeden i bruk; hver er en grunn til å ta den i bruk bevisst.

12. Hvordan vi driver Nashua 360-plattformen på den

Kjeden i denne artikkelen er ikke et forslag vi har teoretisert; det er den vi bygger og driver vårt eget produkt på. Nashua 360 Enterprise Platform er en Next.js-applikasjon, utrullet på Vercel, støttet av Postgres, med kildekoden på GitHub, og den utvikles med Claude Code som agenten, inkludert fra mobilappen når en endring er bedre startet eller godkjent borte fra en pult. En innsjekket konvensjonsfil forteller agenten husreglene; hver endring av plattformen er en gren og en pull request; hver pull request får sin typesjekk, sin kjøring av kontinuerlig integrasjon, og sin forhåndsvisningsutrulling på en isolert kopi av stakken; ingenting når produksjonsgrenen uten at et menneske leser diffen og klikker seg gjennom forhåndsvisningen; og migreringer er endringene vi leser hardest. Vi satte ikke sammen denne kjeden for å være moteriktige. Vi satte den sammen fordi, da vi først aksepterte at en agent hadde gjort generering billig og verifisering til begrensningen, fulgte hvert ledd av spørsmålet om hvordan man verifiserer raskt og trygt, og fordi det samme resonnementet som gjør den riktig for oss, konvensjonelle verktøy agenten håndterer godt, pakket inn i sløyfer og porter som fanger feilene dens, gjør den riktig for de fleste team som bygger webprogramvare i dag. At den også lar et seriøst produkt føres fram fra en telefon på et tog er ikke grunnen til at vi valgte den, men det er et rimelig tegn på hvor langt formen på arbeidet har endret seg.

13. Innvendinger og svar

Dette er bare kontinuerlig leveranse med en agent boltet på. I stor grad, bevisst. Praksisene kjeden hviler på, versjonskontroll, små gjennomgåtte endringer, kontinuerlig integrasjon, automatisert utrulling med forhåndsvisninger og tilbakerulling, er den etablerte disiplinen i moderne programvareleveranse (Humble & Farley, 2010; Forsgren et al., 2018), og det er poenget: agenten erstatter ikke den disiplinen, den hever premien på den, fordi det er disiplinen som leverer verifiseringen agentens hastighet nå krever. Bidraget er ikke en ny praksis men argumentet for hvorfor de gamle praksisene betyr mer, ikke mindre, når generering først er billig.

En bedre modell vil gjøre verktøyene unødvendige. Det vil den ikke, fordi verktøyene adresserer den delen en bedre modell ikke berører. En mer kapabel agent genererer raskere og, i en verifiseringsbundet verden, hever det å generere raskere ikke det som faktisk sendes ut; bare det å verifisere raskere gjør det. Den bedre modellen produserer også mer kode, raskere, for et menneske å sjekke, noe som gjør portene mer nødvendige, ikke mindre. Kjeden er et veddemål på verifisering, og det veddemålet blir bedre, ikke verre, etter hvert som generering forbedres.

Dere er låst inn i én leverandørs stakk. Delvis, og vi sa det. Koblingen av Next.js og Vercel er en reell kostnad akseptert for en reell fordel, den integrerte forhåndsvisningssløyfen som er sentral i hele argumentet. Avhjelpningen er å holde den vesentlige logikken, domenekoden og databasen, portabel, og å behandle rammeverket og verten som utskiftbar infrastruktur. Et team med en annen risikoappetitt kan beholde formen på kjeden, agent, versjonskontroll, isolert forhåndsvisning, typet rammeverk, gjennomgått database, på andre komponenter.

14. Begrensninger

Dette er praktikerrettet råd, og dets grenser bør angis. Det er en begrunnet anbefaling forankret i vår egen bruk, ikke en kontrollert sammenligning; vi har ikke målt kjeden mot alternativer. De spesifikke verktøyene er gjeldende per sent 2026, og dette er et felt i rask bevegelse: argumentet, at verifisering er begrensningen og at kjeden bør leses som sløyfer og porter, er ment å overleve ethvert bestemt verktøy, men de bestemte verktøyene vil endre seg, og en leser bør beholde argumentet og undersøke delene på nytt. Anbefalingen er avgrenset til den typen programvare vi bygger, webapplikasjoner med en database, og bæres mindre direkte over til domener med andre begrensninger, som systemer der kostnaden ved en verifiseringsport i seg selv er prohibitiv, eller der ingen agent har sett nok av stakken til å stoles på den. Og kjedens sikkerhet hviler på en menneskelig port som kjeden gjør billig men ikke kan gjøre automatisk; et team som er uvillig til å holde den porten ærlig bør forvente hastigheten uten sikkerheten.

15. Konklusjon

En kodeagent gjør det å skrive programvare raskt, og gjør dermed den vanskelige delen synlig. Generering, delen som pleide å dominere dagen, blir billig; verifisering, å bestemme hva som skal bygges og å være sikker på at resultatet er riktig, blir det ikke, og blir begrensningen. Lærdommen for verktøy er at verdien av et KI-assistert oppsett ikke ligger i agenten men i kjeden rundt den som lar et team verifisere i den hastigheten agenten genererer og fanger feilene dens før brukerne gjør det. Vi bygger og driver Nashua 360-plattformen på en slik kjede: Claude Code til å skrive, i en sløyfe med sjekkene og tilgjengelig fra en telefon; GitHub til å gjøre hver endring til en gjennomgått, reverserbar diff bak en beskyttet gren; Vercel til å gi hver endring sin egen kjørende forhåndsvisning og hver utgivelse en øyeblikkelig tilbakerulling; Next.js som et typet, konvensjonelt terreng hvis typer er den første porten; og Postgres som varig tilstand endret gjennom gjennomgåtte, reversible migreringer. Hvert ledd lukker en sløyfe eller legger til en port, portene er uavhengige slik at ingen av dem må være perfekt, og helheten er valgt på et kriterium som er særegent for dette øyeblikket: at for en agent er det konvensjonelle verktøyet det kapable. Skriv raskt, verifiser raskere, og la ingenting nå produksjon som en person ikke har sett kjøre. Det er hele greia, og det er nok.

Vedlegg A. En adopsjonssjekkliste

Praksisene nedenfor er det som gjør kjeden trygg snarere enn bare rask. Ingen er ny; disiplinen er verdien.

Referanser

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