Terughoudendheid is de belangrijkste vaardigheid voor ontwikkelaars in 2026

Vorige maand liet een vriend me zijn klantenportaal zien. Strak interface. Klanten waren er dol op. Simpel deliverables delen, goedkeuringsworkflows, een gefocuste tool die één ding extreem goed deed. Hij was er trots op. Terecht.

Toen opende hij zijn backlog en liet me de feature requests zien die het afgelopen kwartaal waren binnengekomen. Facturering. Tijdregistratie. Projectmanagement met Gantt charts. Een ingebouwd chatsysteem. Een rapportagedashboard. Hij kon ze allemaal bouwen — de meeste in een weekend, met Claude Code en een goed gestructureerde prompt. De AI maakte deze features niet alleen mogelijk. Het maakte ze triviaal eenvoudig.

Hij bouwde eerst de factureringsmodule. Daarna de tijdregistratie. Binnen zes weken was zijn strakke klantenportaal een opgeblazen projectmanagement-suite geworden die slecht concurreerde met Asana, slecht met FreshBooks en slecht met Slack — allemaal tegelijk. De onboardingtijd verdrievoudigde. Supporttickets verschoven van "hoe deel ik een deliverable?" naar "waar is de goedkeuringsknop gebleven?" Zijn oorspronkelijke klanten — degenen die zijn product juist kozen omdat het gefocust was — begonnen te vertrekken.

De tool die hem sneller dan ooit liet bouwen was dezelfde tool die hem zijn product sneller dan ooit liet vernietigen. En de vaardigheid die hij miste had niets met code te maken.

Het knelpunt waar niemand meer over praat

Jarenlang was de beperking voor softwareteams de uitvoeringssnelheid. Je had meer ideeën dan capaciteit. De backlog was een kerkhof van features die nooit gebouwd zouden worden omdat er simpelweg niet genoeg engineeringtijd was. Planning nam misschien 20% van de cyclus in beslag — de rest was heads-down implementatie, worstelen met dependencies, bugs fixen, opleveren.

Die beperking is verdwenen.

AI-coderingstools in 2026 hebben het uitvoeringsknelpunt zo volledig weggenomen dat de oude planning-naar-bouw-verhouding is omgekeerd. Waar teams vroeger 80% van hun tijd besteedden aan bouwen en 20% aan plannen, besteden de teams waarmee ik werk nu het grootste deel van hun tijd aan een vraag die drie jaar geleden nauwelijks bestond: moeten we dit überhaupt bouwen?

Dit is geen subtiele verschuiving. Het is een fundamentele verandering in wat een softwareontwikkelaar waardevol maakt. Het Chaos Report van de Standish Group ontdekte dat 50% van de features in maatwerksoftware zelden of nooit wordt gebruikt. Die statistiek komt uit een tijdperk waarin het bouwen van features duur en langzaam was. Wanneer bouwen goedkoop en snel is, gaat het percentage ongebruikte features niet omlaag — het gaat omhoog, omdat er geen natuurlijke wrijving is om overbouwen te voorkomen.

Het Project Management Institute meldt dat ruwweg de helft van alle projecten lijdt onder scope creep. Opnieuw — dat komt uit een tijdperk van beperkingen. Verwijder de beperkingen, en scope creep verdwijnt niet. Het versnelt.

Dit is wat ik heb geleerd na dit te zien gebeuren bij mijn eigen projecten en de teams die ik adviseer: de meest waardevolle vaardigheid in softwareontwikkeling is niet langer het vermogen om te bouwen. Het is de discipline om te beslissen wat je niet bouwt. En die discipline heeft een naam.

Terughoudendheid.

Waarom AI deze vaardigheid niet kan vervangen

Ik breng het grootste deel van mijn werkuren door in Claude Code. Ik heb geschreven over hoe het mijn hele ontwikkelworkflow heeft veranderd, hoe agent teams complexe projecten parallel kunnen aanpakken, hoe taakbeheer over sessies heen multi-file refactors heeft getransformeerd. Ik ben geen AI-scepticus. Ik zit diep in dit ecosysteem.

Maar dit is wat me is opgevallen na maanden van opleveren met deze tools: AI is buitengewoon goed in het hoe en echt verschrikkelijk in het of.

Vraag Claude Code om een factureringsmodule te bouwen voor een klantenportaal. Het genereert schone datamodellen, een solide UI, juiste validatie, edge case-afhandeling — het hele pakket. Wat het niet doet — wat het niet kan — is je vertellen dat het toevoegen van facturering je kerngebruikers in verwarring brengt, de identiteit van je product kannibaliseert, en je in directe concurrentie plaatst met FreshBooks, een bedrijf met een decennium aan domeinexpertise en $100M aan jaarlijkse omzet.

Dat is geen technische beslissing. Dat is een productbeslissing. En het vereist iets dat AI fundamenteel mist: een begrip van de context van je klant, je concurrentiepositie, en de tweede-orde-gevolgen van het toevoegen van oppervlakte aan je product.

Ik ben dit gaan zien als het verschil tussen vermogen en oordeelsvermogen. AI geeft je bijna oneindig vermogen. Oordeelsvermogen is het ding dat je vertelt welke vermogens je daadwerkelijk moet inzetten. En oordeelsvermogen komt alleen voort uit het begrijpen van de mensen die je software gebruiken — hun frustraties, hun workflows, de reden waarom ze jouw tool kozen boven de twaalf alternatieven.

Geen enkel model, hoe groot het contextvenster ook, kan dat begrip repliceren. Nog niet. Misschien nooit.

Het klantenportaalprobleem — een patroon dat ik steeds weer zie

Het klantenportaalverhaal waarmee ik opende is geen eenmalig geval. Ik heb dit patroon zien herhalen bij een half dozijn producten het afgelopen jaar, en het volgt altijd dezelfde boog.

Fase 1: Focus. Het product begint strak. Het lost één probleem goed op. Klanten zijn er dol op omdat het simpel, eigenwijs en snel is. Het team krijgt positieve reviews specifiek omdat het product niet probeert alles te doen.

Fase 2: Feature-druk. Klanten beginnen aangrenzende features te vragen. "Kunnen jullie facturering toevoegen?" "Hoe zit het met tijdregistratie?" "Het zou geweldig zijn als we hier ook projecten konden beheren." Elk verzoek is op zichzelf redelijk. Elke feature is te bouwen in dagen of zelfs uren met AI-assistentie.

Fase 3: De bouwval. Het team zegt ja tegen alles omdat ja zeggen makkelijk is wanneer bouwen goedkoop is. Ze leveren feature na feature op, elk daarvan voegt complexiteit toe aan de UI, het datamodel, de onboardingflow en de supportlast.

Fase 4: Identiteitscrisis. Het product dat "de beste tool voor het delen van deliverables" was, is nu "een middelmatige tool die ook zes andere dingen doet." Nieuwe gebruikers openen het en voelen zich overweldigd. Oorspronkelijke gebruikers kunnen de features niet vinden waarvoor ze kwamen. Het product heeft zijn bestaansreden verloren.

Fase 5: Verval. Churn neemt toe. Het team reageert door meer features te bouwen om gebruikers te behouden, wat het probleem verergert. Het is een neerwaartse spiraal aangedreven door precies de snelheid die AI biedt.

De oplossing is niet langzamer bouwen. De oplossing is beter beslissen.

Hoe terughoudendheid er in de praktijk uitziet

Terughoudendheid is niet nee zeggen tegen alles. Dat is verlamming, geen strategie. Terughoudendheid is een framework hebben om te beslissen welke dingen je bouwt en — cruciaal — een proces hebben dat je dwingt die beslissing te nemen voordat je ook maar één regel code aanraakt.

Dit is het framework dat ik heb aangenomen, en het heeft mijn benadering van elk project opnieuw vormgegeven.

Stap 1: Het pre-planning gesprek

Voordat ik Claude Code open, voordat ik een enkele regel van een spec schrijf, heb ik wat ik een vormgevend gesprek noem. Soms is dit met een mede-oprichter of een productlead. Soms ben ik het alleen met Claude in een apart gespreksvenster — niet in codemodus, maar in denkmodus.

Het doel van dit gesprek is niet "hoe bouwen we dit." Het doel is "moeten we dit bouwen, en zo ja, wat bouwen we precies?"

Ik gebruik Claude hier als strategische gesprekspartner. Niet door het een rigide lijst vragen te geven — dat levert formulaïsche antwoorden op. In plaats daarvan beschrijf ik het feature-idee en vraag Claude om het onder druk te zetten. Mijn aannames uitdagen. Afwegingen naar boven halen die ik niet heb overwogen. Vragen stellen waarop ik nog geen goed antwoord heb.

Een typische prompt ziet er ongeveer zo uit:

Ik overweeg om [feature] toe te voegen aan [product]. Het product doet momenteel [kernfunctie]
voor [doelklant]. Voordat ik iets bouw, wil ik dat je optreedt als kritische productstrateg.
Stel me verduidelijkende vragen over:

- Het kernprobleem dat deze feature oplost
- Wie er specifiek om vraagt en waarom
- Wat ze momenteel in plaats daarvan doen
- Of dit de identiteit van het product versterkt of verwatert
- Waar we nee tegen moeten zeggen om dit goed te doen

Geef me geen rigide vragenlijst. Voer een echt gesprek. Duw terug wanneer mijn
redenering zwak is.

Wat uit dit gesprek komt is helderheid. Soms overleeft de feature het intact. Soms wordt de scope drastisch verkleind. Soms realiseer ik me dat het helemaal niet gebouwd zou moeten worden — in ieder geval niet als native feature.

Stap 2: Het integratie-eerst alternatief

Een van de krachtigste vormen van terughoudendheid is kiezen voor integratie boven implementatie. In plaats van facturering in het klantenportaal te bouwen, bied een Stripe- of FreshBooks-integratie aan. In plaats van projectmanagement te bouwen, verbind met Linear of Asana via API.

Deze aanpak heeft een echt voordeel voorbij productfocus: je gebruikers krijgen best-in-class tools voor elke functie in plaats van een middelmatige ingebouwde versie. En je engineeringteam onderhoudt een kleinere, meer gefocuste codebase.

In de agent-skills-architectuur die opkomt in AI-coderingstools past dit perfect. In plaats van monolithische features te bouwen, bouw je gefocuste agent skills die kunnen samenwerken met externe services. Elke skill doet één ding. Elke skill is testbaar, onderhoudbaar en onafhankelijk vervangbaar.

Ik heb met dit patroon gebouwd in Claude Code, en de agent skills-aanpak maakt het bijzonder natuurlijk. Een skill die verbindt met Stripe's API is schoner, beter onderhoudbaar en krachtiger dan een halfbakken factureringsmodule die je zelf hebt gebouwd.

Stap 3: Het scope boundary document

Voordat een feature een spec krijgt, krijgt het een scope boundary. Dit is een kort document — meestal minder dan een pagina — dat expliciet vermeldt wat binnen scope valt en wat buiten scope valt. Niet als formaliteit, maar als commitment.

Zo zien de mijne eruit:

De "Waarom buiten scope"-kolom is de belangrijke. Het dwingt je om de reden te formuleren waarom iets niet gebouwd moet worden, wat het veel moeilijker maakt om het er later stilletjes aan toe te voegen wanneer iemand er vriendelijk om vraagt.

Plan Mode is nu industriestandaard — maar het is niet genoeg

Er gebeurde iets interessants in AI-coderingstools begin 2026. Claude Code, Cursor en Codex convergeerden allemaal op hetzelfde architecturale patroon: een speciale planmodus die denken scheidt van bouwen.

In Claude Code ga je naar planmodus door Shift+Tab te drukken of /plan te typen. Het model schakelt naar alleen-lezen — het verkent je codebase, stelt verduidelijkende vragen en genereert een implementatieplan zonder een enkel bestand te schrijven. Cursor heeft een vergelijkbaar mechanisme. Zo ook Codex, met zijn eigen variatie op het patroon.

Deze convergentie is niet toevallig. De toolmakers kwamen allemaal tot dezelfde conclusie: ontwikkelaars die plannen voordat ze bouwen produceren betere resultaten. Spec-driven development — waarbij de specificatie de bron van waarheid is, niet de code — is de industriestandaard workflow geworden voor serieuze AI-ondersteunde ontwikkeling.

Maar dit is wat de meeste mensen missen over planmodus: het lost het hoe te bouwen probleem op. Het lost niet het wat te bouwen probleem op.

Planmodus treedt in werking nadat je al hebt besloten iets te bouwen. Het helpt je het goed te bouwen. Het helpt je nadenken over architectuur, dataflows, dependencies, edge cases. Dat is oprecht waardevol — ik gebruik het bij elke significante feature.

Wat planmodus niet doet is de vraag stellen of de feature überhaupt zou moeten bestaan. Het neemt je beslissing om te bouwen als gegeven en optimaliseert de uitvoering. Dat is alsof je een briljante navigator hebt die de snelste route naar elke bestemming kan vinden maar nooit vraagt of je naar de juiste stad gaat.

Het pre-planning gesprek dat ik eerder beschreef is de ontbrekende laag. Het zit boven planmodus in de workflowhiërarchie. Eerst beslis je wat je bouwt (pre-planning). Dan beslis je hoe je het bouwt (planmodus). Dan bouw je het (implementatie).

Sla de eerste stap over, en planmodus helpt je alleen maar sneller het verkeerde ding te bouwen.

De spec-driven development workflow die echt werkt

Dit is de complete workflow waar ik op ben uitgekomen na maanden van iteratie. Het combineert het strategische terughoudendheid-gesprek met de tactische planning die tools zoals Claude Code bieden.

Fase 1: Vormgeven (Mens + AI als denkpartner)

Dit is het pre-planning gesprek. Je schrijft geen code. Je schrijft geen specs. Je denkt — hardop, met AI als klankbord.

Inputs: Een ruw feature-idee, klantfeedback, marktsignaal of concurrentiedruk.

Proces:

1. Beschrijf het idee aan Claude in een niet-coderende context
2. Laat Claude verduidelijkende vragen stellen (voer het geen rigide template)
3. Definieer de kern "job to be done" — welk probleem lost dit op?
4. Identificeer de doelklant en hun huidige workaround
5. Test de scope onder druk — wat valt erbinnen, wat erbuiten, en waarom
6. Breng de gebruikersstroom in kaart voordat je technische details aanraakt

Output: Een lichtgewicht Product Requirements Document (PRD) met probleemstelling, scope boundaries, gebruikersstromen en expliciete beslissingen over wat je niet bouwt.

De sleutelzet hier: de PRD zou minstens zoveel moeten bevatten over wat je hebt besloten tegen als wat je hebt besloten voor. Die documentatie van terughoudendheid is wat scope creep later voorkomt.

Fase 2: Plannen (AI-coderingstool in planmodus)

Nu neem je de PRD mee naar Claude Code, Cursor of je tool naar keuze en ga je naar planmodus.

Inputs: De PRD uit Fase 1.

Proces:

1. Voer de PRD in Claude Code in planmodus (/plan of Shift+Tab)
2. Laat het model je bestaande codebase analyseren tegen de vereisten
3. Genereer een architecturaal plan: datamodellen, API-endpoints, componentstructuur
4. Review het plan op scope creep — introduceert het iets dat niet in de PRD staat?
5. Itereer totdat het plan exact overeenkomt met de scope boundaries

Output: Een gedetailleerd implementatieplan met file-voor-file wijzigingen, afhankelijkheidsvolgorde en geschatte complexiteit.

Fase 3: Bouwen (AI-coderingstool in implementatiemodus)

Pas nu schrijf je code. En omdat je het strategische werk vooraf hebt gedaan, is de implementatie gefocust, snel en gedisciplineerd.

Inputs: Het goedgekeurde plan uit Fase 2.

Proces:

1. Voer het plan stap voor stap uit
2. Gebruik parallelle taakuitvoering voor onafhankelijke werkstromen
3. Controleer elke voltooide component tegen het scope boundary document
4. Stop wanneer het plan compleet is — weersta de verleiding om "nog één ding" toe te voegen

Output: Werkende code die exact overeenkomt met de spec. Niets meer, niets minder.

Fase 4: Valideren (Menselijk oordeelsvermogen)

Nadat de bouw klaar is, loop je terug naar de strategische laag.

Versterkt deze feature de identiteit van het product of verwatert het die? Voelt de gebruikersstroom goed? Is er iets dat je hebt gebouwd dat, achteraf gezien, een integratie had moeten zijn in plaats van een native feature?

Dit is waar je de scope creep vangt die tijdens de implementatie is binnengeslopen. Het gebeurt zelfs met goede planning. De discipline is het opvangen voordat het wordt uitgerold.

Als je liever iemand hebt die deze planning-naar-implementatie pipeline van scratch bouwt, neem ik architectuur- en workflowconsulting-opdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

De vervaging tussen bouwer en productmanager

Dit is iets dat ik een jaar geleden niet had verwacht te schrijven: de rol van "ontwikkelaar" en de rol van "productmanager" groeien samen.

Toen bouwen het knelpunt was, had je gespecialiseerde mensen nodig om productbeslissingen te nemen (PM's) en gespecialiseerde mensen om die beslissingen uit te voeren (engineers). De verdeling was logisch omdat de uitvoering zo tijdrovend was dat het mengen van productdenken alles zou vertragen.

Nu AI het gros van de uitvoering afhandelt, is de bouwer die geen productbeslissingen kan nemen... beperkt. Je bent snel in bouwen, zeker. Maar snel in het bouwen van wat? Als je iemand anders nodig hebt om je te vertellen wat de moeite waard is om te bouwen, werk je op halve capaciteit.

De meest effectieve solo-ontwikkelaars en kleine teams die ik ken in 2026 hebben productmanagement-vaardigheden geïnternaliseerd. Ze denken na over klantsegmenten, concurrentiepositionering, feature-afwegingen en markt-timing — niet omdat ze er een boek over hebben gelezen, maar omdat de AI het excuus wegnam om er niet over na te denken. Wanneer je alles in een weekend kunt bouwen, verdampt het verweer "ik ben te druk met coderen om na te denken over productstrategie".

Dit is een oneerlijk voordeel voor bouwers die de discipline ontwikkelen. Terwijl je concurrent AI gebruikt om twaalf features per maand op te leveren, gebruik jij AI om er drie op te leveren — maar de drie die jij levert zijn degene die er echt toe doen. Je product blijft gefocust. Je gebruikers blijven blij. Je codebase blijft onderhoudbaar.

Dat is terughoudendheid. En het is het ding dat producten waar mensen van houden onderscheidt van producten die mensen tolereren.

Wat ik fout had over snelheid

Ik moet eerlijk zijn over iets. De eerste paar maanden nadat Claude Code mijn primaire ontwikkeltool werd, trapte ik in precies de val waarvoor ik nu waarschuw.

De snelheid was bedwelmend. Ik bedacht een feature om 9 uur 's ochtends en had die voor de lunch gedeployed. Mijn wekelijkse output verdrievoudigde. Ik mat mijn productiviteit in opgeleverde features, en dat aantal ging elke week omhoog. Ik voelde me ongelooflijk productief.

Toen keek ik naar mijn analytics. Time-on-page voor mijn documentatie was gedaald. Gebruikersactivatiepercentages waren niet verbeterd ondanks alle nieuwe features. Supporttickets waren toegenomen — niet omdat dingen kapot waren, maar omdat gebruikers niet konden vinden wat ze nodig hadden in een steeds rommeliger interface.

Ik leverde meer op en bereikte minder. De AI versterkte mijn output, maar mijn output was ongefocust. Snelheid zonder richting is gewoon vibratie.

De correctie was pijnlijk. Ik besteedde een volledige week aan niets anders dan features verwijderen. Code verwijderen die perfect werkte. Flows vereenvoudigen die te veel stappen hadden. Teruggaan naar de gefocuste versie waarvoor gebruikers zich oorspronkelijk hadden aangemeld.

Die week van aftrekken produceerde betere engagement-metrics dan de voorgaande maand van toevoeging. En het leerde me iets dat ik vanaf het begin had moeten weten: de waarde van een product wordt niet gemeten aan wat het kan. Het wordt gemeten aan hoe goed het datgene doet waarvoor de gebruiker kwam.

Een praktisch sjabloon voor het pre-planning gesprek

Ik beloofde een framework, dus hier is het daadwerkelijke sjabloon dat ik gebruik voor het vormgevende gesprek voordat er aan een feature wordt gewerkt. Dit is geen rigide vragenlijst — het is een startstructuur waaruit het gesprek evolueert.

Openingsprompt aan Claude (of je team):

Ik overweeg om [feature] toe te voegen aan [product]. Voordat ik iets plan of bouw,
wil ik deze beslissing onder druk zetten. Hier is de ruwe context:

- Product: [wat het vandaag doet]
- Doelklant: [wie het gebruikt]
- Feature-idee: [wat wordt overwogen]
- Bron van verzoek: [klantfeedback / concurrentiedruk / intern idee]

Treed op als kritische productstrateg. Je taak is me te helpen beslissen OF dit
gebouwd moet worden, niet HOE. Stel me vragen op deze gebieden:

1. Kernprobleem: Welke taak vervult deze feature voor de gebruiker?
2. Klantcontext: Wie wil dit specifiek? Zijn zij onze doelklant?
3. Huidige workarounds: Wat doen gebruikers vandaag? Is het gat pijnlijk genoeg?
4. Concurrentierealiteit: Wie doet dit al goed? Kunnen wij het beter?
5. Scope-risico: Breidt dit het productoppervlak uit op een manier die de identiteit verwatert?
6. Integratiealternatief: Kan dit opgelost worden door een integratie?

Voer een echt gesprek. Duw terug wanneer mijn redenering dun is.

Wat de output zou moeten bevatten:

De beslissingskolom is wat dit anders maakt dan een traditionele PRD. De meeste PRD's gaan ervan uit dat de feature gebouwd wordt — het document bestaat om te beschrijven hoe. Dit document gaat uit van de aanname dat de feature mogelijk niet gebouwd wordt, en vereist een positieve motivering voordat er verder wordt gegaan.

Waar dit niet werkt (en waar wel)

Ik zou oneerlijk zijn als ik dit als een foutloos framework presenteerde. Terughoudendheid heeft ook faalwijzen.

Wanneer terughoudendheid verlamming wordt. Er is een versie hiervan waarbij je elk feature request zo grondig analyseert dat er niets gebouwd wordt. Analyseverlamming is echt, en het vormgevende gesprek kan het voeden als je niet oppast. De oplossing is tijdsafbakening: geef het pre-planning gesprek een maximum van 2-3 uur voor elke individuele feature. Als je binnen dat venster geen beslissing kunt nemen, is het probleem niet de feature — het is onvoldoende klantbegrip. Ga in plaats daarvan met gebruikers praten.

Wanneer je moet verkennen. Sommige features moeten gebouwd worden voordat je weet of ze goed zijn. Prototyping heeft waarde. Het framework dat ik heb beschreven werkt het best voor productie-features die naar echte gebruikers worden uitgerold. Voor interne experimenten en prototypes is een lichter proces logisch. Bouw het, test het met een kleine groep, en neem de terughoudendheid-beslissing op basis van echte gebruiksdata in plaats van alleen pre-planning.

Wanneer de markt snel beweegt. In echt competitieve markten waar snelheid naar feature-pariteit het voortbestaan bepaalt, kan excessieve terughoudendheid je het spel kosten. Het framework is nog steeds van toepassing, maar het vormgevende gesprek zou korter en meer gefocust moeten zijn op competitieve noodzaak dan op ideale productvisie.

Waar het consistent werkt: producten met een gedefinieerd publiek, producten voorbij de initiële product-market-fit fase, en producten waar gebruikerstevredenheid belangrijker is dan feature-checkboxen. Dat beschrijft de meeste B2B SaaS, de meeste ontwikkelaarstools en de meeste consumentenproducten met op retentie gebaseerde bedrijfsmodellen.

De faalwijze waar ik me het minst zorgen over maak is dat iemand te veel terughoudendheid aanneemt. In mijn ervaring is de gravitatiekracht richting bouwen zo sterk dat elk framework dat een pauze afdwingt — zelfs een korte — betere resultaten oplevert dan de standaard.

Het oneerlijke voordeel dat niemand verkoopt

Er is een reden waarom niemand het over terughoudendheid heeft op tech Twitter. Het demonstreert niet goed. "Ik besloot deze feature niet te bouwen" is geen tweet die engagement krijgt. "Ik heb een complete SaaS opgeleverd in 6 minuten" wel. De incentivestructuur van de publieke conversatie in onze industrie is vooringenomen richting snelheid, output en vermogen — niet oordeelsvermogen, focus of discipline.

Maar praat met de founders die al vijf of tien jaar opleveren. Degenen met producten die nog steeds gepassioneerde gebruikersgroepen hebben. Vraag hen wat hun belangrijkste productbeslissing was, en bijna niemand zal naar een feature wijzen die ze hebben gebouwd. Ze wijzen naar een feature die ze niet hebben gebouwd. Een richting die ze niet zijn ingeslagen. Een moment waarop ze keken naar wat mogelijk was en focus kozen boven vermogen.

AI maakt die keuze moeilijker dan ooit. Wanneer je alles in een weekend kunt bouwen, voelt "nee" zeggen als verspilling. Het voelt alsof je waarde op tafel laat liggen. Elk vezel van je bouwersinstinct schreeuwt om het op te leveren.

De bouwers die dat instinct weerstaan — die terughoudendheid behandelen als een vaardigheid om te ontwikkelen, niet een obstakel om te overwinnen — zijn degenen die producten bouwen die standhouden.

Je AI-tools zullen steeds sneller worden. De modellen zullen steeds slimmer worden. De uitvoeringskosten van elke feature zullen steeds meer naar nul neigen. Het enige dat niet zal veranderen is de kosten van het bouwen van het verkeerde ding: verwarde gebruikers, opgeblazen producten, toenemende onderhoudslast, en een langzame erosie van de focus die jouw product de moeite waard maakte om te gebruiken.

De volgende keer dat je Claude Code of Cursor of Codex opent met een nieuw feature-idee, probeer iets voordat je de eerste prompt typt. Sluit de coderingstool. Open een leeg gesprek. En stel jezelf de vraag die AI niet voor je kan beantwoorden:

Zou dit überhaupt moeten bestaan?

Veelgestelde vragen

Wat is terughoudendheid in softwareontwikkeling?

Terughoudendheid is de discipline om te beslissen wat je niet bouwt, zelfs wanneer je het vermogen hebt om het te bouwen. In 2026, met AI-tools die uitvoering bijna onmiddellijk maken, betekent terughoudendheid evalueren of een feature de identiteit van je product versterkt en je kerngebruikers dient voordat je je aan implementatie committeert.

Hoe werkt planmodus in Claude Code?

De planmodus van Claude Code wordt geactiveerd via Shift+Tab of het /plan commando. Het schakelt de AI naar alleen-lezen modus waar het je codebase verkent, verduidelijkende vragen stelt en een implementatieplan genereert zonder bestanden te schrijven. Voor een diepere kijk op Claude Code workflows, zie mijn crash course gids.

Wat is spec-driven development?

Spec-driven development behandelt de specificatie — niet de code — als de bron van waarheid. Je schrijft eerst een gedetailleerde spec, en AI-tools genereren, testen en valideren code ertegen. GitHub heeft een open-source spec-kit uitgebracht om deze workflow te ondersteunen, en grote tools zoals Claude Code, Cursor en Codex hebben allemaal plan-first patronen aangenomen.

Hoe voorkom je feature bloat wanneer AI snel bouwen mogelijk maakt?

Gebruik een pre-planning gesprek voordat je aan een spec begint. Definieer scope boundaries expliciet — wat erbinnen valt, wat erbuiten, en waarom. Kies integratie boven implementatie voor niet-kernfeatures. En meet productsucces aan gebruikersresultaten, niet aan feature-aantallen.

Waarom kan AI productstrategiebeslissingen niet vervangen?

AI blinkt uit in uitvoering — code genereren, architectuur optimaliseren, implementatiedetails afhandelen. Maar strategische productbeslissingen vereisen begrip van klantcontext, concurrentiepositionering en tweede-orde-gevolgen die huidige modellen niet betrouwbaar kunnen beoordelen. De vraag of je moet bouwen blijft een menselijke verantwoordelijkheid.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur opschalen? Ik help je graag.

• Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io