From blocked to moving, and the next trap
From blocked to moving
In an earlier article I described how the best IT people are often the worst vibe coders, because they see too much and not because they can't do it. Every decision the AI makes raises questions for them about architecture, scalability and error handling, and so they slow themselves down with the knowledge they have built up.
A colleague recognised himself in that. We talked, and he changed his approach. Then he went all in.
Seven projects in two evenings
Two evenings later he turned up in our group chat with a list of seven projects he had started: a business analysis platform, a personal page, a site for a family genealogy platform, an overhaul of a foundation's website and a PoC for architects. All at once, all in motion, none really finished.
“Jesus boys, I'm completely off the leash,” was how he opened.
The enthusiasm was infectious, and rightly so. The block that had held him back for years, the fear of failing at the start, was gone. That is no small thing, and it was what needed to happen. But I also saw a new trap taking shape straight away, a different one from the last and just as familiar.
The logic of working in parallel
His reasoning held together. While Claude is busy in one development lane, you can already be prompting in the next, so you never have to wait. The AI is not the bottleneck and neither are you; the reviewers are. He ran seven projects in parallel with childlike ease, as he put it himself, and he had a name for his method: the buckshot method. Shoot wide, get quick results, then see what hit.
That is not a nonsensical strategy, and it has something tempting and rational about it: fail fast, validate broadly, roll out MVPs and wait for decision makers. Why queue up behind one idea when you can have seven built at once? I understand the reasoning, but I also understand what can go wrong with it.
You are the weakest link
The first problem is the simplest one. The weakest link in this process is the human and not the AI. The AI can run seven projects in parallel without trouble, you can't, or at least not without giving something up. Attention does not scale without limit, and anyone watching seven lines at once is not watching any of them thoroughly.
He admitted as much himself, if indirectly: “Het is denk ik vooral de vraag hoe lang je dit soort monsterwerk kunt volhouden.” (I think it mainly comes down to how long you can keep up this kind of monstrous workload.)
The legacy trap
The second problem is less visible, but bigger in the long run. I call it the legacy trap.
If you set up seven projects at high speed without bringing them to a logical end point, you build up technical debt on seven fronts at once. Decisions you made early in project one, about structure, naming and setup, will soon be anchored in projects two to seven as well. If you find out later that something was not wise, you have to change it in all those places at the same time.
Claude Code can handle that in principle, because the tooling is powerful enough to refactor widely. The principle still holds that you should not be wasteful with your resources. It is like leaving the tap running all day because water is cheap anyway: the waste is not in the cost per drop but in the pattern you teach yourself.
A portfolio of starts
There is also something psychological going on that is worth naming.
The ideas he is now rolling out had been on the shelf for years. That is why the breakthrough felt so explosive. It was not a new insight but the falling away of a brake on something that had been lying there all along. That energy is understandable, after years of standstill you want everything at once. But why did everything have to happen now?
If something could wait for years, it can also wait until the previous project is done. The urgency is a feeling and not a fact. Anyone who starts everything at once and finishes nothing is not building a portfolio of products but a portfolio of starts, without solid content, without a demonstrable end result and without the learning effect that only comes when you take something through all the phases.
A quick MVP is not the same as done
He made a good point about the buckshot method and the fail-fast principle. With AI you finish an MVP so quickly, he said, that you have to adapt your product development strategy to it. Why still build Figma mock-ups when you can deliver the real thing as a PoC? That is true, and it is a real shift that AI-assisted development makes possible.
But an MVP is not an end point, it is a measuring instrument. It has value when you do something with it: test, collect feedback, take a decision. An MVP that is ready while the decision maker has not yet looked at it is a prototype without a feedback loop. Seven of those prototypes at once means waiting seven times instead of learning once.
What the previous lesson actually said
Look back at the first article in this series. The core was that expertise blocks, because experts see too much and do not dare to delegate enough to the AI.
The answer to that is not to put the expert aside and let someone without a brake build everything at once. The answer is to learn when you steer and when you let go, and to trust the AI without switching off your own judgement. That is a skill and not a state.
My colleague has thrown off the brake, and that is step one. Step two is learning to brake at the right moment, because that is how you get further.
Three phases, one lesson
Summing up the series so far, I see three recognisable phases in how people learn to handle AI-assisted development:
Phase one: the expert blocks. He sees too much, does not trust the AI and wants to check everything. That produces little output and a lot of frustration.
Phase two: the brake falls away. He discovers that letting go works and builds fast and wide. That produces a lot of movement and little completion.
Phase three: focused use. He learns to steer and decides what has to be finished, in which order and why. That produces output with depth and demonstrable value.
My colleague is in phase two, and that is fine, because phase two is better than phase one. But phase three is where it gets interesting, and I am curious to see when he gets there.
This is the third part in a series about experiences with AI-assisted development. Previously published: ‘Why the Best IT People Are the Worst at Vibe Coding’ and ‘You Can’t See What I’m Doing’.
Jan-Willem Rodenhuis is managing partner of Ductus B.V. and writes on miliarium.nl about the practice of AI adoption in organisations.