What “vibe coding” actually changed in how I ship

Everyone has an opinion about “vibe coding” now, and most of them miss the point. It's not about writing less code or thinking less. It's about collapsing the distance between an idea and a working version you can actually poke at.

For me the change was psychological before it was technical. When the cost of trying something drops near zero, you try more things. You stop pre-optimising for a plan and start steering against something real.

The win isn't speed. It's momentum — the gap between “what if” and “here, look” basically disappears.

The loop that stuck

After a lot of false starts, the workflow settled into something boring and repeatable. Sketch the shape, generate a first pass, then spend my real attention on the 20% that matters: the data model, the edge cases, the parts a model can't taste-test for me.

// the part I still own: the decisions
const ship = async (idea) => {
  const draft  = generate(idea);   // cheap, fast, disposable
  const shaped = review(draft, {
    dataModel: 'mine',
    edgeCases: 'mine',
    vibes:     'the machine',
  });
  return deploy(shaped);
};

The trap is letting the model own the decisions instead of the typing. The moment you stop reading what comes back, you're not coding — you're gambling. So I treat generated code like a pull request from a fast, eager junior: useful, frequent, and never merged without a read.

Where it still bites

It's worst exactly where software is always worst: at the seams. Naming, state that lives in three places, the assumption nobody wrote down. AI happily produces confident code over a shaky foundation. The skill that matters more than ever is knowing what good looks like — because now you have to recognise it, not just type it.