Vibe Coding Is a Mirror for How Clearly You Think

The more I use AI coding tools, the less I think of them as magic.

They feel more like a mirror.

When I am clear about the problem, the output can be surprisingly good. When I am fuzzy, the AI usually gives me a polished version of my confusion.

The friction

It is easy to blame the model when generated code misses the point.

Sometimes the model really does make a bad decision. But a lot of the time, I notice something uncomfortable first: I never properly decided what I wanted.

I asked for “a better architecture” without defining the constraints. I asked it to “clean this up” without saying what must not change. I mixed three goals into one prompt and then acted surprised when the result mixed them too.

What I tried

Before asking the AI to write much code, I now try to make four things explicit:

• Problem: What exactly is broken, slow, repetitive or missing?
• Context: What does the existing system already do?
• Constraints: What cannot change?
• Done: What would make me accept the result?

This is not really a prompting trick. It is basic engineering thinking that AI makes impossible to avoid.

What actually happened

The biggest improvement was not that the prompts became longer. They often became shorter.

Once I had decided what mattered, I could remove a lot of vague instruction.

There is another benefit: reviewing the output becomes easier. If I know the definition of done, I can judge the code instead of being impressed by it.

What I changed

I treat AI-generated code as an implementation proposal, not an answer.

I still have to decide the boundaries, test the behaviour, spot hidden complexity and understand what I am accepting into the codebase.

In fact, AI makes senior engineering judgment more valuable, not less. Generating code is cheaper. Knowing which code should exist is still the hard part.

What I kept

I kept the speed.

I like being able to turn an idea into something runnable quickly. That encourages experiments I might otherwise never start.

But I do not want the speed to hide bad thinking.

Steal this if it helps

Before your next coding prompt, write four lines:

1. The problem is…
2. The relevant context is…
3. Do not change…
4. I will consider this done when…

If those lines are hard to write, that may be the real work.