1. Inleiding

Gedurende het grootste deel van de geschiedenis van software was het schrijven de schaarse hulpbron. Het vakmanschap van een ontwikkelaar werd afgemeten aan het vermogen om een intentie om te zetten in correcte code, en de uren gingen op aan typen, dingen opzoeken, bibliotheken aan elkaar knopen, en het herstellen van de kleine fouten die compileerfouten en falende tests onthulden. Een capabele coding agent neemt het meeste daarvan weg. Geef hem een heldere instructie en toegang tot een codebase en hij produceert in minuten een werkende wijziging, in idiomen die hij een miljoen keer heeft gezien, met de boilerplate al correct. De informele naam voor deze manier van werken, begin 2025 populair geworden, is vibe coding: beschrijven wat je wilt en het model het laten produceren, sturend op resultaten in plaats van op het schrijven van elke regel. Het is werkelijk een sprong vooruit, en het is gemakkelijk het voor het hele verhaal aan te zien.

Het is niet het hele verhaal, want code laten verschijnen was nooit het moeilijke deel van software, alleen het arbeidsintensieve deel. De moeilijke delen zijn beslissen wat te bouwen, en weten dat wat gebouwd is ook echt juist, veilig en geschikt om te draaien is. Die worden niet goedkoper wanneer generatie dat wordt; eerder worden ze moeilijker, want er is nu veel meer code te begrijpen, sneller geproduceerd dan een mens haar schreef, door een auteur die zelfverzekerd is zelfs wanneer hij ongelijk heeft. De beperkende factor van softwareontwikkeling verschuift. Vroeger lag zij bij generatie: hoe snel een team correcte code kon schrijven. Met een agent ligt zij bij verificatie: hoe snel een team er zeker van kan zijn dat de code correct is en haar kan doorlaten.

Dit paper gaat over het gevolg van die verschuiving voor tooling, en het is bewust concreet. Als verificatie de beperkende factor is, dan is het waardevolste wat een AI-ondersteunde opzet kan doen niet sneller genereren, maar een team helpen sneller en veiliger te verifiëren, waarbij de fouten van de agent goedkoop en vroeg worden gevangen. Wij beschrijven de specifieke keten die wij bij Nashua gebruiken om ons eigen product, het Nashua 360 Enterprise Platform, te bouwen en te draaien, Claude Code als de agent, GitHub als de versiebeheerde ruggengraat en reviewpoort, Vercel voor een draaiende preview van elke wijziging, Next.js als het applicatieframework, en Postgres als de database, en wij gaan in op hoe elk onderdeel feitelijk werkt, want in het detail zit de waarde. Elke schakel verdient haar plaats door een lus strakker te trekken of een poort toe te voegen, niet door op zichzelf knap te zijn.

De bijdrage is een betoog en een uitgewerkte aanbeveling, geen benchmark. Paragraaf 2 zet uiteen wat AI veranderde en wat niet, en lokaliseert de beperkende factor. Paragraaf 3 presenteert de keten als een lus (Figuur 1), beargumenteert dat best-of-breed voor agent-ondersteund werk conventioneel betekent, en legt uit waarom onafhankelijke poorten elkaar vermenigvuldigen. Paragrafen 4 tot 9 nemen de vijf onderdelen één voor één en gaan in op hun inwendige werking, inclusief de runtime-architectuur die een deployment feitelijk heeft (Figuur 2) en het deel dat mensen verrast, namelijk dat een wijziging nu vanaf een telefoon gestart en beoordeeld kan worden. Paragrafen 10 tot 12 behandelen de menselijke poort en haar faalmodi, de werkelijke kosten, en hoe de keten in de praktijk draait. De vraag door het hele stuk heen is: zodra een agent de code kan schrijven, wat moet een team eromheen zetten zodat snel schrijven niet betekent dat je het verkeerde uitrolt?

2. Wat AI veranderde, en wat niet

2.1 De verschuiving

De verandering die een agent brengt kun je het best precies formuleren. Het is niet dat de machine het probleem nu begrijpt; het is dat de kosten van het produceren van een plausibele, vaak correcte, implementatie van een goed gespecificeerde wijziging zijn ineengestort. Een ontwikkelaar die een middag aan een feature zou hebben besteed, kan een eerste versie hebben in de tijd die het kost om haar te beschrijven, en kan meerdere versies goedkoop weggooien. De manier van werken verschuift van auteurschap naar regie: intentie formuleren, resultaten lezen, koers corrigeren. Dit is echte hefboomwerking, en een team dat haar weigert wordt voorbijgestreefd.

2.2 Geen wondermiddel

De verandering is ook begrensd, en de grens is oud. Brooks (1987) trok het onderscheid dat hier nog altijd geldt: de accidentele complexiteit van software, het werk dat door onze tools en talen wordt opgelegd in plaats van door het probleem, kan worden aangevallen en verminderd, maar de essentiële complexiteit, het probleem begrijpen en een correcte oplossing specificeren, laat zich niet wegautomatiseren, want zij ís het probleem. Een coding agent is de krachtigste aanval op accidentele complexiteit die tot nu toe gebouwd is: hij absorbeert de syntaxis, de boilerplate, de API-opzoekingen, de idiomen. Aan de essentie doet hij niets. Weten wat de business nodig heeft, het juiste ontwerp kiezen, en vaststellen dat een bepaalde wijziging daadwerkelijk aan de behoefte voldoet zonder iets anders te breken, blijven mensenwerk, en dat is het werk dat altijd al moeilijk was.

2.3 Verificatie wordt de beperkende factor

Zet de twee naast elkaar en de conclusie volgt. Generatie, het accidentele deel, is nu snel en goedkoop. Verificatie, waar de essentie woont, dat deze wijziging correct is, dat zij doet wat gewenst was, dat zij niets heeft gebroken, dat zij veilig is om bloot te stellen, is dat niet. In elke pijplijn wordt de doorvoer bepaald door de traagste stap, en wanneer generatie verificatie voorbijsnelt, wordt verificatie de bindende beperking. Een team dat tien wijzigingen per dag kan genereren maar er twee kan verifiëren zal er twee uitrollen, en zal een achterstand aan ongeverifieerde code opbouwen die een last is, geen bezit. Erger nog, een agent produceert zelfverzekerd, oppervlakkig correct werk, zodat de kosten van onderverificatie, van het mergen van wat juist lijkt en het niet is, precies stijgen naarmate de verleiding daartoe stijgt. De rest van dit paper gaat over het bouwen van een keten wier taak het is het verificatieplafond te verhogen en onderverificatie moeilijk te maken.

3. De keten, en waarom conventioneel wint

3.1 De lus

Een goede AI-ondersteunde opzet is een lus, geen tool. Figuur 1 tekent de lus die wij gebruiken. Een ontwikkelaar formuleert een intentie. Claude Code, de agent, zet haar om in een wijziging op een branch, niet op de live code. De wijziging wordt een GitHub pull request, waar zonder iemands aandacht twee geautomatiseerde poorten draaien: de type checker en de continuous-integration-suite. Vercel bouwt de branch tot een echte, draaiende preview deployment, een volledige kopie van de applicatie met de wijziging live, bereikbaar op zijn eigen URL. Een mens beoordeelt de wijziging, leest de diff en klikt door de preview, op een desktop of, steeds vaker, op een telefoon. Pas dan wordt zij gemerged naar de main branch, die Vercel naar productie deployt, geschraagd door Postgres. De uitkomst voedt de volgende intentie. De pointe van het diagram is dat de agent één vak inneemt; elk ander vak is een lus die zich sluit of een poort die vangt, en daar komen de veiligheid en de snelheid vandaan.

3.2 Best-of-breed betekent conventioneel

De gebruikelijke manier om tools te kiezen is ze te rangschikken op kracht en de meest capabele te kiezen. Voor een agent-ondersteunde keten is het criterium anders, en het is het meest bruikbare idee in dit paper. Een agent schrijft de tools die hij het meest heeft gezien het best. Zijn competentie op een framework of een database is een functie van hoeveel correcte code die dat gereedschap gebruikt in zijn training zat, en die hoeveelheid volgt de populariteit van het gereedschap, zijn documentatie, en de stabiliteit van zijn conventies. Een mainstream, goed gedocumenteerd, conventierijk gereedschap is daarom niet alleen een veilige menselijke keuze; het is de keuze waarop de agent het meest capabel is en het minst geneigd een API te verzinnen die niet bestaat. Het effect stapelt zich op: populaire tools krijgen meer door agents gegenereerde code, die werkt, wat hun populariteit versterkt. Voor AI-ondersteunde ontwikkeling zijn best-of-breed en meest-conventioneel samengevallen, en elk gereedschap in Tabel 1 is met dat in gedachten gekozen. Dit is ook een waarschuwing: het exotische framework dat een menselijke expert briljant zou kunnen hanteren is vaak precies waar een agent het zwakst is, want hij heeft er het minst van gezien.

3.3 Waarom onafhankelijke poorten elkaar versterken

De keten vertrouwt geen enkele controle op zich. Zij verifieert een wijziging via meerdere poorten die naar werkelijk verschillende dingen kijken: de type checker controleert vormen, de continuous-integration-tests controleren gedrag, de preview deployment toont het draaiende resultaat, en de menselijke reviewer beoordeelt intentie. Omdat de poorten grotendeels onafhankelijk zijn, vermenigvuldigen hun missers zich in plaats van op te tellen: een defect bereikt productie alleen als elke poort het niet vangt, zodat vier bescheiden poorten die elk het meeste vangen van wat zij zien slechts een kleine fractie doorlaten van het product van wat zij missen. Dit is het defence-in-depth-principe, in de veiligheidskunde allang bekend als het opeenstapelen van imperfecte barrières (Reason, 2000), en het heeft een scherp praktisch gevolg. Een poort verwijderen of verzwakken, de preview overslaan, een strikt type uitzetten, goedkeuren zonder te lezen, voegt niet een beetje risico toe; het vermenigvuldigt de ontsnappingskans met het omgekeerde van wat die poort placht te vangen. De goedkoopste manier om veilig te blijven is meerdere verschillende, imperfecte poorten eerlijk te houden, wat precies is waarop de keten is ingericht.

4. De agent: hoe Claude Code inpast

Claude Code is de agent: een tool die de codebase leest, bestanden schrijft en bewerkt, commando’s draait, de tests uitvoert, en pull requests opent, werkend vanuit een instructie en zichzelf corrigerend aan de resultaten die hij ziet. Hoe hij gedraaid wordt doet meer ter zake dan de ruwe bekwaamheid van het model, en drie dingen eraan verdienen de aandacht van een praktijkmens.

Het eerste is context. Een agent is slechts zo goed als wat hij over je codebase weet, en het artefact met de grootste hefboomwerking is een ingecheckt conventiesbestand, in ons geval een project-CLAUDE.md, dat de agent de huisregels vertelt: hoe het project is ingedeeld, hoe de type checker en de tests te draaien, wat te deployen en hoe, wat nooit aan te raken. De agent leest het bij elke run, zodat een correctie die eenmaal is opgeschreven niet meer terugkeert. Eromheen ligt een breder oppervlak, herbruikbare skills voor terugkerende taken, hooks die bij tool calls draaien om een regel mechanisch af te dwingen, en MCP-servers die de agent getypeerde toegang tot externe systemen geven, GitHub daaronder, zodat hij pull requests kan openen en bijwerken als eersterangs acties in plaats van via screen-scraping. Context engineering, beslissen wat de agent moet weten en kunnen doen, is het echte werk van er een adopteren, en het is gewone softwarehygiëne: schrijf de conventies op, maak de checks draaibaar, houd het oppervlak klein.

Het tweede is dat de agent in de lus draait in plaats van in isolatie. Van hem wordt verwacht dat hij de type checker en de tests zelf draait, leest wat zij rapporteren, en het oplost, voordat een mens kijkt, zodat de automatische poorten van de keten al groen zijn tegen de tijd dat een pull request wordt geopend. Voor grotere taken kan hij werk uitwaaieren naar subagents die elk hun eigen context dragen en terugrapporteren, wat de hoofddraad gefocust en de context schoon houdt. De discipline is om de snelle, goedkope feedback, types en tests, binnen de eigen lus van de agent te laten gebeuren, en de trage, dure feedback, de mens, voor het eind te bewaren.

Het derde is waar hij draait. Naast de terminal draait Claude Code als een cloud-sessie bereikbaar vanuit een mobiele app, wat de vorm van de werkdag verandert. Een wijziging kan vanaf een telefoon onderweg gestart worden, in de cloud blijven draaien, en haar pull request en preview later vanaf dezelfde telefoon beoordeeld en goedgekeurd worden. Wij zijn hier bewust in, niet omdat mobiel werken een nieuwigheid is maar omdat het de lus verkort: het gat tussen iets opmerken en de wijziging starten, en tussen een wijziging die klaar is en iemand die haar goedkeurt, stort in van uren naar minuten, wat in een door verificatie begrensde wereld precies het gat is dat het sluiten waard is.

5. De ruggengraat: GitHub

GitHub is het deel van de keten dat al het overige veilig maakt, en het is het minst glamoureus. Het bevat de single source of truth, de repository, en het dwingt de regel af waarop het hele betoog rust: de main branch, degene die uitrolt, is beschermd, en kan alleen worden bereikt via een pull request die een mens heeft goedgekeurd en waarvan de verplichte status checks zijn geslaagd. De agent bewerkt nooit rechtstreeks productiecode; hij stelt voor, op een branch, en het voorstel is een diff die een mens kan lezen en een machine kan testen.

De verplichte checks zijn waar de automatische poorten leven. Op elke pull request draait GitHub Actions de suite waarop wij staan voordat er iets merged: de type checker, de linter, de testsuite, en een productiebuild, elk een verplichte status die de merge-knop blokkeert tot zij groen is. Omdat deze door het platform worden afgedwongen in plaats van door iemands discipline, kunnen zij niet in haast worden overgeslagen, en omdat de agent weet dat zij zullen draaien, voldoet hij er eerst aan. De pull request is de eenheid van verandering: klein, op zichzelf staand, individueel beoordeelbaar en individueel terug te draaien, en dat is wat review goedkoop en historie leesbaar houdt. En omdat elke wijziging een commit is met een auteur en een boodschap, is de historie een audittrail en is het ongedaan maken totaal, alles wat de agent deed kan worden gezien, toegeschreven en teruggedraaid. Een coding agent is een snelle, krachtige en feilbare actor, en GitHub is de structuur die het veilig maakt er een los te laten, door te verzekeren dat niets van wat hij doet ongereviewd, ongetest of onomkeerbaar is.

6. De ogen: Vercel

Een diff lezen vertelt je wat er veranderde; het vertelt je niet wat de wijziging doet. Vercel dicht dat gat door elke pull request te bouwen tot een preview deployment: een complete, geïsoleerde, draaiende instantie van de applicatie met de wijziging toegepast, op zijn eigen URL, automatisch aangemaakt en bij elke push bijgewerkt. Dit is de poort die vangt wat types en tests niet vangen, de lay-out die brak, de flow die één stap langer werd, het ding dat technisch correct en in gebruik verkeerd is, en het is grotendeels waarom de keten snel kan bewegen zonder blind te bewegen. Een reviewer, en de agent, klikken door het feitelijke resultaat in plaats van het uit de code te verbeelden.

Wat de preview betrouwbaar maakt is dat zij een echte build van de hele stack is, geen mock (Figuur 2): hetzelfde framework, dezelfde runtime, haar eigen environment variables, en, goed gedaan, haar eigen geïsoleerde of afgetakte database zodat het uitoefenen ervan productiedata niet kan raken. Deployments zijn immutable: elk is een afzonderlijke, adresseerbare build, zodat het promoveren van een beoordeelde preview naar productie een pointerverschuiving is in plaats van een herbouw, en een slechte release een onmiddellijke rollback naar de vorige immutable deployment is in plaats van een paniekerige hotfix. Bij merge naar de main branch bouwt dezelfde machinerie die de preview bouwde de productie, zodat het ding dat beoordeeld werd het ding is dat uitrolt. In het model van deze keten zijn preview deployments een goedkope, automatische verificatiepoort met een hoge vangstratio voor een klasse defecten die geen enkele andere poort ziet.

7. Naadloos via git: waarom de drie samengaan

De reden dat Claude Code, GitHub en Vercel minder als drie tools en meer als één systeem aanvoelen is dat zij één enkele interface delen, en die interface is git. De natuurlijke output van Claude Code is geen deployment; het is een branch en een pull request. De taak van GitHub is die commits op te slaan, de checks te draaien en de review te houden. Vercel houdt de repository in de gaten en maakt van elke branch een preview en van de main branch productie. Geen van hen hoefde over de anderen te worden onderwezen: de agent leert nooit een deployment-API, hij opent een pull request; Vercel leert nooit over de agent, het houdt de repo in de gaten. De naad tussen hen is het git-protocol dat alle drie al spreken, en dat is waarom het toevoegen van een agent aan de keten niets veranderde aan hoe deployment werkte, en waarom het hele pad van een prompt naar productie geen overdrachten kent.

Het gevolg is dat deployment ophoudt een stap te zijn die iemand uitvoert en een gevolg wordt van de git-actie die zij toch al gingen nemen. Een push is een build. Een pull request is een preview-omgeving, vanzelf aangemaakt en afgebroken. Een merge naar de main branch is een productie-deploy. Een revert is een rollback. Niemand draait een release; zij mergen, en de release gebeurt. Er is geen buildserver om op te passen, geen deploy-script dat de agent verkeerd kan doen, geen apart promotiegereedschap, geen venster waarin iemand de code heeft geschreven maar nog niet heeft uitgerold. Voor een door verificatie begrensd team is dit precies de juiste plek om wrijving weg te nemen: de enige bewuste, menselijke handeling die in het pad overblijft is de review, de ene handeling die bewust hoort te zijn, en al het mechanische eromheen wordt afgehandeld door de tools die git in de gaten houden.

Dit is ook waarom de naadloosheid veilig is in plaats van roekeloos, en de twee eigenschappen komen uit hetzelfde feit voort. Omdat deployment op git meerijdt, erft zij de garanties van git: elke productie-deploy is verbonden aan een specifieke beoordeelde commit, met een auteur en een boodschap; elke preview is verbonden aan een branch; en omdat deployments immutable zijn, is terugdraaien slechts productie naar de build van een eerdere commit wijzen. Dezelfde bedrading die een wijziging laat stromen van een op een telefoon getypte prompt naar een live site zonder dat iemand een deploy-console aanraakt, verzekert ook dat niets die live site bereikt behalve via een beoordeelde, toeschrijfbare, terug te draaien commit. De integratie is een match niet omdat de leveranciers haar coördineerden maar omdat alle drie gebouwd zijn om git als de bron van waarheid te behandelen, en toen de agent zich bij die conventie voegde, was de pijplijn die hij nodig had er al.

8. Het terrein: Next.js

De agent moet een codebase navigeren, en het framework van de codebase is het terrein. Next.js is een sterke keuze om twee redenen die beide op verificatie teruggaan. De eerste is dat het TypeScript is, en types zijn de eerste en goedkoopste poort. In strict mode gedraaid wijst de type checker een grote klasse fouten af, een verkeerde vorm, een ontbrekend veld, een waarde die null zou kunnen zijn, op het moment dat de agent het schrijft, precies wanneer een correctie het goedkoopst is, voordat de code draait en lang voordat een mens kijkt. Wij duwen hetzelfde idee naar de randen van het programma, door externe invoer, request bodies, environment variables, databaserijen tegen een schema te valideren zodat ongetypeerde data van buiten getypeerd en gecontroleerd wordt aan de grens in plaats van vertrouwd. Types zijn hier geen bureaucratie; zij zijn de poort die de meest voorkomende fout van de agent, een plausibele vorm die subtiel verkeerd is, verandert in een rode kronkel die hij zelf oplost.

De tweede reden is dat Next.js conventioneel is, en zijn model, hoe rijk ook, is voldoende platgetreden dat de agent het vloeiend schrijft. Het is de moeite waard concreet te zijn over dat model, want daar leeft veel van het engineeringwerk. De App Router rendert standaard op de server: Server Components draaien op de server en versturen hun code nooit naar de browser, wat data-toegang en secrets serverside houdt, terwijl Client Components, expliciet gemarkeerd, de interactiviteit dragen. Mutaties lopen via Server Actions, serverfuncties die een formulier of een knop rechtstreeks kan aanroepen, en Route Handlers leveren het API-oppervlak. Elke route kiest hoe zij rendert, statisch bij build time, incrementeel geregenereerd volgens een schema, of dynamisch per verzoek, en waar zij draait, de lichtgewicht Edge-runtime dicht bij de gebruiker of de vollere Node.js-runtime, met middleware die vóór het verzoek draait om zaken als authenticatie en locale af te handelen. Dit zijn heel wat hendels, maar het zijn publieke, gedocumenteerde, stabiele hendels die de agent op schaal correct heeft zien gebruiken, dus hij grijpt naar de juiste, en het framework is krachtig genoeg om een echt product te bouwen terwijl het het terrein blijft waarop de agent het meest capabel is, wat, volgens het betoog van paragraaf 3, de combinatie is die ertoe doet.

9. De staat: Postgres

Alles hierboven betreft code, die veilig te wijzigen is omdat zij geversioneerd en omkeerbaar is. Data is dat niet: een weggevallen kolom of een slechte migratie kan iets vernietigen dat geen commit kan herstellen. Postgres is de duurzame, transactionele staat onderaan de keten, en de discipline eromheen is bewust strenger dan rond code. PostgreSQL verdient zijn plaats op dezelfde manier als de rest van de keten, het is de conventionele, in de strijd beproefde, voortreffelijk gedocumenteerde keuze, zodat de agent correcte SQL en correcte migraties ertegen schrijft, en een managed instance neemt het operationele gezwoeg weg zonder het model te veranderen.

De zorg gaat naar verandering. Schemawijzigingen zijn migraties: geordende, geversioneerde bestanden die in de repository worden ingecheckt en als elke andere wijziging worden beoordeeld, tegen de preview gedraaid vóór productie, en geschreven om omkeerbaar te zijn. Een live database kan niet worden gewijzigd zoals een verse dat kan, dus een riskante wijziging wordt gemaakt als een reeks veilige, het expand and contract-patroon (Ambler & Sadalage, 2006): voeg de nieuwe kolom of tabel toe en begin ernaar te schrijven, backfill, verplaats de leesoperaties, en pas dan, in een latere deployment, verwijder de oude vorm, zodat bij elke tussenstap de draaiende code en het schema compatibel zijn en de stap omkeerbaar is. Postgres helpt door de meeste schemawijzigingen transactioneel te maken, zodat een gefaalde migratie netjes terugdraait in plaats van de database halfgewijzigd te laten. Twee operationele punten doen ertoe in een serverless omgeving, waar veel kortlevende functie-instanties elk een connectie willen: een connection pooler is niet optioneel, want een database heeft een harde connectielimiet die een vloot serverless workers anders uitput; en row-level security laat de database zelf afdwingen wie welke rijen mag zien, een vangnet dat er niet van afhangt dat de applicatie elke query goed krijgt. De regel die wij aanhouden is eenvoudig en het vermelden waard: de agent mag een migratie voorstellen, maar een migratie is de ene soort wijziging die een mens altijd met volle aandacht leest, want het is de ene soort die de keten niet volledig ongedaan kan maken.

10. De menselijke poort en hoe zij faalt

Elke automatische poort in deze keten bestaat om de menselijke poort goedkoop te maken, niet om haar te verwijderen. De reviewer bij de pull request doet het ene ding dat geen poort automatiseert: beoordelen of de wijziging is wat de business daadwerkelijk wilde en of zij veilig is om bloot te stellen, vragen die types, tests en previews informeren maar niet beantwoorden. Het hele doel van de keten is die reviewer een kleine, draaiende, voorgecontroleerde wijziging te leveren zodat het oordeel snel en goed gefundeerd is. Maar de poort heeft kenmerkende faalmodi, en ze benoemen hoort bij het goed gebruiken van de keten.

De eerste is rubber-stamping. Wanneer de agent meestal gelijk heeft, leert de reviewer snel goed te keuren, en de review verwordt tot een formaliteit die niets vangt. De verdediging is om wijzigingen klein te houden, zodat ze goed lezen goedkoop blijft, en de preview als verplicht te behandelen, niet als optioneel: een review die niet door de draaiende wijziging heeft geklikt is geen review. De tweede is oververtrouwen, de overtuiging dat omdat de code de type checker en de tests doorstond zij wel correct moet zijn; die poorten vangen vormen en gedragingen maar geen intentie, en de mens is de enige poort op intentie. De derde is schaalmoeheid: een agent kan meer pull requests openen dan een team serieus kan beoordelen, en een achterstand aan half-beoordeelde wijzigingen is het door verificatie begrensde regime dat zich opnieuw doet gelden. Het antwoord is niet sneller te beoordelen maar bewuster te genereren, de agent alleen te laten produceren wat het team daadwerkelijk kan verifiëren, want ongeverifieerde verandering is een last ongeacht haar volume.

11. Kosten en afwegingen

De keten is een set keuzes, en eerlijkheid vereist te benoemen wat zij kosten. De meest voor de hand liggende is koppeling: Next.js en Vercel komen van hetzelfde bedrijf, en erop bouwen koopt een soepel, geïntegreerd pad tegen de prijs van een zekere mate van lock-in, zowel aan een framework dat snel beweegt en soms de compatibiliteit tussen majeure versies breekt, als aan een hostingplatform waarvan je de prijsstelling en primitieven overneemt. Wij achten de ruil het waard voor de snelheid en de kwaliteit van de preview-lus, maar het is een echte afhankelijkheid, en een team zou zijn domeinlogica en zijn data portabel moeten houden zodat het framework en de host vervangbare infrastructuur blijven in plaats van het product. De tweede kost is de discipline die de poort vergt: de keten is slechts zo veilig als de review waarin zij culmineert, en een team dat de menselijke poort laat verworden tot rubber-stamping heeft een snelle manier om zelfverzekerde fouten uit te rollen, wat erger is dan een trage manier om weloverwogen fouten uit te rollen. De derde is de toegang van de agent: een tool die de repository kan bewerken en deployments kan aanjagen is een krachtige actor, en moet als zodanig worden afgebakend, met branch protection, met least-privilege-credentials, met secrets gehouden buiten de repository en buiten het bereik van de agent, en met wijzigingen aan permissies en infrastructuur die met bijzondere zorg worden beoordeeld. De vierde is de onomkeerbaarheid van data, hierboven behandeld: de ene plek waar het vangnet van de keten een gat heeft, en de plek om de meeste menselijke aandacht aan te besteden. Geen van deze is een reden om de keten niet te adopteren; elk is een reden om haar bewust te adopteren.

12. Hoe wij het Nashua 360 platform erop draaien

De keten in dit paper is geen voorstel dat wij hebben getheoretiseerd; het is degene waarop wij ons eigen product bouwen en draaien. Het Nashua 360 Enterprise Platform is een Next.js-applicatie, gedeployd op Vercel, geschraagd door Postgres, met zijn broncode op GitHub, en het wordt ontwikkeld met Claude Code als de agent, ook vanuit de mobiele app wanneer een wijziging beter weg van een bureau wordt gestart of goedgekeurd. Een ingecheckt conventiesbestand vertelt de agent de huisregels; elke wijziging aan het platform is een branch en een pull request; elke pull request krijgt haar type check, haar continuous-integration-run, en haar preview deployment op een geïsoleerde kopie van de stack; niets bereikt de productiebranch zonder dat een mens de diff leest en door de preview klikt; en migraties zijn de wijzigingen die wij het hardst lezen. Wij stelden deze keten niet samen om modieus te zijn. Wij stelden haar samen omdat, zodra wij aanvaardden dat een agent generatie goedkoop en verificatie de beperkende factor had gemaakt, elke schakel volgde uit de vraag hoe snel en veilig te verifiëren, en omdat dezelfde redenering die haar juist maakt voor ons, conventionele tools die de agent goed hanteert, verpakt in lussen en poorten die zijn fouten vangen, haar juist maakt voor de meeste teams die vandaag websoftware bouwen. Dat zij ook toelaat dat een serieus product wordt voortgestuwd vanaf een telefoon in een trein is niet de reden dat wij haar kozen, maar het is een eerlijk teken van hoezeer de vorm van het werk is veranderd.

13. Bezwaren en weerleggingen

Dit is gewoon continuous delivery met een agent erop geschroefd. Grotendeels, met opzet. De praktijken waarop de keten rust, versiebeheer, kleine beoordeelde wijzigingen, continuous integration, geautomatiseerde deployment met previews en rollback, zijn de gevestigde discipline van moderne softwarelevering (Humble & Farley, 2010; Forsgren et al., 2018), en dat is nu juist het punt: de agent vervangt die discipline niet, hij verhoogt de premie erop, want het is de discipline die de verificatie levert die de snelheid van de agent nu vereist. De bijdrage is geen nieuwe praktijk maar het betoog voor waarom de oude praktijken méér, niet minder, ertoe doen zodra generatie goedkoop is.

Een beter model zal de tooling overbodig maken. Dat zal het niet, want de tooling adresseert het deel dat een beter model niet raakt. Een capabelere agent genereert sneller en, in een door verificatie begrensde wereld, verhoogt sneller genereren niet wat er daadwerkelijk uitrolt; alleen sneller verifiëren doet dat. Het betere model produceert ook meer code, sneller, voor een mens om te controleren, wat de poorten noodzakelijker maakt, niet minder. De keten is een weddenschap op verificatie, en die weddenschap wordt beter, niet slechter, naarmate generatie verbetert.

Je zit vastgeketend aan de stack van één leverancier. Deels, en dat zeiden wij. De koppeling van Next.js en Vercel is een echte kost die wordt geaccepteerd voor een echt voordeel, de geïntegreerde preview-lus die centraal staat in het hele betoog. De mitigatie is om de essentiële logica, de domeincode en de database, portabel te houden, en het framework en de host als vervangbare infrastructuur te behandelen. Een team met een andere risicobereidheid kan de vorm van de keten, agent, versiebeheer, geïsoleerde preview, getypeerd framework, beoordeelde database, op andere componenten aanhouden.

14. Beperkingen

Dit is advies gericht op de praktijk, en zijn grenzen horen te worden benoemd. Het is een beredeneerde aanbeveling geworteld in ons eigen gebruik, geen gecontroleerde vergelijking; wij hebben de keten niet tegen alternatieven gemeten. De specifieke tools zijn actueel per eind 2026, en dit is een snel bewegend veld: het betoog, dat verificatie de beperkende factor is en dat de keten gelezen moet worden als lussen en poorten, is bedoeld om elk specifiek gereedschap te overleven, maar de specifieke tools zullen veranderen, en een lezer zou het betoog moeten behouden en de onderdelen opnieuw moeten onderzoeken. De aanbeveling is afgebakend tot het soort software dat wij bouwen, webapplicaties met een database, en draagt minder rechtstreeks over naar domeinen met andere beperkingen, zoals systemen waar de kosten van een verificatiepoort zelf prohibitief zijn, of waar geen agent genoeg van de stack heeft gezien om erop vertrouwd te worden. En de veiligheid van de keten rust op een menselijke poort die de keten goedkoop maakt maar niet automatisch kan maken; een team dat niet bereid is die poort eerlijk te houden moet de snelheid verwachten zonder de veiligheid.

15. Conclusie

Een coding agent maakt het schrijven van software snel, en legt daarmee het moeilijke deel in de openheid. Generatie, het deel dat vroeger de dag beheerste, wordt goedkoop; verificatie, beslissen wat te bouwen en zeker zijn dat het resultaat juist is, wordt dat niet, en wordt de beperkende factor. De les voor tooling is dat de waarde van een AI-ondersteunde opzet niet in de agent zit maar in de keten eromheen die een team laat verifiëren op de snelheid waarmee de agent genereert en zijn fouten vangt voordat gebruikers dat doen. Wij bouwen en draaien het Nashua 360 platform op zo’n keten: Claude Code om te schrijven, in een lus met de checks en bereikbaar vanaf een telefoon; GitHub om van elke wijziging een beoordeelde, omkeerbare diff achter een beschermde branch te maken; Vercel om elke wijziging zijn eigen draaiende preview en elke release een onmiddellijke rollback te geven; Next.js als een getypeerd, conventioneel terrein waarvan de types de eerste poort zijn; en Postgres als duurzame staat gewijzigd via beoordeelde, omkeerbare migraties. Elke schakel sluit een lus of voegt een poort toe, de poorten zijn onafhankelijk zodat geen van hen perfect hoeft te zijn, en het geheel is gekozen op een criterium eigen aan dit moment: dat voor een agent het conventionele gereedschap het capabele is. Schrijf snel, verifieer sneller, en laat niets productie bereiken dat een mens niet heeft zien draaien. Dat is het geheel ervan, en het is genoeg.

Bijlage A. Een adoptiechecklist

De onderstaande praktijken zijn wat de keten veilig maken in plaats van louter snel. Geen ervan is nieuw; de discipline is de waarde.

Referenties

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