Why I'm Writing This

In my last post, I mentioned "AI-Directed Development" as distinct from "vibe coding." A few people asked me to expand on that, so here we are.

I've been using AI coding assistants heavily for the past year, primarily Roo Code with Claude and o3, and I've developed a workflow that consistently produces code I'm happy to ship. It's different from what I see a lot of developers doing, and I think the distinction is worth articulating.

This isn't about right vs wrong. Both approaches have their place. But if you've ever been frustrated by AI-generated code that almost works but needs extensive cleanup, or found yourself doing more rework than you expected, this might resonate.

Two Modes of Working With AI

"Vibe coding" has become a common shorthand for letting an AI agent run end-to-end on an implementation with minimal interruption. It's fast, often fun, and surprisingly effective for many tasks. You describe what you want, let the agent work, and review the output at the end.

When I care about consistency, architecture, and long-term maintainability, I use a different workflow that I've started calling AI-directed development.

AI-directed development: the agent writes code, but I insert lightweight checkpoints that keep decisions aligned before they harden.

The key distinction isn't about control or trust. It's about when feedback happens.

Vibe coding optimizes for speed to first solution. AI-directed development optimizes for speed to a solution I'm happy to ship.

In other words: vibe coding is output-first. AI-directed development is decision-first.

What AI-Directed Development Looks Like in Practice

Here's my default workflow when using Roo Code:

Auto-Writes Off By Default

I don't let the agent automatically write files without my approval. This sounds like it would slow things down, and initially it does, but it fundamentally changes the dynamic.

Instead of reviewing a completed implementation, I'm reviewing decisions as they're being made. I can catch issues before they become structural.

My default loop is: agent proposes → I approve/redirect → agent writes.

Tight Early, Relaxed Later

For net-new features and complex changes, I'm heavily involved at the start. I'm reading the proposed changes, asking "why this approach?", and sometimes redirecting before a single line is committed.

Once I understand and agree with the shape of the solution, I loosen the reins. I scan files more quickly. I trust that the foundation is solid and the agent is filling in the details correctly.

For simpler tasks with strong constraints (good test coverage, established patterns, strong linting rules), I'm looser from the start. The guardrails are already in place.

The Goal: Shape the Solution Space

I'm not writing the code. I'm shaping the decisions that produce it.

This is a subtle but important distinction. The agent is still doing the heavy lifting. But I'm making sure it's lifting in the right direction.

My Checkpoint Cadence

Here's what a typical task looks like:

Agent proposes approach (no code yet, just the plan)
Agent writes/updates tests (validates the interface)
Agent implements in small chunks (I review each before proceeding)
Agent refactors to match repo conventions (cleanup pass)
I update AGENTS.md if anything surprised me (encode the lesson)

This turns philosophy into a reproducible workflow. Each checkpoint is lightweight, but together they keep the solution aligned.

Why Early Direction Beats Late Review

This isn't about micromanagement. I trust colleagues to work autonomously all the time. The difference is that humans naturally surface uncertainty, ask clarifying questions, and have long-term ownership instincts.

AI agents are extremely capable, but they:

Don't retain context unless we encode it
Won't reliably surface uncertainty unless prompted
Optimize aggressively for completion

When you defer feedback to the end, decisions get made (often implicitly) and hardened into code. By the time you're reviewing a PR, you're not just reviewing code. You're reconstructing intent, unwinding assumptions, and asking the agent to "try again" after the most important context has evaporated.

I've found it quicker and easier to review early and often, understanding the direction as it progresses, instead of getting a big PR that I have to wade through and unpick lots of issues.

It's easier to set a route at the start of a journey than to reroute after hundreds of miles.

Early Review Is Lighter, Not Heavier

This is counterintuitive, but early review is actually less work:

It's fast (you're looking at direction, not details)
It's directional (you're asking "is this the right approach?" not "is this line correct?")
It requires less mental reconstruction

Late review is dense. You're reasoning about decisions you didn't witness being made. You're trying to understand why the agent chose a particular abstraction without the context of what alternatives it considered.

I don't read more code. I read earlier code.

The Speed Paradox

Yes, my initial time-to-task-complete is longer than pure vibe coding. Maybe 30-50% longer on the first pass.

But here's what I've found empirically:

Fewer retries
Less cleanup
Less architectural drift
More confidence when I merge

Net result? I ship higher-quality changes faster overall, often despite a slower first pass.

I've found that trading a bit of upfront attention buys back far more time later, especially on work I actually care about.

AGENTS.md: Teaching, Not Just Configuring

One of the most powerful tools in AI-directed development is treating your agent configuration as a living system.

In Roo Code, I have an AGENTS.md file (and agent-specific rule files) that captures project conventions, architectural decisions, and coding standards. Strong rails matter, but the real power comes from treating AGENTS.md as a feedback loop rather than a setup step.

When the agent makes a bad assumption or produces code that doesn't match my standards, I don't just correct the immediate issue. I update AGENTS.md right then, while the context is fresh.

A Real Example

Recently, an agent kept wrapping error responses in nested JSON objects when I wanted flat structures. After fixing it twice manually, I added to AGENTS.md:

Error responses: Return flat JSON with error and message keys only. Never nest under data or result.

Haven't had to correct that pattern since.

Over time:

The agent's baseline improves
My intervention rate drops
Consistency goes up automatically

The goal isn't to supervise forever. It's to teach the agent how I think.

This compounds. Every correction that gets encoded is a correction I don't have to make again.

"But Doesn't This Reduce Parallelism?"

People have asked whether this approach limits how many tasks I can run in parallel. If I need to be involved in every task, doesn't that bottleneck everything?

Honestly? I still run 3-4 concurrent tasks without issue.

Here's why: as a principal engineer, most of my time is already spent mentoring, reviewing multiple engineers and teams, and thinking about the big picture. Context-switching between parallel efforts is a core skill I've built over years of leading teams.

AI agents slot naturally into that same mental model. I'm not context-switching more. I'm context-switching differently.

This feels less like micromanagement and more like technical leadership compressed in time.

When Each Approach Makes Sense

I want to be clear: I'm not saying vibe coding is bad. I use it myself for certain things.

Vibe Coding Works Well When:

The problem is bounded and well-defined
The output is disposable or low-stakes
You don't mind re-rolling if it doesn't work
Strong external constraints exist (comprehensive tests, strict linting)
You're prototyping or exploring

AI-Directed Development Shines When:

You care about architecture and maintainability
You own the system long-term
You're accountable for quality
The work is complex or novel
You want to ship without cleanup passes

The key is being intentional about which mode you're in.

Avoiding the "AI Slop" Stigma

Let's name the elephant in the room: there's a stigma around AI-generated code. And honestly? It's earned. Sloppy AI workflows do produce sloppy code.

But the fix isn't avoiding AI. It's using it intentionally.

The stigma exists because unaligned AI writes a lot of code very quickly. If you only review at the end, you inherit whatever assumptions, abstractions, and architectural choices the agent made in the middle. Sometimes that's fine. Sometimes it's a mess of spaghetti code, bad architecture, or assumptions that were never true.

AI-directed development flips that dynamic. Heavy alignment early, light oversight later. By the time the code is "done," it already matches how I would have designed it myself.

The problem isn't that AI writes code. It's that unaligned AI writes a lot of it very quickly.

The Bottom Line

Vibe coding and AI-directed development both have their place. The difference is whether you're discovering a solution or engineering one.

For throwaway scripts and quick prototypes, let the agent run. For systems you'll maintain, code you'll be accountable for, and work that needs to be right the first time, stay in the loop early.

Vibe coding is great for discovering solutions. AI-directed development is how I make sure I ship the right one.

If you've been frustrated by AI-assisted coding producing code that's almost right but needs extensive rework, try tightening up early in the process. You might find, like I did, that a little upfront direction saves a lot of downstream pain.

P.S. 🌴 I've implemented an easter egg somewhere on this site. See if you can find it and let me know what you think! 🐠

Have thoughts on this? I'd love to hear how others are working with AI coding assistants. Where do you draw the line between vibe coding and staying in the loop? Join the conversation on LinkedIn.

AI-Directed Development vs Vibe Coding: How I Actually Work With AI Agents