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, omdat ze te veel zien en niet omdat ze het niet kunnen. Elke beslissing van de AI roept bij hen vragen op over architectuur, schaalbaarheid en foutafhandeling, en zo remmen ze zichzelf af met de kennis die ze hebben opgebouwd.
Een collega herkende zich daarin. We hadden een gesprek en hij paste zijn aanpak aan. Daarna 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 en 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 terecht. De blokkade die hem jaren had tegengehouden, de faalangst om te beginnen, was weg. Dat is geen klein ding en het was wat er moest gebeuren. Maar ik zag ook meteen een nieuwe valkuil opdoemen, een andere dan de vorige en net zo herkenbaar.
De logica van parallel werken
Zijn redenering klopte in zichzelf. Terwijl Claude in de ene ontwikkelstraat aan het werk is, kun je in de andere al weer prompten, dus je hoeft niet te wachten. De AI is de bottleneck niet en 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 en ze 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 en niet de AI. De AI kan prima zeven projecten parallel draaien, jij niet, of in elk geval niet zonder iets in te leveren. Aandacht is niet onbeperkt schaalbaar, en 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.”
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, naamgeving en inrichting, liggen straks ook verankerd in projecten twee tot en met zeven. Kom je er later achter dat iets niet handig was, dan moet je het op al die plekken tegelijk aanpassen.
Claude Code kan dat in principe aan, want de tooling is krachtig genoeg om breed te refactoren. Het principe blijft toch dat je niet zuinig bent met je middelen. Het lijkt op de kraan de hele dag open laten staan omdat water toch goedkoop is: de verspilling zit niet in de kosten per druppel maar in het patroon dat je jezelf aanleert.
Een portfolio van starts
Er speelt ook iets psychologisch dat het benoemen waard is.
De ideeën die hij nu aan het uitrollen is, lagen al jaren op de plank. Daarom voelde de doorbraak zo explosief. Het was geen nieuw inzicht maar het wegvallen van een rem op iets wat er allang lag. Die energie is begrijpelijk, na jaren stilstand wil je alles tegelijk. Maar waarom moest alles ineens nu?
Als iets jarenlang heeft kunnen wachten, kan het ook wachten tot het vorige klaar is. De urgentie is een gevoel en geen feit. Wie alles tegelijk begint en niets afmaakt, bouwt geen portfolio van producten maar een portfolio van starts, zonder robuuste inhoud, zonder aantoonbaar eindresultaat en zonder het leereffect dat alleen komt als je iets door alle fasen heen brengt.
Snel klaar met een MVP is niet hetzelfde als klaar
Hij had een goed 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, en het is een echte verschuiving die AI-ondersteund ontwikkelen mogelijk maakt.
Maar een MVP is geen eindpunt, het is een meetinstrument. Hij 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 een prototype zonder feedback loop. Zeven van die prototypes tegelijk betekent 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 dat expertise blokkeert, omdat experts te veel zien en te weinig durven te delegeren aan de AI.
De oplossing daarvoor is niet om de expert aan de kant te zetten en iemand zonder rem alles tegelijk te laten bouwen. De oplossing is leren wanneer je stuurt en wanneer je loslaat, en de AI vertrouwen zonder je eigen oordeel uit te schakelen. Dat is een vaardigheid en geen toestand.
Mijn collega heeft de rem losgegooid, en dat is stap één. Stap twee is leren remmen op het juiste moment, 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 en wil alles controleren. Dat levert weinig output op en veel frustratie.
Fase twee: de rem valt weg. Hij ontdekt dat loslaten werkt en bouwt snel en breed. Dat levert veel beweging op en weinig voltooiing.
Fase drie: gerichte inzet. Hij leert sturen en bepaalt wat klaar moet zijn, in welke volgorde en waarom. Dat levert output met diepgang en aantoonbare waarde op.
Mijn collega zit in fase twee, en dat is prima, want fase twee is beter dan fase één. Maar fase drie is waar het interessant wordt, en 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.