How I Vibe Code - My Agentic Workflow for Everyday Development

Everyone's talking about vibe coding like it's some new religion. For me it's just... how I code now. I use AI agents for almost everything - planning features, writing boilerplate, reviewing PRs, fixing bugs. But there's a method to it, and it took me a while to figure out what actually works versus what just feels productive while producing garbage.

The Toolbox

Here's what I use on a daily basis, split between personal and work:

• Opencode - my go-to for personal projects and everyday coding. It's fast, it's in the terminal where I already live, and the agent mode handles multi-file edits well.
• Cursor - what we have at the office. Great for visual diffs and the built-in /code-review command. I use Cursor Start on personal stuff too.
• Claude - we have a team plan at work. Claude is my planning partner. More on that below.
• Codex - we got free credits since we registered as a startup. I use it primarily for code reviews. The diff analysis is surprisingly good.
• Kiro - I've tried it. It's good, but it's slow. It plans, then designs, then implements - which is methodical, sure, but it takes roughly 5x longer than just prompting Claude directly. I don't have patience for that workflow yet.

Deepseek V4 Flash was my partner in crime for a few weeks. Fast, decent output, basically free. Then they removed it from the free tier. RIP.

My Agentic Coding Technique

Nothing unique here. Just a three-step process that I've refined over months of trial and error.

Step 1: Plan

This is the most important step and the one most people skip. Before any code gets written, I generate a plan.md file using a high-effort model. I'm talking Claude Sonnet 5 on high effort, or sometimes Opus 5 on medium/high. The plan covers:

• What exactly needs to change and why
• The approach - which files, which functions, what patterns
• Potential edge cases and failure modes
• A rough implementation order

Then I read the plan. Not skim - read. I check every suggestion against what I actually want. Is the model suggesting the right pattern? Does this approach make sense for this codebase? Am I missing something it didn't consider?

This takes 10-15 minutes of upfront work and saves hours of chasing the wrong implementation.

Step 2: Implement

Once the plan is solid, I hand it off to lighter models for actual coding. The planning model was expensive in tokens - the implementation model doesn't need to be.

Models I use here:

• Grok 4.6 (Medium) - surprisingly good at following structured plans
• Sonnet 5 (Low) - when I need reliable output without burning credits
• Deepseek V4 - fast and cheap for straightforward implementations
• Mimo 2.5 - decent for boilerplate and repetitive patterns

The trick is: the plan already has the logic figured out. The implementation model just needs to translate it into code. That's a much easier task than "build me a notification system."

Step 3: Code Review

This is non-negotiable. Every change goes into a new branch. Feature work, bug fixes, hotfixes - doesn't matter. New branch.

Then I run a code review before merging. The review checks for:

• Breaking existing functionality
• Logic errors in the new code
• Missing edge cases
• Code style consistency

What I use for reviews:

• /code-reviews in Opencode - diffs the branch against main and analyzes changes
• /code-review in Cursor - same concept, visual interface
• Codex - when I want a second opinion from a different model
• At work: we have a CI action that runs Claude review automatically on every PR, along with react-doctor. It catches things I miss.

The Token Economy

Here's something nobody talks about: tokens cost money. Planning with Opus 5 is expensive. But it's a one-time cost per feature. Implementation with cheaper models is where you save. The ratio matters more than the absolute cost.

I'd rather spend 10K tokens on a solid plan and 5K tokens on implementation than 15K tokens on a mediocre plan that needs three rewrites.

What I'd Tell Anyone Starting

Don't skip the plan. Seriously. The biggest mistake I see people make with AI coding is throwing a vague prompt at an agent and hoping for the best. That works for toy projects. For anything real - anything with users, dependencies, or production traffic - you need a plan first.

And read the plan. Don't just approve it and move on. The model doesn't know your codebase like you do. Your job is to catch the things it got wrong before they become bugs.