Vibe Coding vs Spec Driven Development

I Keep Getting These Projects

A client sends me a repo and says they already built most of it with AI. Login works. The form submits. They vibe coded it over a few nights and they want a developer to take it live.

Then I open the files.

Within an hour I am not reviewing a product. I am reverse engineering a chat history that got saved as code. Nobody can tell me why checkout is split across three files. Nobody can tell me who is allowed to see which records. The person who built it cannot walk me through a single function, because they never wrote one.

I have spent 20 years building digital systems for clients across Australia and the United States. I use AI every day. I am not against vibe coding as a way to explore. I am against people with no software background treating it as the build process.

If you cannot read the code, you cannot validate it. The model did its job. You did not do yours.

Vibe Coding Feels Like Progress. Spec Driven Work Is Progress.

Vibe coding is what most people are doing in 2026. You prompt. You click around. It looks right, so you prompt again. The demo is the brief. There is no written list of what must work, what must never happen, and how you will know it is done.

Spec driven development is the opposite order. You write the outcomes first, in language you can actually check. Users can book. The form lands in the CRM. A failed payment shows a clear message and does not charge twice. Then a developer, using AI, builds against that list.

I already wrote about this from the handover side. Clients send me generated folders and call it a head start. It is not. If you cannot read it, you cannot approve it. Spec driven work gives you something you can approve before anyone spends a week in the wrong direction.

Both approaches use AI. One of them leaves a paper trail you can argue with. The other leaves a demo and a lot of confidence.

The Problem Is Not the Model

I use the same models these clients use. The output is fast. It looks professional. That is exactly why this keeps happening.

A few months ago I reviewed a system written entirely by AI. The person who built it had no technical background. The person who set the requirements did not either. The plan was to save money and bring a software engineer in at the end.

Two hours in, I knew we were not patching our way out. The stack was wrong for the load. The core flow did not match what the business thought it had asked for. We rebuilt it.

That was not the model being uniquely bad that day. The model filled every gap in a vague prompt with a confident default. Nobody in the room could see which defaults were dangerous. So they shipped them.

When vibe coded work fails, I almost never blame the tool. I blame the fact that the person driving it could not tell good output from garbage.

Ten Things I Keep Finding in Vibe Coded Projects

This is not a theory list. This is what shows up when I open the repo.

1. Nobody can validate the code

The builder clicks through the happy path and calls it review. I ask what happens if the same user submits twice. Silence. If you cannot read the files, you are approving a screenshot, not a system.

2. Security is assumed because login worked once

I keep finding secrets sitting where a browser can read them, forms that accept anything, and access rules that look closed and are not. The builder saw a login screen. I saw an open door. You will not notice that if you have never reviewed authentication.

3. The stack was chosen because it sounded modern

Same story as that rebuild. AI picked a popular default. Nobody asked whether it fit the traffic, the hosting, or the CRM they already pay for. I find that out after they want to go live, when changing stack means starting over.

4. The demo works. The real path does not.

Declined cards. Duplicate bookings. A refresh mid checkout. A staff account that needs access the owner never mentioned. Vibe coding rewards the first click that worked. I find the broken paths when a real customer hits them, or when I test like one.

5. There are tests, and they prove nothing

AI will write a test file. I have opened plenty that never run in the deploy environment, or that pass for the wrong reason. A green check mark feels like engineering. If you cannot tell a useful test from a decorative one, it is just decoration.

6. Customer data is handled in ways the owner never agreed to

Emails, lead lists, sometimes payment details, sitting in the wrong place or sent to a service nobody named. I would not sign that off in a contract. The owner signed it off anyway, because it was buried in code they cannot read.

7. When it breaks, they cannot fix it

Friday night, form stops sending. The person who vibe coded it is back in the chat asking the model to guess. There is no structure, no owner, no way to change one thing without breaking three others. When I walk in later, I am doing archaeology, not a quick fix.

8. The polish quote turns into a rebuild invoice

They hire me to "just take it live." Then I have to say the foundation is not valid. They already spent weeks prompting. Now they pay again for the version that should have been built first. I have had that conversation enough times that I can write it from memory.

9. They want production, with production risk, and no one accountable

Payments. Personal data. Client work that has to stay up. "It worked on my machine" does not help after a complaint or a leaked list. I will not put my name on a system I cannot stand behind. If you vibe coded it and cannot read it, you also cannot stand behind it. You just have not been asked to yet.

10. It looks finished, so they push it live

This is the same pattern I see with AI generated design. The screen looks like a product, so the work feels done. They connect a domain and wait. I would rather tell you in week one that this is a prototype than watch it fail after real users are on it.

What I Ask For Instead

You do not need a fifty page spec. You need a page you can sit with for twenty minutes and mark up.

Write down, in your own words:

• Who uses this and what they are trying to finish
• What must work on day one, as outcomes, not feature names
• What happens when something fails
• What is out of scope, so the model does not invent it
• How you will know it is done, in checks you can do yourself

That is spec driven development in the form a business owner can actually run. I take that list, I use AI, and I reject output that misses a rule. You stay in the job you can do: confirm the outcomes. I stay in the job you hired: validate the code.

If you already vibe coded a prototype, keep it. I will look at it. I will still ask for the written version first, because that is the only version you can check before I start spending your budget.

Use Vibe Coding to Think. Do Not Use It to Ship.

Sketch a flow. Learn what a form might look like. Throw it away when you are done. That is a good use of the tools.

Do not use it as the production process if you have no software background. Do not use it for logins, payments, or anything a client will depend on next month. You will not catch the mistakes, and you will call that speed.

AI makes me faster because I can see when it is wrong. It will not do that for you if you skipped the craft.

If you want to get into vibe coding because it looks like a way around learning development, stop. The model will give you code. It will not give you the ability to know whether that code is safe.

Bring me the outcomes, or bring me the repo and be ready to hear that we are starting from the spec. I would rather have that conversation early than quote you a rebuild after you already fell in love with the demo.