What breaks when vibe coding meets a repository other people work on

Everything about vibe coding changes when the repository has other people in it. Not because the code gets worse, but because the way it fails stops being visible.

On your own machine, a mistake shows up as something not working. On a shared repository, the characteristic failure is code that works, reads reasonably, passes review, and is wrong anyway — because it broke a rule that was never written down anywhere the model could read it.

The shape of it

An agent is asked to add a field to a form. It does, competently. It also adds a database migration, because that is what adding a field usually needs.

The migration is fine. The problem is that this team applies migrations by hand, in a specific order, after a review by the person who owns the schema — a convention that exists because of an incident eighteen months ago, is known by four people, and is written down nowhere.

Nothing in that diff looks wrong. That is the failure. It is not bad code; it is code that is locally reasonable and globally wrong, and the distance between those two is exactly the distance between what is in the repository and what is in somebody’s head.

Why does review not catch it?

Review reads the diff and asks whether it is good. This class of problem is invisible to that question, because the diff is good. The defect lives in the relationship between the change and a piece of context that is not on screen.

A reviewer catches it only if they happen to hold the convention and happen to think of it while reading. That works, sometimes, when the reviewer is one of the four people. It stops working the moment volume goes up — and volume going up is the entire point of using agents.

So the usual advice, review AI-generated code more carefully, is half right and does not scale. Careful line-by-line review of everything removes the reason to generate it in the first place.

What is the failure that costs most?

Two agents, at the same time, on the same repository.

Each is correct in isolation. Each passes its own tests. One refactors a helper the other is depending on; or both touch the same config from opposite directions; or one moves a file the other is writing to. Nothing errors. Both branches are green.

The loss shows up days later as a change that was made and then was not there any more, and nobody can say when it stopped existing. It is expensive precisely because there is no moment of failure to point at — you are reconstructing a negative from git history.

This is not hypothetical and it is not rare. It is the ordinary consequence of running more than one agent on one repository, which is now a normal Tuesday.

How do I know this is already happening?

It does not arrive as an incident, which is the difficulty. It arrives as a set of small facts that each have a plausible individual explanation:

• Work that was done and then was not there. Somebody remembers writing it. Git says it existed. Nobody can name the commit that removed it.
• The same bug fixed twice, three weeks apart, by two people who each thought they were first.
• A convention re-explained in three separate sessions, because each session started with no memory of the last one and nobody wrote it down in between.
• A pull request that touches files nobody expected, where the extra files are all individually defensible.
• “Who changed this?” answered by a commit message that says refactor and an author who was not reading closely.

Any one of these is an ordinary bad week. All of them together is the failure mode, and the reason it goes unnamed for so long is that there is no error to search for. You are looking for the absence of something, and absences do not page anyone.

What if the other people are my own agents?

The inversion that catches most people out: you do not need a team to have a shared-repository problem. Two terminals is enough.

A repository does not know that two sessions belong to the same human. Every property that makes this hard on a team is present when you are alone — concurrent writes to the same files, no shared memory between the sessions, conventions that exist only in your head — and one property is strictly worse. On a team, the second agent’s work is at least read by a different person. When both are yours, you approve both, quickly, in the same afternoon, and there is no second reader anywhere in the loop.

This is why “I am a solo developer, this does not apply to me” is usually wrong by the time somebody says it. The threshold is not the number of people. It is the number of things writing to the repository at once.

Do AGENTS.md and CLAUDE.md fix this?

The standard answer is a CLAUDE.md or AGENTS.md with your conventions in it. Do write one. It genuinely helps, and it is the cheapest thing on this list.

It also decays, for the same reason all documentation decays: it is a snapshot of what somebody remembered on the day they wrote it, and nothing forces it to be revisited when the thing it describes changes. Six months in, it is a mix of true, stale and aspirational, and an agent reading it cannot tell which line is which. Neither can a new hire.

A context file is necessary and it is not sufficient, and the gap between those two is where the interesting work is.

What actually helps?

Name the paths where being wrong is expensive. Not everything — most of a repository is genuinely safe to change, and treating it all as dangerous means nothing is. A short list of the paths that would hurt is worth more than an exhaustive one, because a short list gets read.

Give each one an owner. Not for bureaucracy: so that “should this change?” has somebody to ask. An unowned rule is a rule that gets routed around at the first inconvenience, by humans as much as agents.

Scope the work before it starts, not after. What should this do, what must it not do, which areas does it touch. Written before the code exists, that is a specification. Written after, it is an excuse.

Make it possible to see what a piece of work actually touched, as against what it said it would. That difference is where the surprises are, and it is a question git can answer if anybody asks it.

None of that needs a product. It needs the list to exist somewhere both the people and the agents can read.

What can I do on Monday, without buying anything?

In order, because doing the first two is most of the value:

1. Write down the five paths where being wrong is expensive. Five, not fifty — the point is that the list gets read. Migrations, auth, the payment code, the shared config, whatever yours are.
2. Put a name against each one. So “should this change?” has somewhere to go. It does not have to be a formal owner; it has to be a person.
3. Start every piece of work by saying what it must not touch. One line, before the code exists. This is the single highest-yield sentence in agentic development and it costs nothing.
4. Once a week, look at what actually changed against what you thought was being worked on. Not a review of the code — a comparison of two lists. The gap is where the surprises live, and once a week is enough to catch them while they are still cheap.

None of that is a product and none of it needs permission. If it turns out to matter for you, the next question is what enforces it when everybody is busy — which is where the rest of this gets interesting.

Where CommitCycle fits

That list is the thing we build on. Zones are the paths that would hurt, each with an owner and a risk level. A task declares what it touches before it starts, and moving a wall takes one approval with a reason. Each agent gets a grant bound to one task and one branch that expires on its own, so two sessions in their own worktrees cannot quietly authorise each other — share one directory and they still can, which is why the worktree is the instruction rather than a preference. Every task closes with a record of what it declared against what it touched.

Where it actually is, plainly: the enforcement installs today as a Claude Code plugin; the commitcycle package on npm puts cycle on your PATH and carries no hook, so it gives you the process without the wall. The hosted board is invitation-only while this is small. The zone model is agent-agnostic, but the enforcement point needs a small adapter per harness, and exactly one ships today.

And the honest boundary worth repeating: denying a tool call in flight is not what makes this different. Several vendors ship that and Claude Code includes it for free. The part that is ours is the grant that is bound to one task, attributed to an owner, and expires on its own — and the record afterwards that says what actually happened.

If you are one person on a prototype, none of this is your problem yet, and the first-steps post is the more useful one — or the setup, if the prototype has started looking like it will survive the month.