AI-native ontwikkeling: ervaren oordeel, AI-snelheid

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

Vijf jaar geleden was software bouwen hetzelfde als code typen. Ervaren ontwikkelaars waren de bottleneck omdat hun oordeel de schaarse input was, en je had juniors nodig om het typewerk op te vangen, zodat je de seniors over meer projecten kon verdelen. Het bureaumodel was om die rekensom heen 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 wat een junior kost en het tarief dat ze de klant rekenen. Dat gat wordt nu opgevuld door een LLM.

Achttien maanden geleden hebben we besloten het team anders op te bouwen: alleen seniors, geen reservebank, geen "AI-assisted juniors." Elke ontwikkelaar levert op de snelheid die vroeger een team van vier vergde. De rekensom werkt omdat de AI de laag is die het werk vermenigvuldigt, niet een derde persoon 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 levert in 2026 in een week op wat vroeger een maand kostte. Niet omdat hij anders prompt, maar omdat hij al weet wat hij moet bouwen, wat hij weglaat, waar de valkuilen zitten, en welke gegenereerde suggestie hij weggooit. De AI heeft de typ-bottleneck weggehaald. Het oordeel dat eerst door dat typen werd afgeremd, kan zich nu op volle snelheid uiten.

Een junior ontwikkelaar met dezelfde tool levert in een week op wat hij eerst ook in een week opleverde. Het lijkt meer. Maar hij heeft ook dezelfde architectuurproblemen als in zijn eerdere code, nu op hogere snelheid, en dus moeilijker terug te draaien.

Dit is het deel van de AI-verschuiving dat in het debat steeds wordt gemist. De tool maakt het speelveld niet gelijker. Hij kantelt het juist harder richting de ontwikkelaars die al oordeel hadden. Dat is de hele reden dat we alleen seniors aannemen. Het is geen blufnummer. Het is een manier van werken.

De dure bugs zijn omhoog opgeschoven in de stack

De duurste bug die we vorig jaar hebben opgeleverd, kwam door elke test, code review en AI-kritiek heen die we erop loslieten. De feature liet een ingelogde gebruiker elk document opvragen op basis van ID. De ID's liepen op. De permissie-check controleerde dat de gebruiker was ingelogd. Hij controleerde niet of de gebruiker ook eigenaar was van het document.

Elke laag geautomatiseerde review zei "ziet er goed uit." En de code ís ook goed. Het model heeft niet gefaald. Wat faalde, 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 om het tweede vraagt. Een ervaren ontwikkelaar ziet dat binnen twaalf seconden. Een LLM ziet het nooit, want hij weet niet waar jouw product voor bedoeld 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 onvolledige 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 bepaalde groep gebruikers een gecachte route raakt. De code ziet er goed uit. Het query plan niet.
• De auth-check die op papier klopt en niet goed controleert wie er mag lezen.
• De migratie die in de testomgeving omkeerbaar is en in productie de tabel negen minuten op slot zet, door een foreign key die in de staging-seed ontbrak.
• De beslissing om iets niet te bouwen. Elke prompt levert code op. Soms is het juiste antwoord "zet dit niet live; deze feature levert een supportlast op die je niet kunt dragen."
• De architecturale drift: drie weken feature-werk dat stilletjes wegdrijft van het bestaande domeinmodel. Elke PR ziet er op zichzelf prima uit. De drift komt pas boven als iemand het geheel leest.

Hoe een alleen-ervaren oplevering in de praktijk werkt

Een typische week ziet er zo uit. De ontwikkelaar pakt een roadmap-item op. De eerste ochtend prompt hij juist niet. 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 tegelijk. 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 waar hij de discussie aangaat of we de feature überhaupt nodig hebben.

Elke AI-sessie levert een diff op. De ontwikkelaar leest elke regel. Hij gooit de tien tot dertig procent eruit die niet past in het model dat hij al had bepaald. 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 ontwikkelaar die deze code leest (soms is dat dezelfde ontwikkelaar twee maanden later) hoeft de beslissing niet uit prompts terug te puzzelen.

De pricing-consequentie

Het aantal mensen lijkt dan "dun" ten opzichte van wat we opleveren. Dat is het niet; het staat alleen los van het typewerk dat softwareteams op papier groot liet lijken.

Je betaalt niet voor minder mensen. Je betaalt voor dezelfde hoeveelheid opleverbaar werk, met minder coördinatie eromheen, meer architecturale samenhang, en geen junior die nog op stoom moet komen. Het voordeel ten opzichte van een junior-zwaar team of een eigen aanname stapelt zich op in de eerste zes maanden: dezelfde opgeleverde output, €69.000 goedkoper dan twee eigen ontwikkelaars over een half jaar. De AI-native manier van werken is grotendeels waarom dat getal klopt.

Wanneer dit niet past

De eerlijke uitzondering: wil je een team dat indrukwekkend oogt op een statusrapport, 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 prima slide decks.

Wil je een team dat je roadmap oplevert met zo min mogelijk vaste mensen en zoveel mogelijk architecturale samenhang, daar is AI-native softwarebouw voor. De rekensom is veranderd. De meeste bedrijven hebben dat nog niet door.