Vibe coding, with and without knowing what you’re doing

“Vibe coding” started as a joke and became a job description. You describe what you want, an AI model writes the code, you run it, and if it looks right you move on. For a prototype on a Sunday afternoon, that’s wonderful. For a site a business runs on, it depends entirely on one thing: whether the person steering can tell good output from bad.

The tools are the same for everyone. The results aren’t.

Two people, one prompt

Picture two people asking for the same thing: a contact form with a phone field, validation and a success message.

The first gets a form that works. It submits, it shows the message, it looks fine in the browser they tested it in. They ship it.

The second gets the same form — and then reads it. The labels aren’t tied to their inputs, so a screen reader announces “edit text” with no name. The error message appears in red and nowhere else. The phone field rejects numbers with a country code. Nothing is sent server-side if JavaScript fails. The success message isn’t announced to anyone who can’t see it. They fix five things in ten minutes, because they knew to look.

Both people “used AI”. Only one of them shipped a form that works for everyone who fills it in.

What the model is good at

Being honest about this matters, because the hype and the backlash are both unhelpful.

A good model is genuinely fast at the parts of the job that are repetitive and well understood: scaffolding a component, writing the boring half of a function, converting data from one shape to another, drafting tests, suggesting edge cases I hadn’t listed. It’s also a patient second pair of eyes — ask it to review a function for accessibility or performance problems and it will often catch something.

Used like that, it saves me real time. I use it every week.

What it doesn’t know

It doesn’t know your project. It doesn’t know that this client’s editors will paste text from Word, that the site has to work on a mid-range Android phone on a train, that the checkout has a tax rule nobody wrote down, or that the design system already has a component for this.

It doesn’t know when it’s wrong. A model will produce confident, well-formatted code that uses an API that doesn’t exist, handles the happy path beautifully and falls over on the second click. It reads like expertise. That’s the trap.

And it doesn’t carry responsibility. When the form loses leads or the page fails an accessibility audit, “the AI wrote it” isn’t an answer a client can do anything with.

The difference is judgement, not typing speed

For most of the history of this job, experience showed up as speed: seniors typed less and got there sooner. AI flattens that. Everyone can generate a component in thirty seconds now.

What it doesn’t flatten is judgement:

• Knowing what to ask for. “Build a modal” gets you a div on top of the page. “Build a dialog that traps focus, closes on Escape, returns focus to the trigger and doesn’t scroll the page behind it” gets you something usable. You can only write the second prompt if you know why each part matters.
• Knowing what to check. Reading generated code with a list in your head — semantics, keyboard, states, errors, performance, security — is the actual work now.
• Knowing when to say no. Sometimes the best answer is less code, an existing plugin, or no feature at all. A model will happily build whatever you ask for.
• Knowing how it fits. Code that works in isolation can still be wrong for the codebase: a second way of doing something the project already does, a dependency nobody needed, a pattern the next developer won’t recognise.

That’s why I describe my own use of AI as faster hands, same judgement. It drafts; I decide. Every line is read before it ships.

If you’re hiring

If you’re commissioning a site, it’s fair to ask how AI is used in the work. There’s nothing wrong with the answer “a lot” — as long as the next part of the answer is about review: who reads the code, what it’s tested against, and who is accountable when something breaks.

Cheap and fast has always been available. What you’re paying for is someone who can tell whether the result is any good.

If you’re learning

Use the tools — they’re extraordinary teachers if you ask why, not just what. But don’t skip the fundamentals because the model can write them for you. HTML semantics, CSS layout, how forms really work, how a browser loads a page: these are exactly the things you need to know to spot what the model got wrong.

The people who get the most out of AI are the ones who could have written the code themselves. That’s not an argument against using it. It’s the best argument for learning the craft properly.