Everyone’s talking about “vibe coding,” the practice of handing a prompt to an AI agent and accepting whatever comes out.
I’m not doing that. And I’d argue you shouldn’t be either.
What I’m doing looks similar on the surface. I’m using AI agents to generate code every day, and I’m not typing most of it. But the underlying practice is different. I am not trying to feel my way into working software. I am managing fast implementation against explicit intent, architecture, standards, and review.
The Problem with Vibe Coding
Vibe coding treats the AI as the engineer. You describe what you want, the AI produces code, you review it enough to feel okay about it, and you move on.
The problem isn’t that AI generates bad code. The problem is that you’ve abdicated the decisions that matter most (architecture, trade-offs, constraints, standards) and pushed them down to a layer that has no context for your system, your team, or your users.
When those decisions are wrong (and without guidance, they often are), you don’t find out until you’re three features deep and everything is inconsistent. You didn’t have a vibe coding problem. You had a leadership vacuum, and the AI filled it with defaults.
I have seen the smaller version of this happen in my own workflow. An AI agent I was running committed code directly to main. The code was excellent. That was not the issue. The issue was that it skipped the process that gives the team a chance to review, question, and catch problems before they become shared history.
I made the agent revert the commit and put the work into a feature branch anyway. The standard had to apply even when the output looked good.
What Intentional AI Pair Programming Actually Looks Like
Think about how effective human pair programming works.
One person stays focused on architecture, intent, and constraints. They’re asking “what are we actually building, and does this approach hold up?” The other handles the mechanics of implementation: syntax, patterns, the keyboard. In a good pairing session, both people can challenge the direction.
AI is not that kind of peer. It will not reliably stop you, challenge your assumptions, or tell you that your product judgment is weak. That responsibility stays with the human. The useful version of the pairing model is simpler: the human owns intent, architecture, and judgment. The AI handles execution and speed.
In practice, that means the important decisions stay upstream. I define the system shape before the agent touches a file. I load coding standards and architectural constraints at the start of the session. I decide when to abstract, when to stay concrete, and when “good enough” is actually good enough.
I also watch for drift. When the codebase starts repeating itself, when responsibilities want to move into shared libraries, or when an early decision no longer fits the product, I stop the agent and re-brief. The agent can move fast, but speed without steering just spreads mistakes faster.
The agent’s role is execution, pattern recall, and speed. The engineer’s role is direction, judgment, and ownership.
This isn’t prompting and hoping. It’s not outsourcing thinking to a model. And it’s definitely not shipping whatever the AI happens to generate. It’s an intentional collaboration between an experienced engineer and a very fast, very capable implementation partner.
Why This Changes What Agile Means in Practice
One of the underappreciated effects of working this way is what it does to the inspect-and-adapt loop.
Agile was never just about shipping faster. It was about shortening the distance between learning and action. The idea is simple: the sooner you can see what you’ve built and course-correct, the less waste you accumulate.
The problem has always been latency. By the time a design issue surfaces (in a code review, in a sprint retrospective, in a bug report), you’ve already built on top of it. Refactoring becomes a project. “We’ll clean it up later” becomes a phrase that haunts your backlog.
AI-assisted development collapses that latency. I periodically ask the agent to inspect the codebase for refactoring opportunities as part of the same development loop:
- Where logic has started to duplicate
- Where responsibilities want to be extracted into shared libraries
- Where early decisions no longer reflect how the system has actually evolved
Instead of deferring that work to a future sprint (or accepting “we’ll clean it up later” as inevitable), the refactoring happens now. The inspect-and-adapt cycle that Agile describes at the sprint level becomes a continuous, near-real-time practice.
The result is a codebase that’s cleaner than you’d expect at this stage, not because we avoided change, but because we embraced it early and often.
The Productivity Gains Are Real, But They Come From Discipline
While rebuilding an internal point-of-sale application at a marketing services SaaS provider, I found that I could manage three independent agents at once when the work was scoped well. That did not mean three vague prompts running wild. It meant three bounded threads of work, each with context, standards, and a clear definition of done.
On a good day, I can deliver more than 10 stories while managing three agents. That kind of velocity is what allowed me to recode my company’s point-of-sale application in three months. I could keep one thread moving while reviewing another, redirect bad approaches early, and use agents to handle the mechanical parts that normally slow a developer down.
That only worked because the work was managed deliberately. Broad prompts created broad uncertainty. Tight stories, clear architectural decisions, and explicit standards created useful output.
These are the same guardrails we put in place when onboarding junior engineers: clear intent, explicit standards, tight feedback loops, concrete examples, and design decisions made at the right level. The difference is that an AI agent turns ambiguity into code much faster than a junior engineer does.
AI agents are powerful, but they don’t reduce the need for engineering leadership. If anything, they make its absence immediately visible. A vague request to a senior engineer produces a conversation. A vague request to an AI agent produces a diff, whether the request deserved one or not.
Ownership Is the Difference
The model is not the strategy. The workflow is.
If the workflow starts with vague intent, skips architectural decisions, ignores standards, and treats review as a formality, the team will get fast output and slow consequences. If the workflow keeps ownership with the engineer, AI becomes an accelerant instead of a substitute for judgment.
The AI can generate the code, but the engineer still owns the choices that make the code worth keeping: the architecture, the standards, the tradeoffs, the review, and the decision to ship.
Receipts
- Three-agent workflow: While rebuilding an internal point-of-sale application at a marketing services SaaS provider, I found I could manage three independent agents at once when each thread had clear context, standards, and a definition of done. On a good day, that workflow lets me deliver more than 10 stories.
- Point-of-sale rebuild: That three-agent workflow helped me recode the company’s point-of-sale application in three months.
- Process discipline: An AI agent I was running committed directly to main. I made the agent revert the commit and put the work into a feature branch because good output still needs reviewable process.