Vibe Coding, AI, and the People Who Actually Care
My feed is full of the same jokes.
Vibe coding: 100,000x faster. Vibe debugging: 1x? 2x?
Shipped in 20 minutes. Still fixing it three weeks later.
I have been in tech for more than 25 years. I never learned programming. I was always the annoying guy asking, “Why is this not shipped yet?”
For decades I worked with developers. Some were excellent. Some were careless. Many were somewhere in the middle. And yes, I often struggled with inattentiveness and low ownership. Specs half read. Edge cases ignored. Debugging treated like a chore.
Now the same crowd screams that vibe coding produces garbage code. That AI cannot debug. That junior developers will destroy everything. That the last 1 percent takes forever.
Let’s be honest.
The last 1 percent always took forever.
The Classic Complaints About Vibe Coding
Here is what people usually say:
• AI writes messy, unstructured code
• It does not understand architecture
• It hallucinates APIs
• It ignores edge cases
• Debugging takes longer than writing
• Tech debt will explode
• Security will suffer
This is true, AI models do hallucinate. AI speeds up output, it does not guarantee correctness.
But here is the part nobody wants to say out loud.
If a developer did not care about the product before AI, giving them AI will not suddenly make them care. It will just amplify whatever was already there.
Before, they at least had to read the first sentence of the specification. Now they can paste the whole thing into a prompt and move on. If they had weak understanding before, now the gap is hidden behind fast output.
That is not an AI problem. That is a human problem.
Debugging Was Always a Nightmare
People talk about vibe debugging like it is a new disaster.
Debugging has always been painful. Anyone who has shipped real software knows this. Some bugs are trivial. Some take hours. Some take days. Some only appear in production under weird conditions that nobody predicted.
Nothing new here.
When you deeply understand your product, debugging becomes directional. You know where to look. You know what part of the logic is sensitive. You can tell the AI, “Check the payment webhook handler,” instead of asking it to magically fix everything.
If you do not understand your product, debugging is chaos, with or without AI.
What Changed For Me
Here is what changed.
I started building software myself.
Not toy projects. Real software. With users. With payments. With data. With consequences.
Last year I built a full CRM for my service business in one weekend. Not 20 minutes. More than 20 hours. I started Friday evening. On Monday we were using it in real operations. We imported our existing spreadsheet data. We processed jobs. We tracked payments.
Was it perfect? No.
It took another three or four weekends to refine it. To fix edge cases. To polish flows. To make it stable. We have been using it for almost a year now.
At the same time, we were evaluating ready solutions. The best offer was three weeks to implement. No data import included. And the cost was not small. I am not even focusing on money here. Just time.
For me it was not 100,000x faster.
It was from zero to one.
Before AI, I would not even attempt this. I would need a developer. Budget. Sprint planning. Delays. Pain. Negotiation.
Now I can move.
From Founder to Builder
For 25 years I translated ideas into tickets. Now I translate ideas directly into working systems.
This does not mean I replaced engineers. Good engineers are still gold. Architecture matters. Security matters. Scalability matters.
But internal tools? Operational systems? MVPs? Automation?
The barrier collapsed.
AI can increase developer productivity by 20 to 45 percent in certain tasks like code generation and documentation. In my case, the impact was binary. It was not 30 percent faster. It was possible versus impossible.
That is the real shift.
Why Some Teams Get Worse With AI
If a team does not care about the product, AI will make it worse.
If developers treat tickets as chores, they will now generate more code with less understanding.
If nobody owns outcomes, only output, you will get faster garbage.
AI amplifies intent.
Strong ownership plus AI equals leverage.
Weak ownership plus AI equals noise.
That is why some people experience vibe coding as magic and others as disaster.
The 99 Percent Problem
The meme about being stuck at 99 percent is funny because it is true.
The last 1 percent is thinking. Not typing.
AI automates typing. It does not automate understanding your business model, your users, your edge cases, your constraints.
In my CRM weekend, the hard part was not generating forms or database tables. The hard part was defining exactly how jobs flow through the system. What happens if a client cancels. How and when statuses change.
That is product thinking.
AI did not replace that. It executed it.
Vibe coding and “Real Code”
People say, “Real systems are not vibe coded.”
Are you sure?
Many serious companies now use AI tools in daily development. The code does not magically become fake because AI helped write it. What matters is review, testing, ownership.
The quality bar has always depended on the people maintaining the system.
The Real Divide
The divide is not between real engineers and vibe coders.
The divide is between:
• People who understand the problem and care about the outcome
• People who just execute tasks
AI gives superpowers to the first group. It exposes the second.
For me, vibe coding is not about speed memes. It is about agency. I can build what my business needs without waiting for someone else to prioritize it.
It is exciting. It is empowering. It is messy sometimes. But it is real.
Nobody Banned Mediocrity
Let me say this very simply.
Nobody banned mediocrity.
AI did not create it. It was always there.
Years ago, many accountants said computers would never replace paper. They said real bookkeeping must stay on paper. That serious work cannot happen on a screen.
The tool changed. The standard did not disappear. The market rewarded those who adapted and left the rest behind.
It is the same now.
Some developers will use AI to produce weak systems faster. Some founders will ship half-baked products and blame the tool. Some teams will pile up messy code.
That is not new.
AI lowers the entry barrier. It does not lower the bar for quality. If anything, the bar is higher now. Because speed is no longer the excuse.
If you understand your product and care about the result, AI is leverage.
If you do not, it will only expose it.


In my experience, the missing bit here is how good your spec is. If you get that right ahead of starting to code with AI, then the results are spectacular. I can't program either, or not at the level the AI programs for me, but I've got very good at the next couple of layers of abstraction upwards.
My bash is now excellent, which allows me to query the AI code, and my domain-driven design has got very advanced indeed. So I think the real innovation has been for the human to be the architect at a higher vantage point and the AI to be the programmer with specific and defined parameters. Additionally, I always run a secondary project which is the Q&A level, so testing is built in.