Vibe coding is a skill stack, not a shortcut

Vibe coding has a reputation problem in both directions. Half the internet says you can ship an app by typing wishes into a chat box. The other half says everything built that way is a security breach waiting to happen. After spending months building things this way, I think both halves are describing the same missing ingredient: a small stack of skills that nobody puts in the demo videos.

Here is a number that made me sit up. Researchers ran 2.23 million code samples through 16 different AI models and found that 19.7 percent of them referenced at least one software package that does not exist. The AI made the name up. That is not a reason to stop vibe coding. It is a reason to know what your job is when the AI is doing the typing.

What vibe coding actually is

Vibe coding means describing what you want in plain language and letting an AI write the first draft of the code. You then steer: test it, react to it, ask for changes, repeat. The word “first draft” is doing a lot of work in that sentence, and it is the part that gets skipped.

The workflow that holds up is not “describe, generate, done.” It is a loop with four distinct phases, and each phase is a skill you can practice.

flowchart LR
  P[Plan] --> S[Steer]
  S --> E[Evaluate]
  E --> H[Ship]
  E -->|something is off| P
  H -->|next feature| P

Fig 1The vibe coding loop. The AI only really helps in the Steer phase. The other three are yours, and they are where projects live or die.

Phase 1: Plan before you prompt

Every guide I read while researching this converges on the same first step, and it has nothing to do with AI: know what you are building before you ask for it.

That does not mean a formal spec. It means a few lines of plain text, sometimes called a PRD (product requirements document, a fancy name for “what this is and who it is for”). What the app does, who uses it, and what the main screens are. Sketching how the screens connect, even on paper, counts.

Deciding your data early matters more than it looks. An AI asked to “add user accounts” to a project with no data model will invent one, and every prompt after that builds on the invention.

Phase 2: Steer, do not gamble

The second skill is how you actually talk to the model, and the pattern is consistent across every source I found: small steps beat big wishes.

Asking for one change at a time does two things. It keeps each result small enough to check, and it keeps the AI anchored to what already exists instead of inventing a new pattern each round. Pointing it at the relevant files and at examples of code you already like is part of the same skill. People call this context engineering now, but it is really just briefing someone properly before they start.

The other half of steering is not a prompt skill at all. It is git.

If git (the standard tool for saving snapshots of your code) is new to you, learn just two moves first: save a checkpoint, and go back to one. That covers most of what a solo vibe coder needs on a normal day.

Phase 3: Evaluate everything

This is the phase that number from the intro belongs to. One in five AI code samples mentioning a package that does not exist means “the AI said so” is not evidence of anything. Attackers know this too: some register fake packages under exactly the names models tend to hallucinate, hoping someone installs them without looking. The trick has a name, slopsquatting.

So evaluation is its own skill, made of small checks:

• Run the feature right after it is generated, and click around the features next to it, because changes leak.
• Before installing anything the AI suggested, spend thirty seconds confirming the package exists and is actually used by other people.
• Read the code. Not to grade its elegance, but to notice when something looks off.

That last point is where fundamentals earn their keep. You do not need to write code from scratch to vibe code, but you do need to read it at the level of “what data goes in, what comes out, and where does it get stored.” Reading is a much smaller skill than writing, and it is the difference between steering and hoping.

Phase 4: Ship like it matters

The last phase is everything between “it works on my machine” and something real people use, and it is where AI helps least.

A prototype that looks finished is not finished. Polish is the thing AI is best at producing, which makes it a misleading signal. Before anything goes public there is a short unglamorous list: check what is exposed, check what happens with bad input, check that secrets like API keys live in configuration and not in the code itself.

Shipping also means writing down what you decided and why, even just for yourself. A prompt log reads like a diary of the project’s decisions, and future you, or the AI in your next session, will be briefed by it.

An honest self-check

What I would remember

Vibe coding is real and it is genuinely fast, but the speed comes from the middle of the loop. The AI writes the draft. Planning what to build, checking what came back, and carrying it to something shippable stay human jobs, and they are learnable, unglamorous, and smaller than they sound.

The AI types. You are still the engineer.

Sources

• Softr: 9 vibe coding best practices on planning, wireframes, and prompting in steps
• freeCodeCamp: How to become an expert in AI-assisted coding on fundamentals, evaluation habits, and knowing when to code yourself
• Arnica: Vibe coding security risks for the hallucinated package statistic and slopsquatting
• GitHub Blog: Why developer expertise matters more than ever in the age of AI on judgment, review, and systems thinking
• Appwrite: 20 security best practices for vibe coding for the shipping checklist