The Dunning-Kruger effect is the finding that the less you know about something, the more likely you are to overrate your ability at it. The reason is neat and slightly cruel: the knowledge you would need to recognise your own mistakes is the same knowledge you are missing. You are not ignoring the evidence of your incompetence. You genuinely cannot see it.

Vibe coding is where that plays out fastest. You describe what you want, you accept what comes back, and you keep going for as long as it looks right. No pause to understand what was produced, no test to see whether it holds, just momentum.

And it works. That is the part people miss when they sneer at it. It works right up until it does not — and it fails in three predictable ways.

Trap one: speed feels like skill

At first, vibe coding is intoxicating. You produce working-looking software faster than you ever have, with almost no grasp of how it actually works, and the obvious conclusion is that you have become extraordinarily good at this. Something that used to take a team a fortnight took you an afternoon. Of course that feels like talent.

Confidence is at its highest exactly where competence is at its lowest. The output is fast and plausible, and plausible is the problem — there is nothing in it that gives you reason to suspect anything is missing. A compiler error tells you that you were wrong. Code that runs and demos beautifully tells you nothing at all.

So nobody stops to ask the three questions that actually decide whether this ends well.

Should we build this at all? Can we actually build it? Do we have the skills to build it correctly, to run it, to secure it, and to fix it when it breaks?

Those questions are cheap to answer at the start and ruinous to answer at the end. They are also the first casualties of a good run.

Trap two: the model never applies the brakes

A model is confident by default. It does not hedge in proportion to how likely it is to be wrong. It hands you a flawed answer with exactly the same certainty as a correct one, in the same fluent, authoritative prose, and it will keep doing that for as long as you keep asking.

For someone already convinced they are on a roll, that is the worst possible input. Two sources of overconfidence — the tool’s and your own — reinforce each other, and neither one pauses. The friction that would normally make you check, the small flicker of doubt that says look at this again, is gone. The model removed it, and it felt like progress.

The model will never raise the three questions either. It was not built to. It is built to generate. Ask it for a payment flow and it will give you a payment flow; it will not ask whether you have thought about chargebacks, or whether you are the right person to be handling card data at all. Nothing in the loop is pointing at the gap, because everything in the loop is pointed at the next output.

Trap three: the bill arrives late

The feedback loop rewards the wrong thing. Confidence produces output, output looks like success, and success reinforces confidence — all of it happening well before the cost of the missing understanding comes due.

Then it comes due. The thing that demoed beautifully falls over under real load. A security hole you never considered gets found, by someone who was looking. A change in one place breaks three others, because nothing was structured to prevent that. And the code turns out to be not just unmaintainable but unexaminable — you cannot fix it, because you never understood it well enough to know where to start.

Here is the thing worth sitting with: every one of those problems existed on day one. None of them appeared later. They were baked in at the moment the code was written, and they stayed invisible because nothing in the loop was ever going to surface them. The bill was always coming. It just arrived after you had built the whole business on top of the thing.

The way out

It is not to abandon AI. It is also not to go and become a software engineer. People reach for one of those two answers, and both are wrong — one throws away a genuine multiplier, the other throws away the reason you picked up the multiplier in the first place.

What actually works is unglamorous.

Understand the tools you are using

Know what the model is doing when it generates code. Know what it is good at, where it fails, and why it fails there — because the failure modes are not random, and once you can predict them you can watch for them. Know your stack well enough to read what comes back and tell whether it fits.

Plan before you prompt

Decide what you are building and why, and answer the three questions while changing your mind is still cheap. A plan is not bureaucracy. It is the only artefact that tells you whether the thing the model just produced is the thing you actually wanted.

Give the model context on purpose

Your architecture, your conventions, your data model, your constraints. This is the one that changes everything, and I have written about it at length. The early wins you had were not skill and they were not magic — they were context you happened to supply by accident, in a small enough problem that everything the model needed fitted in one prompt. Supply that context deliberately and the wins repeat at real scale. Fail to, and you get slop.

Have enough skill to judge the output

Not to write it yourself. To read it, test it, try to break it, and recognise when it is wrong. That is a much lower bar than becoming an engineer, and it is the bar that actually separates the people who ship from the people who demo.

Then focus on the problem

Describe what you want clearly and stop short of dictating how to do it. If you specify the implementation, you have locked in every flaw in your own guess — you have used a tool that knows more than you do about the solution space and constrained it to your imagination. State the problem, state the constraints, and let it produce something better than what you had in mind.

None of this is complicated. It is just slower than vibing.

It is also the entire difference between something that works in the demo and something that works in production.

Nigel Price is the founder of Digital Discovery Group, specialising in ecommerce strategy, digital transformation, AI-powered platforms, and managed cybersecurity services for small and medium businesses.