Kort samengevat. We gebruiken AI om een groot deel van onze code te schrijven, en dat is een bewuste keuze, geen sluiproute. De reden is eenvoudig: een agent is snel in code produceren en slecht in een systeem overzien. Dus laten we hem het typewerk doen en verplaatsen we onze engineers omhoog — naar architectuur, naar flexibiliteit, naar de systeembrede besluiten die bepalen of een codebase over een jaar nog prettig te wijzigen is. De branche haalde dit in 2026 in: 84% van de developers gebruikt AI-tools dagelijks, en het winnende patroon is "genereer stevig, verifieer streng". De adder is dat AI elk bestand lokaal optimaliseert en niemand de codebase in zijn geheel optimaliseert — en precies daarom breken de codebases die we beoordelen allemaal op dezelfde elf manieren. Ons antwoord is een mens houden op het deel dat AI niet kan zien: de architectuur. Zo bouwen wij, en waarom.

Het werk veranderde, en wij veranderden mee

Het grootste deel van de geschiedenis van software was typen het knelpunt. Een helder idee omzetten in werkende code was het trage, dure deel, dus daar ging de engineeringinspanning heen en daaraan werd senioriteit afgemeten.

Dat knelpunt is weg. Zoals de stand van de developerswereld van juni 2026 uiteenzet, zijn AI-programmeertools van curiositeit tot uitgangspunt geworden: 84% van de developers grijpt er dagelijks naar, TypeScript haalde Python in als meestgebruikte taal deels omdat getypeerde code AI eerlijk houdt, en de productiefste engineers schrijven niet méér code met de hand — ze sturen agents aan die dat doen. De "10x-engineer" werd een manager van machines.

We verzetten ons daar niet tegen; we reorganiseerden eromheen. Kan een agent in minuten een werkende functie produceren, dan is de schaarse, waardevolle menselijke vaardigheid niet langer "kun jij deze functie schrijven". Het is "hoort deze functie te bestaan, waar hoort ze thuis, wat gebeurt er als de eisen veranderen, en hoe gedraagt ze zich als tienduizend mensen er tegelijk op drukken". Dat zijn vragen over architectuur en flexibiliteit. Het zijn precies de vragen waar AI het slechtst in is — en de vragen die bepalen of een product leeft of sterft.

Het uitgangspunt van 2026, in vier getallen:

  • 84% gebruikt AI dagelijks. AI-programmeergereedschap is nu het uitgangspunt, geen optionele aanvulling.
  • 46% wantrouwt het, 3% vertrouwt het sterk. Veel meer developers wantrouwen AI-uitvoer dan haar vertrouwen — en daarom is verificatie niet optioneel.
  • Meerdere agents is het nieuwe normaal. De productiefste engineers sturen vloten agents aan in plaats van meer code met de hand te schrijven.
  • TypeScript staat op 1. Getypeerde talen haalden Python in, deels omdat ze gegenereerde code eerlijk houden.

Wat we aan AI geven, en wat we houden

De helderste manier om ons proces te beschrijven is het werk in tweeën te delen: het deel dat we aan machines uitbesteden, en het deel dat we weigeren uit te besteden.

We geven AI de toetsaanslagen. Standaardwerk, CRUD-endpoints, de tiende variant van een formulier, lijmwerk dat data verplaatst, eerste versies van tests, migraties, de saaie mechanische transformaties die vroeger hele middagen opslokten — agents zijn daar werkelijk uitstekend in. Een model schrijft sneller een correct ogende uitvoering dan een mens die kan beschrijven. Dus laten we het. Er zit in 2026 geen eer meer in een gepagineerde lijstweergave met de hand uittypen.

We houden de architectuur. Waar leeft de state? Wat is de enige bron van waarheid voor dit domein? Welke grenzen mogen van welke andere weten? Hoe schaalt dit van één instantie naar twaalf? Wat is de faalwijze wanneer de betaaldienst een time-out geeft? Hoe buigt deze vorm mee wanneer de klant over drie maanden vraagt om het ding waarvan hij zweert dat hij er nooit om zal vragen? Geen daarvan heeft een antwoord op de "kortste weg naar draaiende code" — en de kortste weg naar draaiende code is het enige waarop een agent optimaliseert.

Deze verdeling is geen compromis. Het is de hoogste hefboom voor beide partijen. De machine doet waar ze snel in is; de mensen doen wat op dit moment alleen mensen goed doen. De uitdrukking die in de branche rondgaat — "Codex voor toetsaanslagen, Claude Code voor commits" — gaat eigenlijk over hoogte: hoe dichter je bij een besluit komt waar het hele systeem van afhangt, hoe meer een mens in de lus hoort.

Waarom architectuur menselijk moet blijven

Dit is de ongemakkelijke waarheid die we wekelijks zien, en het is de motor achter alles wat we net beschreven.

We voeren code-audits uit op een gestage stroom met AI gebouwde applicaties. De codebases verschillen enorm, maar de bevindingen vrijwel nooit: geheimen rechtstreeks in de repository vastgelegd, geen invoervalidatie, authenticatie die nooit controleert wie het vraagt, geen tests, dezelfde hulpfunctie vier keer gedupliceerd met kleine afwijkingen, twee schermen in één project geschreven alsof twee verschillende teams eraan werkten, complexe state ingeklapt tot callbackchaos, code die uitgaat van één machine en zichzelf corrumpeert zodra ze op twee draait. Elf problemen, keer op keer.

Elk daarvan is een eigenschap van het hele systeem. Geen ervan kan uit één goede prompt komen, want geen enkele prompt kan het geheel zien. Een model dat code genereert heeft een smal contextvenster en geen herinnering aan het besluit dat het drie bestanden geleden nam. Het maakt elke keer de lokaal optimale keuze — en de som van lokaal optimale keuzes is een codebase die vandaag werkt en zich morgen tegen elke wijziging verzet. Het uiteendrijven is geen fout in één generatie; het is de onvermijdelijke vorm van genereren zonder eigenaar van het geheel.

De rol van de mens kromp dus niet toen AI code begon te schrijven. Hij verschoof — van regels produceren naar de eigenschappen garanderen die alleen tussen regels bestaan. Samenhangende architectuur, één bron van waarheid, state gemodelleerd als state in plaats van een stapel racende callbacks, besef van de echte uitrolomgeving, beveiliging die standaard aanstaat. Dat is het bindweefsel. Het is het verschil tussen een demo en een product, en een agent die je alleen laat slaat het allemaal over. Dat laten we niet gebeuren.

Genereren en verifiëren: hoe we AI-code veilig houden

Er zit een echt vertrouwensgat in de cijfers, en dat nemen we serieus: in de branche wantrouwt 46% van de developers actief de uitvoer van AI en vertrouwt slechts 3% haar sterk. De volwassen reactie is niet stoppen met AI gebruiken — het is alles wat het produceert behandelen als niet-vertrouwde code van derden tot het tegendeel is bewezen. Genereer stevig; verifieer streng.

In de praktijk betekent dat dat elke regel die een agent schrijft door dezelfde poort gaat als de pull request van een ingehuurde bouwer:

  • Hij wordt door een mens gelezen, niet doorgebladerd. De vertrouwensval bij AI-code is dat ze er afgerond uitziet, zodat de 20% die dat niet is onzichtbaar blijft. We lezen op de dingen die modellen betrouwbaar fout doen — ontbrekende autorisatie achter een inlogscherm, invoer rechtstreeks in een query geplakt, een endpoint dat het hele gebruikersobject teruggeeft terwijl de interface een naam nodig had.
  • Hij krijgt tests, met opzet. Een functie genereren en tests ervoor genereren zijn twee verschillende verzoeken, en het tweede gebeurt zelden vanzelf. Wij zorgen dat het gebeurt: een rooktest dat de app start, echte dekking rond geld en authenticatie, en een regressietest voor elke bug die we oplossen.
  • Hij wordt afgemeten aan de architectuur, niet alleen aan "draait het". Een functie die werkt maar zijn eigen statepatroon verzint, of een bestaande hulpfunctie dupliceert, of over een grens reikt waarvan hij niet had mogen weten, gaat terug — ook als hij zijn gelukkige pad haalt.

Dit is dezelfde discipline die we voor oprichters met AI-prototypes beschreven in wat er breekt tussen de demo en productie. De korte formulering waar we steeds op terugkomen: AI brengt je 80% van de weg in 5% van de tijd — en die laatste 20% is het hele product. Wij laten de 80% aan AI. De 20% houden wij in handen.

Agents aansturen in plaats van meer code schrijven

De andere verschuiving die het landschap van 2026 benoemt is ontwikkelen met meerdere agents: in plaats van één assistent, gespecialiseerde agents die parallel draaien — een die de functie opstelt, een die tests schrijft, een die op beveiliging beoordeelt, een die de mechanische migratie afhandelt — met een engineer die het geheel aanstuurt.

Zo brengen onze engineers hun dag nu werkelijk door. Minder tijd binnen één functie, meer tijd besteed aan bepalen wat de agents moeten bouwen, in welke volgorde, tegen welke interfaces, en daarna controleren of wat terugkomt in het systeem past. Het voelt minder als typen en meer als technische leiding geven aan een heel snel, heel letterlijk team dat precieze richting en zorgvuldige beoordeling nodig heeft. De hefboom is enorm, maar alleen als degene die het orkest leidt een partituur — een architectuur — in het hoofd heeft. Richt een vloot agents op een codebase zonder ruggengraat en je krijgt sneller elf auditbevindingen.

De hefboom werkt twee kanten op

Agents versterken de richting die ze krijgen. Gericht op een heldere architectuur laten ze een sterke codebase sneller groeien. Gericht op geen architectuur laten ze een verknoopte sneller verknopen. De mens die de richting bepaalt is geen overhead boven op de AI — het is wat bepaalt of de AI een versneller of een lawine is.

Flexibiliteit is het hele punt

Is er één woord voor waarop we optimaliseren, dan is het niet snelheid — snelheid is nu goedkoop. Het is flexibiliteit: het vermogen een verandering in de eisen op te vangen zonder herbouw.

Daar betaalt de architectuur-eerst-aanpak zich het zichtbaarst terug. De met AI gebouwde codebases die we beoordelen zijn snel te starten en meedogenloos te wijzigen — ze verkalken, niet omdat de code goed en kostbaar is, maar omdat niemand hem durft aan te raken zonder tests, zonder samenhangende structuur, zonder te weten wat er nog meer breekt. Dat is het tegenovergestelde van flexibel. Een product dat niet kan veranderen is dood op de dag dat de markt beweegt.

Houdt een mens de architectuur in handen en doet AI het typewerk, dan krijg je beide helften: de snelheid van genereren en een systeem dat meebuigt. Er komt een nieuwe eis binnen, en er is één bron van waarheid om bij te werken in plaats van vier kopieën om op te sporen; één statemodel om uit te breiden in plaats van een callbackdoolhof om te ontwarren; één heldere grens om uit te breiden in plaats van een gok over welk van twee schermen het op de "juiste" manier doet. Precies dit deden we bij Arcana, een streamende AI-chatclient — het weinig glamoureuze werk om de architectuur, de streaming en het statemodel goed te krijgen is wat van een snel prototype iets maakte dat we konden blijven doorontwikkelen in plaats van herbouwen.

Dat is de hele stelling: we gebruiken AI zodat onze engineers hun beste uren niet meer aan toetsaanslagen besteden maar aan de besluiten die software flexibel houden. De code is nu het goedkope deel. De architectuur is het product.

Veelgestelde vragen

Nee, want we behandelen de uitvoer van AI nooit als afgerond. We volgen het patroon waar de branche in 2026 op uitkwam: genereer stevig, verifieer daarna streng. Elke regel die een agent schrijft wordt door een mens beoordeeld als de pull request van een ingehuurde bouwer, krijgt echte tests rond de delen die ertoe doen, en wordt tegen de systeemarchitectuur gelegd voordat hij uitkomt. AI doet het typewerk; mensen garanderen de kwaliteit. Zo gebruikt is het resultaat sneller en minstens zo degelijk als volledig handgeschreven code, omdat engineers hun aandacht aan ontwerp besteden in plaats van aan standaardwerk.
Zij nemen alles voor hun rekening waar AI slecht in is, en dat is het meeste van wat bepaalt of software standhoudt: architectuur, waar de state leeft, de enige bron van waarheid per domein, hoe het systeem over instanties schaalt, faalwijzen, beveiligingshouding, en flexibiliteit voor toekomstige verandering. Ze sturen ook de agents aan — bepalen wat er gebouwd wordt, in welke volgorde, tegen welke interfaces — en verifiëren wat terugkomt. Het menselijke werk verplaatste zich omhoog, van regels produceren naar de systeembrede eigenschappen garanderen die geen enkele prompt kan produceren.
Omdat een model elk bestand optimaliseert op de kortste weg naar draaiende code, en niemand de codebase als geheel optimaliseert. Het resultaat is voorspelbaar: vastgelegde geheimen, geen invoervalidatie, authenticatie die nooit controleert wie het vraagt, geen tests, gedupliceerde logica, geen consistente architectuur, state ingeklapt tot callbackchaos, en code die breekt zodra ze op meer dan één instantie draait. We zien deze elf problemen in vrijwel elke met AI gebouwde codebase die we beoordelen. Het zijn systeembrede fouten die niet prompt voor prompt kunnen ontstaan, dus moet een mens de architectuur in handen houden om de AI veilig te laten zijn.
Het betekent dat je voor oordeelsvermogen betaalt en niet voor toetsaanslagen. Genereren is nu het goedkope, snelle deel, dus het werk dat echt tijd kost is de architectuur, de verificatie, en de flexibiliteit voor toekomstige verandering — precies het werk dat je investering beschermt. In de praktijk krijg je prototypes en functies dramatisch sneller, zonder de verkalkte, onveranderlijke codebase te erven die pure AI-generatie doorgaans achterlaat. Je houdt de snelheid en je houdt het vermogen later van koers te veranderen.
Vrijwel altijd te redden, en vrijwel nooit een herbouw. De functies werken en het product is echt; wat ontbreekt is het bindweefsel — tests, een samenhangende architectuur, ontdubbelde logica, een deugdelijk statemodel, besef van de uitrolomgeving, en beveiliging. Dat kan allemaal ter plekke worden toegevoegd, veel sneller en goedkoper dan vanaf nul herbouwen. Precies die gerichte reparatie levert een audit van AI-code op: we behouden het fundament dat de AI goed deed en herstellen de systeembrede delen die hij niet aankon.

Bouw snel, blijf flexibel

De teams die in 2026 winnen zijn niet degenen die AI weigerden, en ook niet degenen die het onbewaakt lieten draaien. Het zijn degenen die de machine op de toetsaanslagen zetten en een mens op de architectuur. Zo bouwen wij elk project: AI voor snelheid, engineers voor de besluiten die software flexibel genoeg houden om zijn eigen succes te overleven.

Heb je een met AI gebouwde app en weet je niet zeker of die kan blijven meegroeien, haal hem dan door een audit van AI-code, of plan een gratis analyse. We vertellen je waar de architectuur stevig is, waar hij je gaat bijten, en wat het kost om dat te herstellen — met een offerte met vaste scope, geen gok.