Vibe coding is genuinely impressive until it isn't. You describe what you want, the AI produces something, and then you spend the next hour trying to explain what you actually meant. The tool didn't fail. The idea wasn't ready.
There's a version of this that works well: you have a sharp, specific concept, you know the constraints, and you can describe what success looks like. The AI fills in the implementation. That's a reasonable way to prototype.
The version that doesn't work: you have a rough feeling that something should exist, you type it into a prompt, and you're surprised when the output is rough too. AI reflects your thinking back at you. If the thinking is vague, so is the output.
The real skill is upstream of the prompt
Precision, clarity, and context — that's what separates a prototype that demonstrates something real from one that demonstrates that you had a vague idea. Before you open any AI coding tool, write the idea down in plain language. Describe the user, the problem they have, and exactly what the software does to address it. If you can't write that clearly, the AI definitely can't infer it.
This isn't a new problem. It's what requirements documents were invented for. The format has changed, but the underlying discipline hasn't.
Code was never the hard part
Even if AI could write flawless code from a perfect prompt, building real software involves a lot more than code:
- Infrastructure — where does it run, how is it deployed, what happens when demand spikes?
- Security — who has access to what, how is data stored, what are the attack surfaces?
- Scalability — what was designed for a hundred users and will crack under ten thousand?
- User experience — does the thing you built match how real people think and behave?
- Edge cases — the ones nobody thought of until 2am when something breaks in production
AI doesn't handle these by default. Neither does a developer who's only thinking about the happy path. These are the things that get dealt with by people who've launched real products and watched what actually goes wrong.
What to do before you build anything
Write the idea down — not the feature list, the actual idea. What problem does this solve? Who has that problem? Why don't existing solutions handle it?
Then pressure-test it. Ask yourself what would have to be true for this to work. Identify the assumptions. Find the weakest one and stress-test it before you've written a line of code or burned a single prompt.
Then talk to someone who's done this before. Not to hand the idea over, but to get a second perspective from somebody who knows which assumptions usually turn out to be wrong.
AI is useful. It isn't a substitute for clear thinking
We use AI tools in our own work — for automation, for agentic workflows, for accelerating the parts of development where intelligence helps. But we've also seen what happens when a project starts from a fuzzy brief: the first build gets thrown out, the second is a partial fix, and the third is what was actually needed from the beginning.
The prompt is not where the real work happens. The thinking before it is.
If you've got an idea you've been sitting on, get in touch. One conversation is usually enough to work out whether it's ready to build — and what needs to be clearer before it is.
