That headline sounds like a course pitch. It isn't. There's nothing to buy at the bottom of this post. I just keep watching the AI coding debate run on opinions, and I'd rather add a data point: mine.
Two claims dominate that debate. One: AI-built apps are toys held together with tape. Two: you can build a SaaS empire in a weekend with zero experience. I've tested both claims against production, and both failed, in ways that cost people real time and money.
Here's my data point: twelve apps, live, in production, with real users. Call tracking, keyword analysis, competitive research, image generation, landing page testing, link tracking, marketing analytics, client communication, a marketplace, and one app that has nothing to do with marketing at all. I didn't write the code for them. Every single one is my architecture, my problem, and my fix.
What "I don't write code" actually means
Let me be precise, because this is the part that gets oversold.
I don't type the code. But I've been building SaaS products with my dev team since 2014. My first tool exists because I was tired of juggling spreadsheets to plan client sites, so I designed something better and we built it. That tool became the core of the platform my company runs today. Over a decade of that work, you absorb things: how data should flow, what breaks under load, why feature A can't ship before feature B, what users actually click versus what they say they want.
That's the part AI didn't replace. AI replaced the typing.
When I sit down to build an app with AI tools, I'm not saying "make me a call tracking app" and going for coffee. I'm specifying how calls get routed, what the reporting needs to show, where the data lives, what happens when two things break at once. The AI writes the implementation. I make every decision a software architect makes, just in plain English instead of TypeScript.
So when I hear "vibecoded apps are toys," what's usually being described is an app built by someone who skipped the ten years of learning what to ask for. The tool didn't fail. The specification did.
What AI coding actually replaces
Three things, honestly:
The typing. Obvious, but it's most of the cost. A feature that would have been a two-week dev cycle is now an afternoon of me describing, testing, and correcting.
The starting line. The gap between "I have an idea" and "there's something on screen" used to be weeks and thousands of dollars. Now it's an evening. That changes which ideas are worth trying. I built one of my apps because I wanted to know whether the idea worked at all, and the cheapest way to find out was to build it. It works. It's selling. In 2015 I would never have greenlit that experiment.
The permission. This is the one that took me longest to notice. Before AI coding, a non-developer with an idea needed to convince a developer it was worth building. That's a pitch, a budget, a queue. Now the idea goes straight to a prototype, and the prototype either proves itself or dies quietly. Bad ideas die cheaper. Good ideas live faster.
What it doesn't replace
Knowing what to build. Every one of my twelve apps started as a wall I hit in my own work. I tracked calls manually before I built call tracking. I checked competitors page by page before I built software that scores them. The app is always the second step. The process knowledge is the first, and there's no prompt for it.
Knowing when it's wrong. AI code mostly works, which is the dangerous part. The failures are quiet: the edge case it didn't handle, the data it stores in a way that will hurt you at 10,000 users instead of 100. If you can't smell when something is off, you'll find out from your customers. Ten years of shipping with a real dev team is what tuned my nose. I can't give you a shortcut for that, and I'd be lying if I sold you one.
The last 20 percent. Getting an app to "works in the demo" is the easy 80. Real users, real payments, real support tickets, real uptime: that's the 20 that separates a project from a product. AI helps there too, but it doesn't carry it. You do.
A team, when it matters. My core platform is custom-built by developers who've been with me for over eleven years, and I wouldn't trust it to anything else. The AI-built apps orbit around it. Knowing which projects need which approach is itself a judgment call, and it's not one you develop in a weekend.
The honest pitch for trying it anyway
After all those warnings, here's the other side, and I mean it just as much.
If you have real process knowledge in any field (you've done the work by hand, you know where it hurts), you are sitting on app ideas whether you realize it or not. The thing you do in a spreadsheet every week because no software does it right? That's an app. The report you assemble by hand for every client? That's an app. The question you answer forty times a month? App.
For twenty years, having that knowledge without having code was a dead end. You'd tell people "someone should build this" and watch nothing happen. That dead end is gone. The distance between "someone should build this" and "I built this" is now measured in evenings.
You will build some bad things first. Mine weren't all winners either, and the ones that work went through more revisions than I'd like to admit. But the cost of finding out dropped so far that not trying is the expensive option now.
Where this goes
I think we're early in a shift where the interesting software increasingly comes from operators, not engineers. The person who's done a job for ten years and can finally build their own tool will beat the engineer guessing at that job's problems from the outside. Not always. But more and more.
The developers aren't going anywhere; somebody has to build the platforms the rest of us build on, and the serious systems still need serious engineering. But the long tail of software, the thousands of small sharp tools that solve one specific problem well, that's being handed to the people who actually have the problems.
I've shipped twelve so far. The habit's gotten out of hand, my wife would confirm it, and I have no intention of stopping.