Stop Vibe-Coding in One Giant Chat

A few months ago I tried to build a feature entirely in one chat. Requirements, design decisions, implementation, tests, the works, all in a single running conversation. It started great. By the 3rd hour it was a mess: the assistant had forgotten a requirement constraint I mentioned at the top, it was reconfirming a decision we'd already made before, and every new prompt had to compete with a wall of stale context just to get read correctly. I was basically pair programming with someone who had short-term memory loss, and I was the one paying the tax for it.

That's not an AI problem. It's a context problem. And once I started treating it that way, the fix looked a lot like something I already knew from writing actual software: don't cram everything into one function, split it by responsibility.

The chat window is not the unit of work

The default way most people use AI coding assistants is one continuous thread: describe the feature, iterate, debug, ship, all in the same context. It feels natural because it mirrors how we'd explain something to a coworker. But a single thread accumulates everything - abandoned approaches, corrected assumptions, half-finished tangents - and none of it gets cleaned up. The model has to hold all of it, and so do you, scrolling back up to remember why a decision was made.

The fix isn't a smarter model. It's a smaller, well-defined unit of work per conversation, with an explicit artifact handed from one stage to the next. That's the whole idea behind splitting a workflow into agents: each one gets a narrow job, a clean context, and a concrete output. No agent has to hold the entire history of the project in its head, because it doesn't need to - it just needs the artifact its predecessor produced.

I ended up with five stages, each mapped to a slash command: /create-td, /dev, /test, /handoff, and /prototype. None of this is precious - swap the names, merge two stages, whatever fits your project. What matters is the shape underneath.

/create-td - write the plan before the code

This one takes product requirements (either I paste them in, or write them inline in the prompt) and turns them into a comprehensive technical overview: what needs to get built, how the pieces fit together, what the tricky parts are. It doesn't modify a single line of code.

The reason this exists as its own step, instead of folding into "just start building", is that it produces a durable artifact. A tech doc sitting in the repo is something every later stage can read instead of re-deriving. It's the difference between "the agent remembers we decided X" and "X is written down at docs/some-feature.md and any agent, any day, in any fresh context, can go read it." One of those survives a compacted conversation. The other doesn't.

/dev - break it into parallel, verifiable chunks

/dev takes that tech doc and decomposes the build into smaller tasks - parallelizing where it can - then checks the breakdown with me before touching anything. This is the sub-agent idea in practice: instead of one big agent doing the entire implementation serially in one context, independent pieces get handed to separate agents (or separate isolated contexts) that don't need to know about each other's internals, only about the shared contract between them.

The "verify with the user before executing" part matters more than it sounds. Task decomposition is where an agent's assumptions are cheapest to catch - before code exists, not after. A 5-min look at a task breakdown catches a wrong assumption that would otherwise surface as a confusing bug 3 files deep.

/test - but only after checking the assumptions

Tests are a suite of their own sub-skills - unit, UI, end-to-end - and the thing I had to learn the hard way is that letting an agent write tests immediately is how you get tests that faithfully encode the wrong behavior. If the implementation has a subtle misunderstanding baked in, a test written against that same misunderstanding just certifies the bug.

So /test reads CLAUDE.md (or a PRODUCT.md, whatever the project's source of truth is) before writing anything, to get a real sense of what the feature is supposed to do - not just what the code currently does. That's a small thing, but it's the difference between tests that describe intended behavior and tests that describe implementation, which is exactly the distinction this project's own coding standards call out: cover user-visible behavior, not implementation details.

/handoff - make the git history someone else's friend

This stage generates the actual commits - usually more than one, split along logical boundaries - and writes a PR description worth reading. It's a small stage but it's the one that pays off weeks later, when someone (often me) is doing a dig through git blame trying to understand why a change was made. Comprehensive commit messages and a real PR description are cheap to generate at handoff time and expensive to reconstruct after the fact.

[ BAD DUMP ]:
Commit: "fix features and stuff" (1,452 lines changed) -> 🗑️

[ GOOD FLOW ]:
Commit 1: "feat: add db schema for billing" (400 lines changed)
Commit 2: "feat: implement stripe webhook handler" (1,000 lines changed)
Commit 3: "test: cover webhook edge cases" (52 lines changed)

One thing you should take away is that you should always create small & understandable commits rather than pushing 1 big commit - it saves a lot of time and money down the line if your commit happens to have a bug and you need to revert it urgently.

/prototype - spend an hour to avoid spending a week

Not everything deserves the full pipeline above. Sometimes the actual question is "can this even be built the way I'm imagining it," and the honest answer is you don't know until you try. /prototype exists for exactly that: check out a new branch first (so a failed experiment costs nothing), prompt it to build the smallest working version (or MVP - Minimum Viable Product) of the idea, and use it to answer the feasibility question directly instead of debating it in the abstract.

The golden rule of prototyping: end every prototype with an honest estimate of the gap between "this works on my machine in a throwaway branch" and "this is production-ready". Get a sense of how much effort it will take to make it production ready. Doing so every time is what keeps a fast experiment from turning into an unreviewed shortcut.

Why this is context engineering, not process theater

It would be easy to read the five commands above as bureaucracy - steps for the sake of steps. The actual point is narrower: each stage exists because it changes what's in context when the real work happens.

• Artifacts over memory. A tech doc, a task list, a CLAUDE.md - these are things any agent can read cold, in a brand-new context, and act correctly. A fact that only exists because it was mentioned forty messages ago in a chat is not durable. If a decision matters, it belongs in a file, not in scrollback.
• Narrow context beats large context. An agent given exactly the tech doc for one feature will do better work than an agent given the entire codebase's history and told to "keep the feature in mind." Relevance beats volume. This is why /dev hands off a scoped task rather than the whole project to each sub-agent, and why /test deliberately re-reads the spec instead of trusting whatever the implementation agent inferred along the way.
• Checkpoints are where humans add the most value. Verifying the task breakdown before execution, reviewing the tech doc before code, reading the PR description before merge - these are cheap moments to catch an expensive mistake. The pipeline isn't there to slow things down; it's there to put a human decision exactly where it's highest-leverage, instead of spread thin across one long conversation.

Keeping code moving forward

The failure mode I was originally describing - the 3 hour chat that ground to a halt - wasn't really about the AI running out of steam. It was about the process having no natural stopping points, so context just kept accumulating until nothing fit anymore. Splitting a workflow into stages does the same thing that splitting a big function into small ones does: it gives you seams. Seams are where you can stop, inspect, correct course, and hand off cleanly - to another agent, to a reviewer, or to your own future self picking this back up tomorrow.

None of this requires exotic tooling. It requires deciding, deliberately, what belongs in a durable file versus what's allowed to live only in a conversation - and then actually writing the first kind down. That one habit is most of what "context engineering" means in practice, and it's the reason a five-stage pipeline of narrow agents keeps shipping long after a single giant chat has quietly stalled out.