You open a new project folder, drop in a prompt, and watch the agent go. Files appear. Functions take shape. The thing starts to look like real software in twenty minutes. It feels like hiring a fast contractor who never sleeps.
Then you ask for one more feature and something breaks three files away from where you were working. The agent confidently patched the wrong function, introduced a variable name collision, and removed a comment block that was the only documentation for a piece of logic you didn't write. You don't know when it happened. You don't have a clean restore point. And the agent, asked to fix it, is perfectly willing to keep going.
That is the actual experience of vibe coding at scale. Not the twenty-minute win. The hour after it.
The supervision problem nobody names
Building software with AI agents is a supervision problem, not a coding problem.
The friction is not that agents write bad code. Often they write decent code. The friction is that agents have no stake in the project. They do not track what changed and why. They do not ask whether a new feature conflicts with an architectural decision you made two sessions ago. They do not warn you that the approach they are about to take will make the next three features harder to build.
They execute. You manage.
Most developers coming to agentic tools for the first time treat the agent like a search engine with output. Ask a question, get an answer, move on. That works for isolated tasks. It does not work when the agent is making real changes to a living codebase across multiple sessions and multiple areas of concern.
The gap between those two modes of use is where projects fall apart.
What a rules file actually does
.cursorrules. Claude Code uses CLAUDE.md. The names differ but the function is the same.A useful rules file is not a style guide. It is a working brief that answers the questions the agent will never think to ask on its own:
What stack is this project on, and which version constraints matter? What patterns are in use and which ones are off-limits? Where does business logic live versus presentation logic? What should never be modified without explicit instruction?
Without that file, every session starts cold. The agent has no memory of decisions you made before. It will reinvent approaches you already rejected and make structural choices that contradict your architecture. Not because it is malfunctioning. Because it does not know.
A rules file is not a nice-to-have. It is the foundation of any session that involves more than a single isolated task.
Version control as a save point system
Experienced contractors take photos of a job site before they start work. Not because they expect problems, but because disputes about prior conditions are expensive and photos are cheap.
Git commits in an agentic workflow serve the same purpose. Before you hand the agent a task, commit what you have. The commit message does not need to be polished. "Working state before agent session on auth module" is enough. That message is not for your future self reading the history. It is for your present self who needs a clean rollback point when the agent does something unexpected across four files at once.
The instinct many builders resist is committing unfinished work. That instinct comes from professional git hygiene built for teams. In solo agentic work, the cost calculation is different. A messy commit history costs you some embarrassment on a pull request no one else will ever see. A missing save point costs you an hour of manual reconstruction.
Commit before the agent touches anything significant. The scope of the task determines the granularity. Narrow tasks warrant a commit before and after. Broad refactors warrant commits at every logical checkpoint during the session.
The questions the agent won't ask
An agent will implement what you describe. It will not evaluate whether you described the right thing.
This is the hardest part of the general contractor model to internalize, because agents are fluent and confident. They produce output that looks considered. The reasoning trace reads like a thoughtful developer walking through a decision. But the agent is not reasoning about the project. It is reasoning about the prompt.
That means the questions that shape project outcomes stay with you:
Does this feature belong in this module, or is it trying to solve a problem that indicates a missing abstraction? Does this approach make the next three things easier or harder to build? Is this complexity I am introducing, or complexity I am inheriting from a real requirement? What breaks downstream if this changes?
None of those questions appear in the agent's output unless you put them in the prompt. And most of the time, builders do not put them in the prompt because they are not the immediate task. They are the architectural thinking that surrounds the task.
The general contractor model makes this explicit: the agent builds what you specify. You are responsible for specifying the right thing. That division is not a limitation to work around. It is the correct mental model for working with these tools.
What you give up with each approach
Two supervision styles dominate in practice.
Hands-off means you describe the outcome, the agent works, and you review the result. Speed is high. Intervention is low. The risk is drift: the agent makes small structural decisions throughout the session, none of them individually problematic, and three sessions later the codebase has taken a shape you would not have chosen. You did not notice because each individual output looked fine.
Hands-on means you break work into small scoped tasks, review outputs before approving them, and commit frequently. Speed drops noticeably. The agent spends time waiting for input. But decisions stay with you, the rules file gets updated as you discover gaps, and the codebase reflects choices rather than defaults.
Neither approach is universally correct. The determining factor is reversibility. If the work is exploratory or throwaway, hands-off is fine. The stakes are low and the speed benefit is real. If the work will persist and compound, hands-on is the only mode that keeps the project coherent over time.
Most builders use hands-off for everything and discover the problem when complexity makes the codebase hard to reason about. Hands-off vibe coding produces fast prototypes and slow-to-debug production code.
Before the next agent session
Start with the rules file open, not the chat window. Read what you wrote last time. If something changed in the project since then, update the file before the agent sees a single prompt.
Write a commit. Even if the code is messy. Even if the message is rough. A restore point has more value as an imperfect object that exists than as a polished artifact you will write after the session.
Then, before you type the first prompt, write out the task in one sentence. Under it, write the one question that, if you got the answer wrong, would send the session in the wrong direction. Answer that question yourself. Then give the agent the task.
That thirty-second process will prevent more wasted sessions than any individual technique or tooling choice. The agent is fast and capable. The limiting factor is not what the agent can do. It is how clearly you can specify what you want, and how reliably you can catch the moments when the build is drifting from the project you meant to build.
That is the job of the general contractor. The agent is the crew. You are the one who owns the outcome.