I Vibe Code Every Day Without an Engineering Team. Here Are the 3 Modes I Switch Between

I started vibe coding seriously about six months ago. And let me say it loudly: you can build real software without an engineering team. Sure, you need a bit of technicality, you need to be curious, you need to ask the right questions — but that’s another story.

What I want to share today is the meta question that most people miss: it’s not whether to vibe code. It’s which mode to use for what.

Because I’ve ended up using three completely different modes. And switching between them is the whole game.

Mode 1: Auto-Edit (or Bypass) — When You Just Want to Go

Auto-edit is for right now. No planning. No spec. No process. You see something, you want to change it, and you tell the AI: do it.

If you want to do something now, without even planning, auto-edit (or bypass mode) is for you. Don’t overthink it.

I prefer auto-edit over bypass when I have the option — it gives me at least a tiny bit of visibility into what’s happening. But honestly, the spirit is the same: shut up and ship.

When this mode shines:

• A tiny fix on existing code
• A quick prototype to “feel” an idea
• You’re exploring, not building
• The cost of being wrong is basically zero

The downside? You’re not tracking anything. You’re not thinking about phases. You’re just hoping the AI gets it right — and most of the time it does, for small stuff.

But don’t fool yourself: this mode does not scale. The moment you try to do something serious with auto-edit alone, you’ll feel the pain.

Mode 2: Planning — When You Want Structure Without Ceremony

Planning mode is the middle ground. You want the AI to recheck the repo, think before acting, and write down what it’s going to do. Then it does it.

I did a full deep dive on bypass, auto-edit, and planning — the three permission gears themselves — in a separate article, including the deploy bug that convinced me to stop arguing with the model and just plan instead.

This is great when:

• You’re starting from scratch on something new but contained
• You’re touching code you don’t fully know — and you want the AI to look around first
• The change is bigger than a 5-minute auto-edit, but smaller than a “real project”

The classic flow: you describe what you want, the AI explores the repo, writes a small plan, you say “yeah, do it”, and it executes. Clean. Predictable. Not too heavy.

This is my default for single-feature work on something I already understand. Just enough discipline to avoid mistakes, not so much that I waste tokens.

Mode 3: GSD — When You Have Something Bold, Big, or Completely New

Now we’re talking serious projects.

If you have something bold, something big, a brand new functionality, you want to track all the changes, you want to write everything down, you want phases, dependencies, a roadmap — GSD is there for you.

GSD stands for Get Shit Done. It’s a framework I discovered through a friend (the project lives here). It’s a plugin — a combination of skills, slash commands, and scripts — that guides you through the creation of any software using any LLM, any AI coding tool you like.

The mental model: imagine Jira inside your codebase, but driven by AI. You define a milestone. The milestone gets broken into phases. Each phase has its own discussion, its own plan, its own execution. And then — the magic part — you can run the whole thing autonomously, in waves, at the end of the day.

I did a full deep dive on GSD in a separate article, so I won’t unpack the whole machinery here. But the when is clear:

Use GSD when:

• You’re building a real project, not just a feature
• You want to track decisions, not just code
• You’ll work on it over multiple days or weeks
• You want to run things autonomously while you sleep
• You’ll have to explain the project to someone else later (or future-you)

The PM Mindset Tip (Before You Even Touch GSD)

Quick aside, because this matters: before I even start GSD, I usually open a regular chat with Claude or Cursor and just discuss the idea.

Not to build anything. Just to:

• Sketch the use cases
• Write the requirements
• Define the high-level outcome I’m chasing

Because I’m a product manager. I have this kind of product mindset baked in. So typically I write the use cases, the requirements, the high definition of what I need to achieve, and only then I switch to GSD.

That way, when GSD asks me “what are we building?”, I’m not improvising. I’m bringing context. Which is half the battle.

The Honest Recap

Three modes. Three different costs. Three different payoffs.

Mode	When	Cost	Payoff
Auto-edit	Tiny tasks, exploration	Cheapest, fastest	Speed
Planning	From-scratch single features	Medium	Structure without ceremony
GSD	Bold, big, multi-phase projects	Highest (time + tokens)	Real software tracked properly

There’s no “best mode.” There’s only the right mode for this task. The people who get great results from AI coding aren’t the ones who picked the perfect tool — they’re the ones who learned to switch modes consciously.

One Last Thought

The biggest unlock for me wasn’t any single tool. It was realizing that AI coding is not one thing — it’s a spectrum, from “go now” to “plan everything in waves.” And I get to pick where on that spectrum I want to be, for each task.

Six months ago I would have used the wrong mode for everything and either felt the AI was useless, or felt overwhelmed by ceremony. Now I switch on autopilot.

So if you’re still vibe coding in one mode for everything — try the other two. You’ll be surprised how much faster (or slower) you should actually be.

If you want to see what happens when you really commit to GSD end to end — milestone → phases → autonomous execution → end-to-end tests — I wrote it all up in the GSD deep dive. Spoiler: it’s nuts.