Vibe Coding: What It Actually Takes to Ship Something Real

Vibe coding means describing what you want in plain language and letting an AI model write the code, then judging the result by whether it works rather than by reading every line. It is real, and I shipped a live production e-commerce site that way. It also breaks in specific, predictable places, and knowing where those places are is the actual skill.

What is vibe coding, exactly?

Andrej Karpathy named the practice in early 2025, and the label stuck because it describes a posture rather than a tool. You stay at the level of intent. You say what the software should do, you look at what comes back, and you review behavior instead of diffs. Nothing in that requires a particular editor or a particular model.

The definition is not the hard part. The hard part is the word "correctly." Accepting output because it behaves correctly is a reasonable trade when the cost of being wrong is a broken demo. It is not a reasonable trade when the cost of being wrong is a customer seeing the wrong price. A lot of the writing about vibe coding comes from someone who built a weekend project, and a weekend project never has to survive a Tuesday.

What vibe coding actually got me

It got me DAD LINK, a live B2B e-commerce site for network infrastructure and cabling equipment in Iraq. I designed it and shipped it on Odoo with Claude Code doing most of the build work: catalog structure, category pages, storefront layout, on-page SEO, and the content. It is a real store that is online now, not a portfolio mockup. That upside is large and I am not going to pretend otherwise.

Where AI coding tools genuinely earn their keep:

• First versions. Something you can look at and react to beats a blank file. Reacting is easier than specifying.
• Conventions you do not know yet. A framework you have touched twice becomes usable in an afternoon.
• Boilerplate and refactors. Anything with a clear before and after.
• The work you would otherwise skip. Tests, error handling, logging, comments. The model does not get bored.

None of that is small. The reason I am writing a reality check is not that vibe coding failed me. It is that it worked, and the parts that worked were not the parts people talk about.

Where does vibe coding break down?

In four places, and none of them are the model being bad at code. Requirements you never wrote down. Output that is wrong but looks right. Integration edges, where the real system does not match what the model assumed. And the point where you can no longer tell whether the code in front of you is correct. All four are on you, not the tool.

Requirements you never wrote down. A coding AI fills gaps with something plausible, and it fills them instantly, which means you often do not notice a gap existed. The gaps that matter are usually not technical ones. Any storefront has to decide how the person it sells to actually searches, what a buyer needs to see before asking for a quote, and which product attributes are worth filtering on. No model knows that. It is not in the training data. It is in the market you are selling to.

Output that is wrong and silent. Code that crashes is cheap. Code that runs, returns a number, and returns the wrong number is expensive, because nobody finds it until the number is somewhere that matters. This is the same failure mode I design around in automation, which is why I build human review gates into AI automation instead of trusting output on sight. The rule carries over: a plausible-looking result is unverified until you verify it.

Integration edges. The model is strong on general patterns and weak on your specific system. Odoo has its own conventions, and a model's general web knowledge does not always line up with them. An API documents one response shape and returns another. Auth behaves differently in production than it did in a test call. Each of these is a point where "it worked when I asked for it" quietly stops being true, and none of them show up in a tutorial.

Can you vibe code if you cannot read code?

Not for anything other people depend on. You do not need to write it from memory. You do need to open a function and say whether it does what the description claims it does. That is the floor. Below it you are not making engineering decisions, you are approving text you do not understand, and these tools are very good at making that text look reassuring.

Reading code is far cheaper to learn than writing it, and it is the highest-return skill in this whole practice. The specific things worth being able to spot:

• Input that gets trusted without validation.
• An error that is caught and then swallowed, so the failure never surfaces.
• A fallback that hides a problem instead of reporting it.
• Hardcoded values that only work against the test data.
• Logic that is correct today and wrong the first time an input is weird.

Every one of those is something a model will write without hesitating, and every one of those is something a review catches in under a minute.

Vibe coding is one layer out of four

Prompt, context, harness, loop. Vibe coding as most people practice it is the first layer only: phrasing the request well. What makes output survive production sits in the other three, which are what the model can see, what it is allowed to do, and how its work gets checked before anyone trusts it. That is the difference between a fast demo and a site that stays up.

On a long build, most of my effort goes into context and harness. Keeping decisions written down somewhere the model will actually re-read them. Making each pass verifiable before another pass gets stacked on top of it. Prompting is the part that takes five minutes. I broke this down properly in the four layers of working with AI, and it is the framework I would hand anyone about to start a serious build this way.

So should you vibe code?

Yes, if you can review what comes back. It is the fastest route I know from an idea to something running, and refusing to use it is not a principled position, it is just slower. The people it fails are the ones who cannot tell the difference between a working system and a system that has not broken yet.

That distinction is the whole job now. The typing has been automated. The judgment has not, and it is judgment about your business, your data, and your users, none of which the model has access to. I did not come to this through a computer science program either, and I wrote about shipping real software without a CS degree separately, because the two questions get confused constantly. Not having a CS degree is not the obstacle. Not being able to check the work is.

If you are building something real

Vibe coding will get you to a working first version faster than anything else available. Getting from there to something a business actually runs on takes requirements you wrote down, validation you built on purpose, and someone who can read the output and say no. If you have something in that second category, send me the details from my contact page and I will tell you straight whether it is worth doing this way.