AI-gedreven softwarebouw: senior oordeel, AI-snelheid

Vorige week vroeg een oprichter me waarom ons team "zo klein" is voor de prijs. Omdat het model veranderd is.

Vijf jaar geleden was software bouwen = code typen. Ervaren ontwikkelaars waren de bottleneck omdat hun oordeel de schaarse input was, en je had juniors nodig om het typewerk te absorberen zodat de seniors over meer projecten konden worden uitgesmeerd. Het bureaumodel was rond die rekensom gebouwd: één senior architect, drie juniors die typen, factureer voor vier mensen.

Dat model is voorbij. AI doet het typen. De meeste bureaus hebben hun model niet bijgewerkt, ze factureren nog steeds vier seats. Hun marge kwam uit het gat tussen junior-kosten en het factuurtarief richting klant. Dat gat wordt nu opgevuld door een LLM.

Achttien maanden geleden hebben we de keuze gemaakt om het team anders te bouwen: alleen seniors, geen bench, geen "AI-assisted juniors." Elke engineer ship't op de snelheid die vroeger een team van vier vergde. De rekensom werkt omdat de AI de leverage-laag is, niet een derde headcount die we in de factuur verstoppen. Dit stuk is de lange versie van waarom.

Wat AI vermenigvuldigt

AI vermenigvuldigt geen skill. Het vermenigvuldigt wat je al hád.

Een ervaren ontwikkelaar met Claude Code in 2026 ship't in een week wat vroeger een maand kostte. Niet omdat hij anders prompt, maar omdat hij al weet wat hij moet bouwen, wat hij weglaat, waar de foot-guns zitten, en welke gegenereerde suggestie hij weggooit. De AI heeft de typ-bottleneck weggehaald. Het oordeel dat voorheen door dat typen werd beperkt, kan zich nu op volle snelheid uiten.

Een junior engineer met dezelfde tool ship't in een week wat hij eerst ook in een week ship'te. De output ziet er groter uit. Hij heeft ook dezelfde architectonische problemen als zijn eerdere code, nu op hogere snelheid, dus moeilijker terug te draaien.

Dit is het deel van de AI-gedreven verschuiving dat het discours blijft missen. De tool maakt het speelveld niet gelijker. Hij kantelt het juist harder richting de engineers die al oordeel hadden. Dat is de hele reden dat we alleen seniors aannemen. Het is geen credential-flex. Het is een operating model.

De dure bugs zijn omhoog opgeschoven in de stack

De duurste bug die we vorig jaar ge-ship't hebben, kwam door elke test, code review en AI-kritiek heen die we erop loslieten. De feature liet een geauthenticeerde gebruiker elk document opvragen op basis van ID. De ID's waren oplopend. De permissie-check verifieerde dat de gebruiker geauthenticeerd was. Hij verifieerde niet dat de gebruiker eigenaar was van het document.

Elke laag van geautomatiseerde review zei "ziet er goed uit." De code is ook goed. Het model heeft niet gefaald. Wat gefaald heeft, is de stap ervoor, het moment waarop iemand moet weten dat "authenticated" en "authorized" verschillende woorden zijn, en dat het beveiligingsmodel van dit specifieke product het tweede vraagt. Een ervaren ontwikkelaar ziet dat binnen twaalf seconden. Een LLM ziet het nooit, want hij weet niet waar jouw product voor is.

Dat is het bredere patroon. De bugs die AI betrouwbaar pakt, zijn de lokale: typfouten, type-errors, voor-de-hand-liggende off-by-ones. De bugs die hij mist, zijn de bugs waarvoor je moet weten waar het systeem voor dient. Een niet-uitputtende lijst van wat wij in 2026 zelf nog steeds moeten opvangen, en wat AI structureel laat liggen:

• De N+1 query die alleen afgaat als een specifieke subset van gebruikers een gecachte route raakt. De code ziet er schoon uit. Het query plan niet.
• De auth-check die op papier klopt en wie er mag lezen niet goed controleert.
• De migratie die in de testomgeving omkeerbaar is en in productie de tabel negen minuten op slot zet, vanwege een foreign key die in de staging-seed niet zat.
• De beslissing om iets niet te bouwen. Elke prompt produceert code. Soms is het juiste antwoord "ship dit niet; deze feature veroorzaakt een supportlast die je niet kunt dragen."
• De architectonische drift, drie weken aan feature-werk dat stilletjes wegloopt van het bestaande domeinmodel. Elke PR ziet er in isolatie prima uit. De drift komt pas naar boven als iemand het geheel leest.

Hoe het alleen ervaren team in de praktijk werkt

Een typische week ziet er zo uit. De engineer pakt een roadmap-item op. Hij brengt de eerste ochtend door met niet prompten. Hij schetst het domeinmodel, de dataflow, de edge cases, en de stukken bestaand systeem die mee moeten buigen. Dat is het beslis-werk. Het duurt een half uur tot twee uur, afhankelijk van de feature.

Daarna prompt hij, meestal drie of vier sessies parallel. Eén in Claude Code die de migratie uitwerkt. Eén in Cursor die het API-oppervlak schetst. Eén in zijn hoofd die de rollout ontwerpt. Eén in Slack waarin hij in discussie gaat of we de feature überhaupt nodig hebben.

Elke AI-sessie levert een diff op. De engineer leest elke regel. Hij gooit de tien tot dertig procent eruit die niet past in het model dat hij al had vastgesteld. Hij voegt de testcases toe die de AI niet bedacht, vooral de negatieve tests. Hij verwijdert de oude code die door de nieuwe wordt vervangen. De AI verwijdert vrijwel nooit; de mens altijd.

Tegen het einde van dag twee of drie staat de feature live. De codebase is niet groter dan nodig. Het domeinmodel is intact. De testsuite dekt het nieuwe gedrag én de negatieve cases. De volgende engineer die deze code leest (soms is dat dezelfde engineer twee maanden later) hoeft de beslissing niet uit prompts te reconstrueren.

De pricing-consequentie

De headcount-rekensom ziet er dan "dun" uit ten opzichte van de output. Dat is hij niet, hij is alleen losgekoppeld van het typewerk dat softwareteams op papier groot liet lijken.

Je betaalt niet voor minder mensen. Je betaalt voor dezelfde leveringsklaar throughput, met minder coördinatieoverhead, meer architectonische samenhang, en geen junior-ramp-up-belasting. Het voordeel ten opzichte van een junior-zwaar team of een in-house aanname stapelt zich op in de eerste zes maanden: dezelfde leveringsklaar output, €78.000 goedkoper dan twee eigen ontwikkelaars over een half jaar. Het AI-gedreven operating model is grotendeels waarom dat getal werkt.

Wanneer dit niet past

De eerlijke uitzondering: wil je een team dat indrukwekkend oogt op een status-rapport, acht mensen, meerdere tijdzones, wekelijkse all-hands, dan past Stacklane niet. Huur een van de grotere bureaus in die nog op de oude manier factureren. Zij maken uitstekende slide decks.

Wil je een team dat je roadmap ship't met de kleinst redelijke headcount en de grootst redelijke architectonische samenhang, daar is AI-gedreven softwarebouw voor. De rekensom is veranderd. De meeste bedrijven hebben dat nog niet door.