PI
All articles
Pavel Ilin5 min read

I vibe-coded a bunch of apps — an honest report

Vibe CodingAISecurityIndie

Over 14 years I've shipped 30+ apps. A good chunk of the recent ones were vibe-coded: I described what I wanted in plain words, and the AI wrote the code. Some of them already make money. Before you decide this is another "AI will replace programmers" piece — or the opposite, "vibe coding is a toy" — it's neither. It's an honest report from someone who actually ships: where it's pure magic, where I got burned, and where I watched a grown-up service drive off a cliff on blind trust in the model.

What vibe coding actually is — and why not to confuse it

The term comes from Andrej Karpathy: you "give in to the vibes" and accept whatever the AI suggests without reading every line. Sounds reckless? Sometimes it's exactly right. But there's a line, and most of the pain below grows from blurring it:

  • Vibe coding — I don't read the code. I care about the result, not how it's wired.
  • AI-assisted development — the AI types, but I read, edit, and own every line.

These are two different tools. Trouble starts when someone thinks they're doing the second while actually doing the first.

Where it's magic

You can vibe-code a working prototype over a weekend. Literally: Saturday to Sunday, total cost four beers and a bag of chips. For an indie maker that changes everything — a hypothesis gets tested in a weekend instead of a month. Didn't land? Throw it away, no regrets.

Where vibe coding genuinely carries you:

  • Prototypes and testing hypotheses — throwaway code that doesn't need to live long.
  • Boilerplate, plumbing, the routine you can't be bothered to type by hand.
  • An unfamiliar language or API — a fast start where you used to spend a day in the docs.
  • One-off scripts and tooling for yourself.

Some of my vibe-coded apps already make money. For things assembled over a weekend, that's a great ROI.

Where it breaks

The more complex and grown-up the system, the more blind trust costs you.

A real example — a large online video editor I worked on. A developer handed the whole task to the AI: whatever OpenAI suggested, he committed, without digging in. The result was such a mess that the task took twice as long: first "done fast," then just as long untangling why it worked at all. The story repeated with a second developer — he also trusted the model, and in the end the AI's changes had to be rolled back entirely and the service rewritten by hand over a weekend.

The lesson isn't "AI is dumb." It's that in a complex system full of edge cases and cross-dependencies, the AI confidently produces plausible code that breaks somewhere other than where you're looking. And debugging code you don't understand is almost always more expensive than writing it yourself.

Mobile deserves its own note: models have far more web data than native iOS. Xcode, async/await, memory management, wiring into system APIs — here the AI is wrong more often, and more subtly. On the web vibe coding flies; on native it trips.

Security — where you get burned quietly

The nastiest thing about vibe coding is that it fails quietly. What I catch over and over:

  • The AI happily hardcodes API keys and tokens straight into the code and drags them into a commit. One git push and the secret is in history forever.
  • Made-up dependencies. The model confidently imports a package that doesn't exist — and attackers have already registered those frequent hallucinations on npm or PyPI with malware inside. It's called slopsquatting: you install it, and hello.
  • Insecure "just make it work" defaults: CORS: *, certificate checks turned off, an open bucket, zero input validation.

It all has one root: you're trusting code you never read.

My rules

  • Prototype on vibes — sure. Production with other people's data — only what I've read with my own eyes.
  • I check secrets and dependencies before every commit, always. Two minutes versus a leaked key.
  • The more critical the code, the less vibe. Payments, auth, anything touching user data — I don't hand those over without a full review.
  • If debugging a vibe-coded chunk costs more than writing it myself, I rewrite it instead of stubbornly pushing on.

Who it's for

Vibe coding is a multiplier on top of skill, not a replacement for it. For a senior it gives a real speed-up on routine and prototypes, because there's something to check the result against. For a junior it's dangerous for exactly that reason — a junior has no way to tell working code from merely plausible code. For a pet project, go ahead and vibe. For production with money and data, vibe the draft but ship what you understand. That's why I own my apps end-to-end and for the long haul instead of slapping them together.

The takeaway

A year in, my position is simple: vibe coding is about speed at the early, low-stakes stages — not about switching your brain off. The most expensive stories I've seen weren't where the AI made a mistake, but where a human stopped reading. Great tool. Just don't turn off your head where the code will live longer than a weekend.


Wondering where vibe coding's limit is for your product, or want a senior who'll take an idea all the way to release? Get in touch.