The vibe coding debate is asking the wrong question.
There's a post doing the rounds on this very blog: The Vibe Coding Trap: Why Founders Are Building Faster and Understanding Less. It's a good piece. It's also half the story, and I'm the other half.
I've spent 22 years in commercial and operational roles. Phones4U on the shop floor. BlackBerry running channel sales. VP at Inmarsat, a FTSE 100 business, where my job was numbers and people, not code. CEO of an AIM-listed SaaS company before this one. At no point in any of that was I a proper engineer (don't tell them, but I always wanted to be). I couldn't have told you the difference between a merge conflict and a parking ticket.
In one six-month stretch I wrote over 1.5 million lines of production code. On my own. For five live products that real, paying customers use right now. There's been a lot more since then and my transition to using Claude Code.
So when people ask me whether AI-assisted building makes founders dumber, my honest answer is: only if you let it. The tool isn't the issues, the absence of discipline is the issue. And discipline is the one thing 22 years of operating actually taught me.
Let me explain what I mean, because this is the bit that I don't think enough people talk about.
The problem is a real one, but it's not new
"Building faster and understanding less" didn't arrive with AI. I've watched it happen for two decades (hellooo IoT).
I've sat in board meetings where a leader presented a number they couldn't defend, because someone in finance built the model and they just read the summary slide. I've seen product launches fail because the founder outsourced the entire build and never once asked why it worked the way it did. The pattern is ancient: someone produces output they don't own, and the gap between what they have and what they understand quietly widens until it breaks.
AI just made that gap cheaper and faster to create. That's all it is, the mistake isn't the speed. The mistake is treating the thing you built as finished the moment it runs.
What can keep you honest
When I started building ReflowAI's products, I had a choice. I could let the AI hand me code I didn't read, ship it, and keep my fingers, toes, legs and anything else crossed. Or I could treat every single thing it produced the way I'd treat a report from a direct report I respect but don't blindly trust.
I chose the second. Here's what that looks like in practice. None of it is technical. All of it is operational.
I never ship anything I can't explain to a customer. If a feature breaks at 9pm on a Friday, I'm the one fixing it, as there is no engineering team to hide behind (I've even installed Terminus and a VPS onto my mobile so I'm never caught short, but that's a story for another time). That single fact forces my continual understanding. You learn what you have to fix at 9pm. Make that your rule and the trap closes on its own.
I make the AI show its working. I don't ask for code. I ask why this approach over that one. I make it argue with itself. The understanding lives in the conversation, not the output. Founders who only prompt for results are the ones building faster and learning nothing. Founders who interrogate are getting a private tutor for the price of a subscription (or actually MANY private tutors, on any subject matter you care to learn).
I build the same way I'd run a team, small, reviewable pieces, clear ownership. Then test it before it goes ANYWHERE near a customer. Write down why decisions were made so future-me isn't a stranger. This isn't software practice. It's just good management applied to a codebase. Turns out the codebase doesn't care that I learned it running sales teams.
I stay close to the customer, not the code. My first paying customer for our newest product went live a few weeks ago. Every line I wrote was answering a question they actually had. Vibe coding goes wrong when the building becomes the point. The building is never the point. The customer and their SOW is the point.
Why your experience is the asset, not the obstacle
Here's the part I most want a mid-career operator to hear, because I needed someone to tell me.
You think your lack of a computer science degree disqualifies you from building. It's the exact opposite. The hard part of building a real product was never the syntax. AI handles the syntax now. The hard part is judgement. Knowing what to build. Knowing what "good enough to ship" means versus what needs to be right. Knowing when a customer is telling you the real problem versus the symptom. Knowing how to sequence work when everything feels urgent.
Twenty-two years of operating is that judgement. The years you thought were taking you away from building were quietly preparing you for the exact moment when the technical barrier dropped away and only the judgement was left.
I'm not special (though my Mum would disagree). I'm just early. The barrier that stopped commercially-minded people from building their own products has gone, and most of them haven't noticed yet, and that is INCREDIBLY exciting.
So, the right question
Not "does AI make founders worse?" That's a question for people looking for permission to be lazy or permission to be afraid. The right question is: am I building with discipline and logic, or am I building with hope?
If you're shipping things you can't explain, you're in the trap, AI or not. If you're interrogating every decision, staying close to the customer, and owning what you ship, you're not building faster and understanding less. You're building faster and understanding more, because you're getting a hundred reps in the time it used to take to get ten.
The tool is extraordinary. What you bring to it is everything.
