Van blokkade naar beweging — en de volgende val
Van blokkade naar beweging
In een eerder artikel beschreef ik hoe de beste IT'ers vaak de slechtste vibe-coders zijn. Niet omdat ze het niet kunnen, maar omdat ze te veel zien. Elke beslissing van de AI roept bij hen vragen op over architectuur, schaalbaarheid, foutafhandeling. Ze remmen zichzelf af met de kennis die ze hebben opgebouwd.
Een collega herkende zich daarin. We hadden een gesprek. Hij paste zijn aanpak aan.
En toen ging hij volledig los.
Zeven projecten in twee avonden
Twee avonden later stond hij in onze groepschat met een lijst van zeven projecten die hij had opgezet: een platform voor business-analyse, een persoonlijke pagina, een site voor een familiegenealogieplatform, een overhaul van een stichtingswebsite, een PoC voor architecten. Alles tegelijk. Alles in beweging. Niets echt af.
“Sjezus boys, ik ben helemaal los,” was zijn opening.
Het enthousiasme was aanstekelijk. En eerlijk gezegd ook terecht. De blokkade die hem jaren had tegengehouden — de faalangst om überhaupt te beginnen — was weg. Dat is geen klein ding. Dat is precies wat er moest gebeuren.
Maar ik zag meteen een nieuwe valkuil opdoemen. Een andere dan de vorige, maar net zo herkenbaar.
De logica van parallel werken
Zijn redenering was coherent. Terwijl Claude in de ene ontwikkelstraat aan het werk is, kun je in de andere al weer prompten. Je hoeft niet te wachten. De AI is de bottleneck niet, jij bent de bottleneck niet — de reviewers zijn de bottleneck. Hij draaide zeven projecten parallel met kinderlijk gemak, zoals hij het zelf noemde. En hij had een naam voor zijn methode: de buckshot-methode. Breed schieten, snel resultaat, dan kijken wat raak is.
Dat is geen onzinnige strategie. Het heeft zelfs iets verleidelijk rationeels. Fail fast, breed valideren, MVPs uitrollen en wachten op beslissers. Waarom zou je in de rij staan bij één idee als je er zeven tegelijk kunt laten bouwen?
Ik snap de redenering. Maar ik snap ook wat er mis mee kan gaan.
De zwakste schakel ben jij
Het eerste probleem is het eenvoudigste: de zwakste schakel in dit proces is de mens. Niet de AI. De AI kan prima zeven projecten parallel draaien. Jij kunt dat niet — of in elk geval niet zonder iets in te leveren. Aandacht is niet onbeperkt schaalbaar. Wie zeven lijnen tegelijk bewaakt, bewaakt geen van alle grondig.
Dat erkende hij zelf ook, zij het indirect: “Het is denk ik vooral de vraag hoe lang je dit soort monsterwerk kunt volhouden.”
Precies.
De legacy trap
Het tweede probleem is minder zichtbaar, maar op termijn groter. Ik noem het de legacy trap.
Als je zeven projecten in hoog tempo opzet zonder ze tot een logisch eindpunt te brengen, bouw je technische schuld op op zeven fronten tegelijk. Beslissingen die je vroeg in project één hebt genomen — over structuur, over naamgeving, over hoe iets is ingericht — liggen straks ook verankerd in projecten twee tot en met zeven. Als je er later achter komt dat iets niet handig was, moet je dat op al die plekken tegelijk aanpassen.
Claude Code kan dat in principe aan. De tooling is krachtig genoeg om breed refactoring door te voeren. Maar het principe blijft: je bent niet zuinig met je middelen. Het is een beetje alsof je de kraan de hele dag open laat staan omdat het water toch goedkoop is. De verspilling zit niet in de kosten per druppel, maar in het patroon dat je aanleert.
Een portfolio van starts
Er is ook iets psychologisch aan de hand dat het benoemen waard is.
De ideeën die hij nu aan het uitrollen is, lagen al jaren op de plank. Dat is de reden waarom de doorbraak zo explosief voelde: het was geen nieuw inzicht, het was het wegvallen van een rem op iets wat er allang lag. Die energie is begrijpelijk. Die golf van beweging na jarenlange stilstand — je wilt alles tegelijk.
Maar waarom moest alles ineens nu?
Als iets jarenlang heeft kunnen wachten, kan het ook wachten totdat het vorige klaar is. De urgentie is een gevoel, geen feit. En wie alles tegelijk begint maar niets afmaakt, bouwt geen portfolio van producten. Hij bouwt een portfolio van starts — zonder robuuste inhoud, zonder aantoonbaar eindresultaat, zonder het leereffect dat alleen komt als je iets echt door alle fasen heen brengt.
Snel klaar met een MVP is niet hetzelfde als klaar
Hij had een mooi punt over de buckshot-methode en het fail-fast-principe. Met AI ben je zo snel klaar met een MVP, zei hij, dat je je productontwikkelstrategie daarop moet aanpassen. Waarom nog Figma-mockups bouwen als je de echte zaak als PoC kunt opleveren?
Dat klopt. Dat is een echte verschuiving die AI-ondersteund ontwikkelen mogelijk maakt.
Maar een MVP is geen eindpunt. Het is een meetinstrument. Een MVP heeft waarde als je er iets mee doet: testen, terugkoppeling ophalen, een beslissing nemen. Een MVP die klaarstaat terwijl de beslisser nog niet heeft gekeken, is geen MVP — het is een prototype zonder feedback loop. En zeven van die prototypes tegelijk is zeven keer wachten in plaats van één keer leren.
Wat de vorige les eigenlijk zei
Kijk terug naar het eerste artikel in deze reeks. De kern was: expertise blokkeert, omdat experts te veel zien en te weinig durven delegeren aan de AI.
De oplossing daarvoor is niet: zet de expert aan de kant en laat iemand zonder rem gewoon alles tegelijk bouwen. De oplossing is: leer wanneer je stuurt en wanneer je loslaat. Leer de AI vertrouwen zonder je eigen oordeel uit te schakelen. Dat is een vaardigheid, geen toestand.
Mijn collega heeft de rem losgegooid. Dat is stap één. Stap twee is leren remmen op het juiste moment — niet omdat het moet, maar omdat je daarmee verder komt.
Drie fasen, één les
Als ik de reeks tot nu toe samenvat, zie ik drie herkenbare fasen in hoe mensen AI-ondersteund ontwikkelen leren hanteren:
Fase één: de expert blokkeert. Hij ziet te veel, vertrouwt de AI niet, wil alles controleren. Resultaat: weinig output, veel frustratie.
Fase twee: de rem valt weg. Hij ontdekt dat loslaten werkt, bouwt snel, bouwt breed. Resultaat: veel beweging, weinig voltooiing.
Fase drie: gerichte inzet. Hij leert sturen — bepaalt wat klaar moet zijn, in welke volgorde, en waarom. Resultaat: output met diepgang en aantoonbare waarde.
Mijn collega zit in fase twee. Dat is prima. Fase twee is beter dan fase één. Maar fase drie is waar het interessant wordt.
Ik ben benieuwd wanneer hij daar aankomt.
Dit is het derde deel in een reeks over ervaringen met AI-ondersteund ontwikkelen. Eerder verschenen: ‘Waarom de beste IT’ers het slechtst vibe-coden’ en ‘Je ziet niet wat ik doe’.
Jan-Willem Rodenhuis is managing partner van Ductus B.V. en schrijft op miliarium.nl over de praktijk van AI-adoptie in organisaties.