Building with AI

Vibe Coding: What It Actually Means to Build Software by Talking to It

By Sean Doherty · June 19, 2026

Last month I built a working booking prototype in an afternoon, in my kitchen, with a coffee going cold next to me. I did not write most of the code by hand. I described what I wanted, watched it appear, corrected it, described the next bit, and by the time the coffee was properly undrinkable I had something I could click through. Then I told a friend I had been "vibe coding" and he laughed at me, and honestly, fair enough. It is a slightly silly phrase. It also happens to describe something real.

So let me be the person who says the plain thing. Vibe coding means building software by telling an AI, in ordinary language, what you want it to do, and letting it write the code. That is the whole idea. You are not typing every semicolon. You are steering.

It is neither magic nor a toy

The hype runs in two directions and both are wrong.

On one side you have the people selling the dream that anyone can now build anything, that engineers are finished, that you just speak your app into existence. That is nonsense. On the other side you have the people who dismiss the whole thing as a party trick for folk who cannot code, something that produces throwaway rubbish and nothing more. Also nonsense.

I have spent 25 years leading digital work, and before that I was Toyota's first Kaizen engineer, from 1987 to 1997, where I learned that a process is only as good as your honesty about where it fails. I am not a career software engineer by training. I am a strategist and a designer. And yet I ship production software now by working conversationally with AI tools, because I have done it enough times to know the difference between a demo and a thing that survives contact with real users.

Vibe coding is a real practice. It is just not the practice the loudest voices describe.

The afternoon prototype

Back to that booking tool. A few years ago, building a clickable prototype that actually ran, with real data flowing through it, would have meant either learning a framework properly or hiring someone or spending a fortnight fighting configuration files. Instead I opened a chat, said what I wanted in three or four sentences, and started iterating.

Here is the honest part. The first version was wrong in ways I could see immediately, because I know what good looks like. The layout was clumsy. It stored data somewhere daft. But the loop was fast. I could say "no, put the confirmation step before the payment, and stop trusting the user to type the date correctly," and a moment later it had changed. What used to be a two-week job to even test an idea was now an afternoon.

That speed is not a gimmick. When you can build the thing instead of arguing about the thing in a meeting, you learn faster. I have run 15 or more enterprise AI proofs of concept as Head of Digital UX and AI Innovation at Coforge, and the ones that mattered were the ones we could actually stand up and poke, not the ones that lived in a slide deck. Vibe coding collapses the distance between an idea and something you can touch.

Where it genuinely shines

I want to be specific here, because vague praise helps no one.

• Prototypes and proofs of concept. When the goal is to learn whether an idea is any good, describing it into existence is the fastest route I have ever used. You throw most of it away, and that is the point.
• Glue code and the boring plumbing. The connectors, the scripts, the little tool that reshapes one file format into another. Tedious to write by hand, quick to describe, easy to check because you can just run it and look.
• Moving fast on things that do not yet need to be perfect. Internal tools. One-off automations. The rough draft of a feature you will harden later.
• Non-engineers building real things. This is the one that genuinely moves me. People who have the domain knowledge but never had the coding fluency can now build. A vet, an accountant, a small firm owner who knows exactly what their process needs. I built SoloBusinessAI, FloraLoop, and Cura Mirai partly to serve exactly those people. The barrier that kept good ideas trapped in the heads of non-coders is lower than it has ever been.

If all you took from this piece was "use it for prototypes and plumbing," you would already be ahead of most people.

Where it quietly bites you

Now the part the cheerleaders skip. This is where I earn my keep, because I have been bitten, and I would rather you learned from my bruises.

The confident wrong turn

The AI is never unsure. It will hand you a wrong answer with exactly the same calm certainty it hands you a right one. There is no wobble in its voice, no "I think this might be it." So when it goes down a bad path, it goes fully, and it will happily build three more things on top of the mistake before you notice. You have to supply the doubt yourself.

Debugging what you did not write

When you hand-write code, you carry a map of it in your head. When you describe it and something else writes it, that map is thin. So when it breaks at eleven at night, you are debugging a codebase you did not author and only half understand. This is real, and it is the tax nobody mentions. Reading the code the AI produced is not optional homework. It is the job.

Security and the edges

The happy path is easy. The AI will cheerfully build you something that works when everyone behaves. It is the edges that hurt. The malformed input, the user who does something daft, the field left blank, the person actively trying to break in. Left to its own devices, the AI does not think like an attacker and does not obsess over the awkward cases. You have to. My work on Cura Mirai, which is patent-pending AI governance, exists precisely because "it worked in the demo" is where a lot of AI projects quietly go to die.

The illusion of understanding

This is the subtle one. Because the software runs, and because you described it, you feel like you understand it. Sometimes you do not. You understand what you asked for, not what was actually built. Those are different things, and the gap between them is where the nasty surprises live.

The discipline it still demands

Here is my slightly contrarian conclusion, though I promised not to use that phrase, so call it my closing opinion.

Vibe coding does not remove the need for expertise. It relocates it. It stops mattering whether you can remember the exact syntax, and it starts mattering enormously whether you know what good looks like. Whether you can smell a bad design decision. Whether you know that this thing needs to handle a blank field and that thing needs to never trust the browser.

You still have to know what good looks like. And someone accountable still has to read the code.

That second part is not negotiable. Describing software into existence is a genuine skill and a genuine accelerant. It is not a licence to ship code no human has read. Somebody with judgement, somebody who will own it when it breaks, has to look at what was built and decide it is fit to go out. The AI does not carry accountability. You do.

So yes, I vibe code. I still think the name is a bit daft. But I have shipped real products this way, products people use, and I would not go back to the old pace. The trick is to hold two thoughts at once. This changes what one person can build, genuinely and permanently. And it demands more judgement, not less, from whoever is steering. Take the speed. Keep the discipline. Read the code.