Je architect verstuurt de authenticatiemodule dinsdag om 23:00. Geen pull requests die op beoordeling wachten. Geen standup de volgende ochtend om merge conflicts uit te leggen. Slechts één senior engineer en Claude Code, sneller bewegend dan je vorige team van vier personen ooit deed. Vijf maanden geleden zeiden investeerders dat dit logistiek platform 18 maanden en een half miljoen in salarissen zou kosten. Vorige week waardeerden ze het op $2 miljoen. Het gehele engineeringteam? Één persoon die het domein begreep, gekoppeld aan een AI die productie-code bij de eerste poging vaker correct schreef dan zou moeten. Geen offshore-ontwikkelaars. Geen aannemersfacturen. Geen Jira-tickets die stof verzamelen. Maar drie foutmodi hadden het project bijna vermoord — en de derde kostte ons twee weken die we nooit terug krijgen.

Ik schrijf dit niet om AI te hypen. Ik ben door de hype-cyclus al vaak genoeg gebrand. Ik schrijf dit omdat wat op dit project gebeurde, fundamenteel veranderde hoe ik denk over teamsamenstelling, projectschatting en wat werkelijk mogelijk is wanneer je diepgaande architectuurkennis koppelt met AI-ondersteunde ontwikkeling. De cijfers liegen niet — we haalden mijlpalen die een traditioneel team van 6-8 engineers ongeveer 18 maanden zou hebben gekost, en we deden het in onder 5 maanden.

Laat me je exact door de gang van zaken lopen.

Inhoudsopgave

Het project: wat we werkelijk bouwden

Ik kan de cliënt niet noemen — NDA-territorium — maar ik kan het platform beschrijven. Het is een B2B SaaS-product in de logistieke sector. Multi-tenant architectuur. Real-time tracking dashboards. Complexe op rollen gebaseerde toegangscontrole die zich uitstrekt over organisaties, teams en individuele gebruikers. Integratie met 14 verschillende externe API's (vervoerders, betalingsverwerkers, douanedatabases). Een klantgericht portaal en een intern admin-systeem.

Het soort project waarin je in een typische agencyopstelling zou uitbreiden met een tech lead, 2-3 senior devs, een paar mid-levels, een dedicated DevOps-persoon en misschien een QA-engineer. De oorspronkelijke schatting van de cliënt van een ander bureau was $3,2M over 20 maanden met een team van 9.

Wij stelden $2M, 5 maanden, één architect voor. Ze dachten dat we gek waren. Eerlijk gezegd? Ik ook, een beetje.

Waarom één architect in plaats van een volledig team

Hier is het contra-intuïtieve ding over kleine teams: de communicatieoverhead op een project met 9 personen is enorm. Fred Brooks schreef hierover in 1975 en het is nog steeds waar. Met 9 engineers heb je 36 mogelijke communicatiekanalen. Vergaderingen vermenigvuldigen zich. Merge conflicts worden een dagelijkse routine. Iemand wacht altijd op iemands PR-review.

Met één architect leeft de gehele systeemtoestand in het hoofd van één persoon. Er is geen context-switching belasting door je aanpak uit te leggen in een pull request. Geen ontwerp-bij-commissie. Geen twee uur durende sprint planning sessies.

Maar één persoon kan slechts zo snel typen. Één persoon kan slechts zoveel bestanden in werkgeheugen houden. Één persoon wordt moe om 18:00 uur en maakt fouten om 20:00 uur.

Daar komt Claude Code om de hoek. Niet als vervanging voor de architect, maar als een vermenigvuldiger van kracht. De architect maakt elke beslissing. Claude Code voert uit met een snelheid die anderszins 4-5 developers zou vereisen.

De rol van de architect

Onze architect — laten we hem Marcus noemen — heeft 15 jaar ervaring. Hij heeft eerder systemen op deze schaal gebouwd. Zijn taak op dit project was:

  • Systeemontwerp en architectuurbeslissingen
  • Het definiëren van modulegrenzen en datacontracten
  • Het schrijven van kritieke-padcode (auth, betalingsverwerking, data pipeline-orchestratie)
  • Het beoordelen en verfijnen van alles wat Claude Code produceerde
  • Infrastructuur- en inzetarchitectuur
  • Beveiligingsaudits

Wat hij niet deed: boilerplate CRUD-eindpunten schrijven, UI-componenten uit ontwerpen bouwen, unit tests voor straightforward logica schrijven, databasemigraties maken of nieuwe services scaffolden. Claude Code handelde dat allemaal af.

Hoe Claude Code werkelijk in een echte workflow past

Laat me specifiek zijn over wat "Claude Code gebruiken" eigenlijk betekende dag in dag uit, omdat de marketingmaterialen de werkelijkheid niet vastleggen.

Marcus zou elke ochtend beginnen door het werk voor de dag op een gestructureerde manier te definiëren. Geen vage prompts zoals "bouw me een user management systeem." In plaats daarvan zou hij maken wat we "architectuurmemo's" begonnen te noemen — gedetailleerde documenten die aangaven:

  1. De verantwoordelijkheid en grenzen van de module
  2. Datamodellen met exacte veldtypen en relaties
  3. API-contract (eindpunten, request/response-vormen)
  4. Bedrijfsregels en randgevallen
  5. Foutafhandelingsverwachtingen
  6. Welke bestaande modules het mee moest integreren

Daarna voerde hij deze in brokken door aan Claude Code. Een typische sessie zag er zo uit:

# Marcus zou werken in de projectmap met Claude Code CLI
# Eerst, context tot stand brengen
claude "Read through /src/modules/shipment/ and /src/lib/database/schema.ts. 
I need you to understand the existing patterns before we build the 
invoicing module."

# Dan, de werkelijke bouwinstructie met het architectuurmemo
claude "Build the invoicing module following the architecture brief in 
/docs/briefs/invoicing.md. Follow the exact same patterns as the 
shipment module for service layer, repository layer, and route handlers. 
Use the existing error handling middleware. Write tests for all 
business logic in the service layer."

Claude Code zou dan de module genereren — meestal 15-30 bestanden inclusief types, schemas, services, repositories, route handlers, middleware en tests. Marcus zou de output beoordelen, correcties maken en itereren. De hele cyclus voor een middelcomplex module duurde ongeveer 2-3 uur in plaats van de 2-3 dagen die het een senior developer zou kosten.

De iteratielus

Hier is wat niemand je vertelt over AI-ondersteunde ontwikkeling: de eerste output is zelden production-ready. Het is misschien 70-80% daar. Maar die resterende 20-30% is waar de expertise van de architect het meest van pas komt.

Marcus ontwikkelde een ritme:

  1. Genereren — Claude Code produceert de initiële implementatie
  2. Beoordelen — Marcus leest elk bestand, markeert problemen
  3. Verfijnen — Specifieke correcties teruggestuurd naar Claude Code
  4. Verharden — Marcus handelt beveiligingskritieke secties handmatig af
  5. Testen — Voer gegenereerde tests uit, voeg edge cases toe die Claude miste

Deze lus ging meestal door 2-3 cycli per module. Tegen maand drie van het project produceerde Claude Code first-pass-code die dichter bij 85-90% production-ready was, omdat de codebase genoeg vastgestelde patronen had om te volgen.

De technische stack en architectuurbeslissingen

We kozen de stack bewust om AI-ondersteunde productiviteit te maximaliseren:

  • Next.js 14 (App Router) — voor het klantportaal en admin dashboard
  • Node.js met Fastify — voor de API-laag (gescheiden van Next.js)
  • PostgreSQL — primaire database
  • Redis — caching, sessiemanagement, real-time pub/sub
  • Drizzle ORM — typeveilige databasetoegang
  • Turborepo — monorepo management
  • Vercel — frontend deployment
  • AWS (ECS Fargate) — API en background workers

We kozen Next.js specifiek omdat de patronen goed vastgesteld zijn en Claude Code diepe trainingsgegevens over App Router-conventies heeft. Dit maakt meer uit dan mensen denken. Als we iets exotisch hadden gekozen zoals een Rust-gebaseerde backend met HTMX, zou de AI output-kwaliteit aanzienlijk zijn gedaald. Je kunt meer leren over hoe we Next.js-ontwikkeling op schaal benaderen.

Drizzle ORM was een bewuste keuze boven Prisma voor dit project. Claude Code genereert betere Drizzle-schema's omdat ze slechts TypeScript zijn — geen aangepaste DSL om verkeerd te doen. Plus, het migratieverhaal is eenvoudiger wanneer je snel veel schemawijzigingen genereert.

// Voorbeeld: Claude Code genereerde dit factuurschema 
// bij eerste poging met minimale correcties nodig
import { pgTable, uuid, varchar, decimal, timestamp, pgEnum } from 'drizzle-orm/pg-core';
import { relations } from 'drizzle-orm';
import { shipments } from './shipments';
import { organizations } from './organizations';

export const invoiceStatusEnum = pgEnum('invoice_status', [
  'draft', 'pending', 'sent', 'paid', 'overdue', 'cancelled', 'refunded'
]);

export const invoices = pgTable('invoices', {
  id: uuid('id').primaryKey().defaultRandom(),
  organizationId: uuid('organization_id').notNull().references(() => organizations.id),
  shipmentId: uuid('shipment_id').references(() => shipments.id),
  invoiceNumber: varchar('invoice_number', { length: 50 }).notNull().unique(),
  status: invoiceStatusEnum('status').notNull().default('draft'),
  subtotal: decimal('subtotal', { precision: 12, scale: 2 }).notNull(),
  taxAmount: decimal('tax_amount', { precision: 12, scale: 2 }).notNull().default('0'),
  totalAmount: decimal('total_amount', { precision: 12, scale: 2 }).notNull(),
  currency: varchar('currency', { length: 3 }).notNull().default('USD'),
  dueDate: timestamp('due_date', { withTimezone: true }).notNull(),
  paidAt: timestamp('paid_at', { withTimezone: true }),
  createdAt: timestamp('created_at', { withTimezone: true }).notNull().defaultNow(),
  updatedAt: timestamp('updated_at', { withTimezone: true }).notNull().defaultNow(),
});

export const invoiceRelations = relations(invoices, ({ one, many }) => ({
  organization: one(organizations, {
    fields: [invoices.organizationId],
    references: [organizations.id],
  }),
  shipment: one(shipments, {
    fields: [invoices.shipmentId],
    references: [shipments.id],
  }),
  lineItems: many(invoiceLineItems),
}));

Wat Claude Code goed deed

Laten we specifiek zijn. Hier is waar Claude Code werkelijk ontwikkeling versnelde:

Boilerplate en CRUD-operaties

Dit is de voor de hand liggende. REST-eindpunten genereren, request validatieschema's (we gebruikten Zod), response serializers, basale servicemethoden — Claude Code sloeg deze in minuten neer. Over het hele project heen, schatten we dat er ongeveer 180 API-eindpunten waren. Misschien 140 daarvan waren standaard CRUD of query-operaties die Claude Code met minimale herzieningsbehoeften genereerde.

Testgeneratie

Claude Code schreef ongeveer 2.400 tests over het hele project. Waren ze allemaal perfect? Nee. Ongeveer 15% had aanzienlijke overhaul nodig. Maar 85% van je test suite gegenereerd en werkend hebben is een enorme tijdsbesparing. Marcus concentreerde zijn testenergie op integratietests en de ingewikkelde edge cases die Claude Code niet kon anticiperen.

UI-componentontwikkeling

Het klantportaal had ongeveer 60 unieke pagina's. Voor elk één zou Marcus de Figma-ontwerpreferentie en het API-contract verstrekken, en Claude Code zou de React-componenten genereren, hooks voor ophalen van gegevens (we gebruikten TanStack Query), formafhandeling met React Hook Form + Zod, en laad-/foutstaten. De output was consistent goed — misschien 75% pixelprecies bij eerste generatie.

Databasemigraties en schema-evolutie

Naarmate vereisten zich ontwikkelden (en dat doen ze altijd), handelde Claude Code schemamigratiesvlot af. Beschrijf de verandering die je nodig hebt, en het genereert het migratiebestand, werkt het schema bij, past betrokken query's aan en stelt de TypeScript-types aan. Wat ooit een 45-minuten voorzichtige refactoringsessie zou zijn geweest, werd een 10-minuten controle-en-goed-keuren cyclus.

Documentatie

Claude Code genereerde API-documentatie, inline codecommentaar, README-bestanden en zelfs runbook-documenten voor operaties. Marcus zou beoordelen en aanpassen, maar de baselineoutput was werkelijk nuttig. We eindigden met betere documentatie dan 90% van de projecten die ik heb gezien, simpelweg omdat de kosten van het genereren ervan zo laag waren.

Waar Claude Code faalde en wat we eraan deden

Dit deel is belangrijker dan de succesgeschiedenissen. Als je van plan bent AI op deze manier te gebruiken, moet je weten waar de muren staan.

Complexe bedrijfslogica met meerdere afhankelijkheden

De verzendingsrouteringsmotor — die vervoerderbeschikbaarheid, kostenoptimalisatie, douanevereisten, leveringsvensters en capaciteitsbeperkingen tegelijk moest overwegen — was voorbij wat Claude Code goed kon afhandelen. Het zou iets genereren dat aannemelijk uitzag maar had subtiele logicafouten die echt geld konden kosten.

Marcus schreef deze module met de hand. Duurde ongeveer twee weken. Dit is precies het soort werk dat rechtvaardigt een senior architect te hebben in plaats van alles via AI proberen door te zetten.

Beveiligingskritieke code

We vertrouwden Claude Code nooit met auth-flows, betalingsverwerking of encryptie zonder regel-voor-regel beoordeling. En terecht — het genereerde soms JWT-validatie die technisch functioneel was maar edge cases miste zoals tokenverloopclock skew, of desinfecteerde inputs niet correct voor databasequery's ondanks gebruik van een ORM.

Als vuistregel: als een bug in deze code geld kan verliezen of gegevens kan blootstellen, schrijft een mens het en beoordeelt een ander mens het.

Architectuurconsistentie op lange termijn

Tegen maand drie was de codebase groot genoeg dat Claude Code soms "vergat" patronen die eerder waren vastgesteld, zelfs met verschafte context. Het zou een ander foutafhandelingsbenadering in één module versus een ander kunnen gebruiken. Marcus moest waakzaam blijven op het opsporen van deze inconsistenties.

We verzwakten dit door een levend "conventies"-document in onderhoud te houden dat in elke Claude Code-sessie was opgenomen. Denk eraan als een stijlgids, maar voor architectuurpatronen.

Prestatie-optimalisatie

Claude Code genereert code die werkt maar genereert niet altijd code die snel is. Databasequery's die N+1-ophaaloperaties doen. React-componenten die onnodig opnieuw renderen. API-eindpunten die meer gegevens laden dan nodig.

Marcus besteedde ongeveer 20% van zijn beoordelingstijd aan prestatie-optimalisatie. Geen dealbreaker, maar iets om voor in te plannen.

De economie: kostenbreakdown en ROI

Hier is het deel waar iedereen voor komt. Reële cijfers.

Kostencategorie Traditioneel team (schatting) AI-versneld (werkelijk)
Engineeringsalarissen (18 mnd / 5 mnd) $1.890.000 $175.000
Claude Code API / abonnement $0 $12.400
Infrastructuur (dev/staging) $48.000 $8.200
Projectmanagement $216.000 $0*
QA / Testen $180.000 $22.000**
Ontwerp (aanbesteed) $120.000 $95.000
DevOps / Infrastructuuropstelling $96.000 $35.000
Totaal $2.550.000 $347.600

Marcus beheerde zelf met Linear voor taaktracking. Geen PM-overhead.

*Aanbestede QA-specialist voor de laatste 6 weken.

De Claude Code-kosten lopen uit op ongeveer $2.500 per maand. Dat is het Max-abonnement ($100/maand voor het abonnement) plus API-kosten voor uitgebreide sessies. Sommige dagen zou Marcus $150-200 in API-oproepen tijdens intensieve generatiesessies verbranden. De meeste dagen was het $40-80.

Het project werd gefactureerd tegen $2M. Onze totale afleveringskosten waren onder $350K. Ik laat je zelf de winstmargeberekening doen.

Snelheidsgedrag

Mijlpaal Traditionele tijdlijn AI-versnelde tijdlijn
Architectuur & ontwerp 6 weken 3 weken
Kernplatform (auth, multi-tenant, basis API) 10 weken 3 weken
Feature-ontwikkeling (alle modules) 32 weken 10 weken
Integraties (14 externe API's) 12 weken 4 weken
Testen & QA 8 weken 3 weken
Inzet & verharding 4 weken 2 weken
Totaal 72 weken 25 weken

Lessen voor teams die AI-versnelde ontwikkeling overwegen

Na dit project heb ik veel nagedacht over wat dit betekent voor hoe we software voortaan bouwen. Hier is wat ik elk team of agency zou zeggen die dit model overweegt.

Je hebt nog steeds een senior architect nodig. Misschien zelfs meer dan ooit.

AI elimineert de behoefte aan expertise niet — het versterkt welke expertise (of gebrek ervan) je meebrengt. Een junior developer die Claude Code gebruikt zal junior-kwaliteit code sneller inzetten. Een senior architect die Claude Code gebruikt zal senior-kwaliteit code inzetten met een snelheid die voorheen onmogelijk was.

Het slechtste mogelijke scenario is een mid-level developer die denkt dat ze senior zijn en AI gebruiken om code te genereren die ze niet goed kunnen evalueren. Zo krijg je een codebase die oppervlakkig goed uitziet maar instort onder belasting.

Conventie boven configuratie, overal

Hoe voorspelbaarder de patronen van je codebase zijn, hoe beter AI presteert. We gebruikten dezelfde bestandsstructuur, naamgeving en codeorganisatie in elke module. Deze consistentie leverde enorme dividenden op toen Claude Code leerde bestaande patronen te matchen.

Als je werkt met een headless CMS-architectuur, zorgen strikte conventies voor inhoudstypen, API-routes en componentstructuren ervoor dat AI-gegenereerde code dramatisch betrouwbaarder is.

Investeer in architectuurmemo's

De kwaliteit van Claude Code's output correleerde rechtstreeks met de kwaliteit van Marcus's architectuurmemo's. Vage instructies produceerden vage code. Gedetailleerde memo's met expliciete datamodellen, bedrijfsregels en integratievereisten produceerden code die dicht bij production-ready was.

We schatten dat Marcus ongeveer 30% van zijn tijd besteedde aan het schrijven van architectuurmemo's en het beoordelen van output, en 70% van de tijd die een traditioneel team op werkelijke implementatie zou hebben doorgebracht, werd afgehandeld door Claude Code.

AI-ondersteunde ontwikkeling verandert prijsmodellen

Als je een agency bent, dit is het ongemakkelijke gesprek. Wanneer één architect kan leveren wat ooit een team van 8 vereiste, hoe prijzie je? We geloven in value-based pricing — de cliënt betaalt voor het resultaat, niet voor de uren. Het platform is $2M waard ongeacht of het 1 persoon of 10 kostte om het te bouwen.

Als je geïnteresseerd bent in hoe dit soort benadering voor je project zou kunnen werken, breekt onze prijspagina af hoe we denken over projectscoping in deze nieuwe werkelijkheid.

Niet elk project past in dit model

Dit werkte omdat:

  • De vereisten goed waren gedefinieerd (logistiek is een volwassen domein)
  • We hadden een werkelijk senior architect beschikbaar
  • De tech stack was mainstream (geweldige AI-trainingsgegevens)
  • De cliënt vertrouwde ons het platform te leveren zonder op de teamgrootte te micromanagen

Projecten met dubbelzinnige vereisten, zware R&D-componenten of gespecialiseerde domeinen (medische apparaten, financiële instrumenten met regelgeving) hebben meer menselijk oordeel nodig en moeten dienovereenkomstig bemand worden.

Voor projecten gebouwd met frameworks zoals Astro waar het ecosysteem nieuwer is en AI-trainingsgegevens dunner zijn, zul je minder versnelling van AI-tools zien vergeleken met React/Next.js-projecten.

Veelgestelde vragen

Hoeveel kost Claude Code werkelijk per maand voor intensief gebruik?

Op dit project bedroegen we gemiddeld $2.500 per maand alles inbegrepen. Het Claude Max-abonnement is $100 per maand (of $200 per maand voor de hogere laag vanaf begin 2026), en API-gebruik voor Claude Code's agentic-sessies telt op afhankelijk van hoeveel code je genereert. Zware dagen bereiken $150-200 in API-kosten. Lichte herzienings- en verfijningsdagen waren $40-80. Anthropic heeft ook het Max-plan op $200/maand geïntroduceerd dat aanzienlijk gebruik bevat dat variabele kosten zou kunnen verminderen.

Kan een junior developer Claude Code op dezelfde manier gebruiken?

Nee, en dit is belangrijk. Claude Code versterkt je bestaande vaardigheidsniveau — het vervangt architectuurkennis niet. Een junior developer die Claude Code gebruikt genereert sneller code, maar ze zullen niet de subtiele bugs, beveiligingskwesties, prestatieproblemen of architectuurinconsistenties opvangen die een senior engineer onmiddellijk ziet. Je hebt iemand nodig die de output kan evalueren, niet zomaar accepteren.

Hoe zit het met codekwaliteit — is AI-gegenereerde code onderhoudbaar?

Het hangt helemaal af van de beperkingen die je eraan stelt. Onze gegenereerde code haalde dezelfde linting-regels, typechecking en code review-normen als door mensen geschreven code. De truc is sterke patronen vroeg in het project tot stand brengen zodat de AI goede voorbeelden kan volgen. We onderhielden een levend "conventies"-document dat in elke Claude Code-sessie werd opgenomen. Zes maanden na inzet heeft het team dat het platform onderhoudt geen ongebruikelijke onderhoudslast gemeld.

Werkt deze benadering voor frontend-zware projecten?

Ja, met voorbehoud. Claude Code is uitstekend in het genereren van React-componenten, formafhandeling, gegevens-ophaalhaaks en state management-code. Het is minder betrouwbaar bij het produceren van pixelperfecte CSS-indelingen uit ontwerpen — je zult meer iteratiecycli voor visuele afwerking nodig hebben. We ontdekten dat het ongeveer 75% nauwkeurig was bij first-pass UI-generatie vergeleken met 85-90% voor backend-code.

Hoe handelen je codebeoordeling af wanneer er slechts één ontwikkelaar is?

Marcus beoordeelde elke regel AI-gegenereerde code zelf. We brachten ook een aanbestede veiligheidsspecialist voor twee gerichte auditsessies tijdens het project (week 12 en week 22). Voor de eindmaak sloot een QA-specialist voor zes weken aan. Het gebrek aan peer code review is een werkelijk risico — we verzwakten het met geautomatiseerde tooling (TypeScript strict mode, ESLint met agressieve regels, Vitest met coverage-drempelwaarden) en externe audits.

Wat gebeurt er wanneer Claude Code buggy code genereert?

Het gebeurt regelmatig. De eerste doorgang is zelden perfect. We bouwden deze verwachting in de workflow — genereren, beoordelen, verfijnen, verharden. De meeste bugs werden opgespoord tijdens Marcus's beoordelingscyclus. De geautomatiseerde testsuite (ook grotendeels AI-gegenereerd maar door mensen beoordeeld) ving regressieproblemen op. Het belangrijkste inzicht is dat debuggen van AI-gegenereerde code sneller is dan het van nul af aan schrijven van juiste code, omdat je begint met iets dat grotendeels correct is.

Is dit alleen haalbaar voor greenfield-projecten, of werkt het met bestaande codebases?

Claude Code werkt eigenlijk goed met bestaande codebases omdat het bestaande patronen kan lezen en begrijpen. Op dit project profiteerden de latere modules van het hebben van eerdere modules als referentie. We hebben sindsdien Claude Code voor feature-toevoegingen op bestaande klantprojecten met goede resultaten gebruikt. Het sleutel is het ervan voorzien van genoeg context over bestaande conventies en patronen. Als je codebase inconsistent of slecht gedocumenteerd is, zullen AI-gegenereerde toevoegingen die inconsistentie erven.

Zou je dit opnieuw doen?

Absoluut. We doen het al. Twee meer projecten draaien momenteel met dit model — één met een enkele architect, een ander met twee engineers voor een complexer systeem. De economie is te overtuigend om te negeren. Maar ik wil duidelijk zijn: dit gaat niet over het vervangen van developers. Het gaat over het veranderen van de verhouding van senior architects tot output. Je hebt nog steeds menselijke expertise nodig. Je hebt gewoon minder van het menselijk typen nodig. Als je een project overweegt en wilt verkennen wat dit model voor je zou kunnen betekenen, neem contact met ons op — we bespreken graag of het een goede match is.