What Vibe Coding Actually Is

The term is polarizing but the phenomenon is real: using an LLM as your primary coding interface — describing what you want, reviewing what comes out, iterating — rather than writing every line yourself.

I've been doing this seriously since early 2025 across multiple products: manju (AI image translation), talkr.ai features, this portfolio, and internal tooling. The results are uneven — but the productivity ceiling is genuinely different from what I've seen before.

What It's Actually Good At

Scaffolding and boilerplate: generating auth flows, CRUD APIs, component structures. Things where the pattern is known and the main cost was typing. This is where vibe coding pays back immediately.

Exploring unfamiliar territory: I needed to build a custom OCR pipeline for manju. I've never done computer vision at this level. With Claude walking me through the options, evaluating libraries, and generating initial implementations to test — I shipped a working prototype in two days instead of two weeks of reading docs.

Refactoring and documentation: "here's this 400-line function, extract the business logic, add types, explain what it does." Tasks that are important but painful to do manually. The LLM is tireless here.

What It's Bad At

Knowing when to stop: LLMs over-engineer. They'll add abstractions, error handlers, and configuration options you don't need. You have to actively prune. The output of vibe coding is always too complex by default — your job is to simplify it.

System-level reasoning: "is this architecture right for my scale?" is a question where LLMs give you plausible-sounding answers that might be completely wrong for your context. I've had Claude confidently suggest a Redis strategy that would have been a disaster at yomimanga's traffic levels. You need to think critically about architecture yourself.

Novel bugs: when something is wrong in a way the LLM hasn't seen before, it starts hallucinating fixes. You can waste hours on a loop of suggested changes that don't address the actual root cause. Learn to recognize when to step out of AI-assisted mode and debug manually.

My Actual Workflow

I don't "vibe code" in the sense of hands-off generation. I treat the LLM as a very fast junior engineer: it writes first drafts, I review and direct, it revises. The feedback loop is tight.

The shift in how I allocate my time is real though. I spend far less time writing code and far more time:

  • Designing system behavior (what should happen, under what conditions)
  • Reviewing and testing output (does it actually do what I said)
  • Making architecture decisions (which the LLM can't make for me)
  • Talking to users (the thing that actually determines what to build)

This is the real shift. Vibe coding doesn't remove engineering judgment — it amplifies it. You need to be a better engineer to use it well, not a worse one.

The Compounding Effect

The part that's hard to communicate until you've experienced it: the speed at which you can test ideas. A new feature that used to take a week to prototype takes a day. That extra time goes back into talking to users and shipping more iterations. The feedback loop that was already compressed gets compressed again.

For solo founders, this is the biggest unlock. I'm building at a pace that used to require a team. Not because the AI writes perfect code — it doesn't — but because the total cycle time from idea to testable implementation is radically shorter.