Why is it so simple to vibe-code an app today?
It isn’t. That’s the whole point of this article.
In 2026 I shipped two apps built with AI at every stage — Lemonize, a macOS capture tool, and a major evolution of MyAbonPlus, my iOS subscription tracker. AI wrote most of the code. And yet nothing in that process resembled a “vibe.” There were requirement documents, acceptance criteria, design references, test suites, and a lot of me saying no, redo this part. If that sounds less magical than the demos you’ve seen on social media, good. It’s supposed to.
The promise (and the trap) of vibe coding
Let me be clear: when I say vibe coding, I mean the term as it’s actually used today — building software with no technical foundation, accepting whatever the AI produces with little or no validation of the code. Prompt, run, ship, repeat. The app appears on screen, it works on the happy path, and the story ends there.
Except it doesn’t, because shipping is not where the story ends. It’s where it starts. Creating an app is only a fraction of the work — the rest is edge cases, side effects, and the bugs your users find before you do. Every one of those discoveries costs you a customer, a sale, or a piece of credibility. And when that moment comes, the vibe coder is holding a codebase they never read, built on assumptions they never checked, with no tests to tell them what just broke.
An AI agent will happily write a thousand fluent, plausible lines — some of which are confidently wrong because it guessed the wrong thing three functions earlier. Without anything external to catch those errors — tests, a linter, a type-checker, a human who reads the diff — you’re not developing. You’re gambling with a very articulate slot machine.
That’s the trap. The demo takes an afternoon. The maintenance takes years.
Augmented, not replaced
So what should we call the real thing? Not vibe coding — just coding with modern tools.
Back in 2025, I wrote about building my first iOS app “with vibe coding”. At the time, the term loosely meant “using AI tools to build software,” and my conclusion already carried the caveat: AI didn’t replace me — it amplified me. Since then the vocabulary has sharpened. Vibe coding now specifically names the no-validation, no-ownership approach. What I was doing then, and what I do far more deliberately now, is something else: AI-augmented development.
The distinction matters because it changes who is responsible. In vibe coding, the AI is the developer and you’re a spectator. In augmented development, you’re the developer — the AI is a very fast, very capable, occasionally overconfident collaborator. The output is still yours. The bugs are still yours. The judgment is still yours.
AI-assisted development is product management
Here’s the shift nobody puts on the demo reel: when AI writes the code, your job stops looking like engineering and starts looking like product management.
Think about what actually fills my days on Lemonize and MyAbonPlus. I identify which features carry real value and which are decoration. I define each feature precisely — what it does, what it explicitly doesn’t do, how it behaves at the edges. I write acceptance criteria before any code exists, so that “done” means something verifiable instead of “looks fine.” I slice the work into small, shippable tasks. I hand one task to the agent — one, not ten. I review what comes back against the criteria I wrote. I accept, reject, or send it back with notes. Then I move to the next slice.
Identify, define, specify, slice, delegate, verify, iterate. That’s a product manager’s loop wearing a developer’s hoodie. The skill that got displaced isn’t thinking — it’s typing. What remains, and what actually determines whether your app survives contact with users, is the ability to specify clearly and judge honestly. AI raised the floor on code production and, in the same movement, raised the bar on everything around it.
The 2026 toolchain: from wireframe to shipped feature
The tools have matured enough to support this whole process, not just the code-generation part of it.
For Lemonize, the design didn’t start in Xcode. It started in Claude Design: first rough wireframes to explore the capture flow, then an interactive HD mockup — the floating panel, the preferences window, the onboarding screens, the design tokens. That mockup became a formal design reference document that the implementation was checked against. Design first, as an artifact you can point to, argue with, and validate code against.
Then come the agents. I use Claude Code and Codex as delegated workers, and the single most important rule is this: one feature at a time. You have to kill the fantasy of the AI that generates a whole app in one prompt. That fantasy is vibe coding — a giant unreviewed blob of code is exactly the failure mode we just walked through. An agent working on one well-specified feature, inside a project with tests, produces a diff a human can actually read. An agent asked to “build the app” produces an archaeology site.
The toolchain even helps with the reviewing. One useful pattern: separate production from critique. The instance that just wrote the code is the worst possible reviewer of that code — it’s attached to its own decisions. A fresh session, or a different model entirely, reads the diff like a skeptical colleague. I’ve had Codex tear apart plans that Claude Code was perfectly happy with, and vice versa. That friction is not overhead. It’s the process working.
Two apps, one method: Lemonize and MyAbonPlus
Lemonize was born professional. Before the first line of Swift, there was an expression of needs — target user, V1 scope, explicit non-goals. Then the Claude Design reference. Then an MVP development plan cut into phases, each phase with its own acceptance criteria. Development itself ran on TDD: the test exists before the code, and xcodebuild test decides what’s true, not my optimism. When Apple rejected the first App Store submission, that structure is what made the recovery fast — I knew exactly what the app did, why, and where, because all of it was written down before it was built.
MyAbonPlus tells the other half of the story, because it’s the same app across both eras. It started life in 2025 as my vibe-coding experiment — and it worked, as far as it went. But turning it into something durable meant retrofitting the discipline: a clean MVVM structure, business logic extracted into a package that tests in seconds without a simulator, versioned SwiftData migrations so that a schema change can never eat a paying user’s data. Same product, same solo developer, same AI assistance. The difference between the 2025 version and the 2026 version isn’t the model’s intelligence. It’s the method wrapped around it.
What this method really costs
This approach is slower at the start. Writing an expression of needs while someone on X ships a prototype from a single prompt feels like showing up to a street race in a truck. If all you want is a weekend prototype, a proof of concept, a toy — vibe-code it, sincerely. The truck is the wrong vehicle for that trip. And that’s okay.
It also demands skills that have nothing to do with prompting: scoping a feature, writing acceptance criteria, saying no to your own ideas. Product management skills. If you got into this hoping to skip the boring parts of software, I have bad news — the boring parts turned out to be the job.
And code review never became optional. I still read the diffs. All of them. Some days that’s the least glamorous hour of my day, and it’s also the hour that has caught every bug that would have embarrassed me in production.
Conclusion
The question in the title has a serious answer after all. It’s “simple” to vibe-code an app today in exactly the way it’s simple to record a song on your phone: the tool barrier collapsed, and the craft barrier didn’t move an inch.
AI didn’t shrink the job of building software. It relocated it — away from the keyboard, toward specification and judgment. The developers who thrive with these tools aren’t the ones who prompt hardest. They’re the ones who know what to build, can say precisely what “done” means, and read what comes back with a skeptic’s eye.
AI didn’t make development simple. It made good process the whole job.
What about you — have you shipped something vibe-coded and lived with it six months later? I’d love to hear how that went.