mp_
← back

April 5, 2026

How I actually vibe code — my process in 2026

buildinghow-to8 min read

People use the term "vibe coding" like it means typing prompts and hoping for the best. That is not how it works if you want to ship something real.

Here is my actual process.

What vibe coding actually means to me

I am not a trained software engineer. I can read code, I understand systems, I have opinions about architecture — but I could not write a React component from scratch without help.

Vibe coding, to me, means using AI as a capable collaborator who knows the implementation details that I do not. I bring the product sense, the taste, the requirements, the judgment about whether something is good or not. Claude (or whatever model I am using) brings the syntax, the library knowledge, the pattern matching.

The division of labor works well when both sides are honest about what they are good at.

My actual workflow

Step 1: Write a real spec

I write a detailed document before starting any build. Not a sketch — a proper spec with stack decisions, component inventory, data shapes, edge cases. The spec usually takes longer than you think it should. That is fine. Decisions made in the spec are much cheaper than decisions made mid-build.

Step 2: Plan the phases

I break the build into phases. Foundation first. Then data layer. Then UI components. Then pages. Then polish. Doing it in the wrong order creates dependency hell.

Step 3: One context, one problem

Each Claude Code session has a focused scope. Not "build the whole site" — "build the header component according to this spec." Focused prompts get focused output. When I try to do too much in one session the output gets sloppier.

Step 4: Test everything visually

AI cannot see your screen. You have to. After every meaningful change, I look at it in the browser. Not just at desktop size — mobile too. Things that look correct in code often look broken on screen.

Step 5: Understand what was built

This is the step most vibe coders skip. Before moving to the next thing, I make sure I understand why the code works. Not to memorize it — to catch it when something breaks. If you do not understand what was built, debugging becomes impossible.

The honest limitation

You will get stuck. AI will confidently suggest something that does not exist, or will miss a subtle dependency. When that happens, the ability to read the error message and know what question to ask is the skill that matters.

That skill is worth developing.

Tools I actually use

No stack is sacred. Use what ships.

← previous

I used an image I had no right to. Here is what that week felt like.

next →

What Ramadan taught me about productive hours

// stay in the loop

No schedule. No spam. Just updates when something ships.