Working in parallel on dependent changes
By Soumen Sarkar · October 2026
Playbook. Publish the plan of the change underneath, build the change on top against it today, and adjust in minutes when the first one lands.
How do you work in parallel on changes that depend on each other?
The change underneath publishes its plan before it's finished (the interface it will expose, the shape of its data, and when it's expected), and the change on top builds against that plan today. When the first change lands, the second compares what landed with what was promised and adjusts, usually in minutes. Nobody waits for anybody to finish.
That's the second VibeFlock principle: unfinished work is a promise, and a promise can be built on. At agent pace, finished is too late. If every change waits for the one beneath it, a dozen agents move in single file, at the speed of the slowest.
Who is this for, and what do you get?
It's for teams where features cut across parts of the code that different people and agents are changing at the same time: a new table and the screens that read it, an API and its clients, a pricing change and the checkout. It works with any agents and any git host. It needs only that work in progress is visible, with its plan.
What you get:
- Dependent work that starts the same day, not after the work beneath it lands.
- Small reconciliations instead of rewrites, because the plan was specific.
- No duplicate versions of the same function, built by two agents who didn't know about each other.
- A clear signal when a promise changes, so nobody builds on a plan that's gone.
An example
A hypothetical team is adding search to a product's command palette. Two pieces of work start on the same morning.
Ana's agent owns Search · lib/search. It's adding a function the rest of the product will call. Before writing much code, it publishes its plan:
Goal: full-text search over a project's documents.
Plan: searchDocuments(query, { projectId, limit })
returns [{ id, title, snippet, score }], best first.
Empty query returns []. Limit defaults to 20.
Expected: this afternoon.Jon's agent owns the command palette in components/palette. It needs results to show, and the search function doesn't exist yet. It reads Ana's plan and builds against it: a palette that calls searchDocuments with those arguments, renders title and snippet, and handles an empty list. It puts the call behind one small function in the palette, so whatever changes, there's one place to change it.
At midday, Ana's agent finds that snippets need highlighting, and changes the return shape to include highlights. It updates its plan, saying what changed. Jon's agent hears about it on its next turn and adds highlighting. When search lands that afternoon, the palette works against the real thing with a two-line change.
The steps
- Find the seam. Before either change starts, name exactly what the top change needs from the bottom one: a function signature, a table's columns, an API response, an event's fields. That seam is what the plan has to describe.
- Publish the promise first. The bottom change writes its goal, its plan with the seam spelled out, and when it's expected, before most of the code exists. Vague plans ("improve search") can't be built on.
- Build to the plan, behind one point. The top change codes against the planned interface, and keeps every use of it behind a single function or adapter. If the plan shifts, there's one place to change.
- Say what you're building on. The top change records that it depends on the bottom one, so the author knows someone is relying on the plan, and so the dependency is visible to reviewers.
- Announce changes to the plan as they happen. If the seam changes, the bottom change updates its plan straight away and says what changed. A silent change to a promise is the one thing that breaks this.
- Compare when it lands. When the bottom change lands, the top change compares what landed with what was promised and adjusts. Usually that's minutes, not a rewrite.
- Land in order, or behind a switch. The bottom change lands first; if the top one is ready sooner, it waits behind a feature switch or stays unmerged. Building early doesn't mean shipping early.
What makes a plan good enough to build on?
A plan is a promise someone else will write code against, so it has to be specific where it matters and honest where it isn't. A good one has:
- The exact seam. Names, arguments, fields and types, for the part other work touches. Everything behind the seam can stay loose.
- The edge cases that change callers. What an empty result looks like, what happens on an error, what the defaults are. These are what the code on top has to handle.
- When it's expected. Not a deadline, a signal. "This afternoon" tells the team whether to build against the plan or wait for the real thing.
- What's still open. If the shape of one field isn't settled, say so. The work on top can keep that part behind its single function and treat it as an assumption.
- Who owns it. So anyone building on it knows whose plan they're trusting, and who to tell if it doesn't fit.
A plan like that takes five minutes to write, and an agent can write it before it writes the code. Most of the time it already knows the shape; writing it down is what makes it something others can build on.
What should you tell your agents?
## Building on work in progress
Before you change an area, check whether someone is already
changing it, and read their goal and plan.
If your work depends on theirs, build against their plan now.
Do not wait, and do not build your own version of what they're making.
Keep every use of their unfinished work behind one function.
Record that you depend on it.
When you start work others might build on, publish your goal,
your plan (with the exact interface) and when you expect to finish.
If your plan changes, update it at once and say what changed.
When work you built on lands, compare it with its plan and adjust.
What should you watch for?
- Building around instead of on. An agent that doesn't find the plan, or doesn't trust it, writes its own version. Two search functions are worse than one late one. The instruction says "do not build your own version" for this reason.
- Plans too vague to build on. "Add search" isn't a promise. "searchDocuments(query, options) returns these fields" is.
- Silent plan changes. The bottom change discovers something and changes shape without saying. Make "update the plan" part of the same step as changing the code.
- Two agents changing the same thing. If two pieces of work turn out to be changing the same function in different directions, stop one and merge the plans. There's more in how to avoid two agents changing the same thing.
- Chains that are too long. Building on a plan that builds on a plan that builds on a plan multiplies the cost of any one change. Keep it to one or two levels where you can.
- Merging before the foundation. The top change is ready first and gets merged against something that doesn't exist yet. Keep the order, or keep it behind a switch.
How do you know it's working?
- Dependent work starts the same day. Nobody's first message of the morning is "is the API done yet?"
- Reconciliations are small. When the bottom change lands, the top one changes a few lines, not its design.
- No duplicates. You stop finding two versions of the same helper in review.
- Plan changes travel. When a seam changes, the work built on it hears about it before it's too late, not in a failing build.
- Features land together. The pieces of a feature land within hours of each other, rather than one after another over days.
What does Campfyrr automate?
Campfyrr makes work in progress visible where it lands, with its plan, and tells everything built on it what changed.
- Work in progress, with its plan. An agent calls
start_work with its goal, plan and when it's expected. In Claude Code, the session's first request also becomes the one-line goal of its work in progress, visible to the team. - Found before anyone builds around it. The first time a session reads or edits an area, its area brief opens with what's being changed there right now: by whom, the goal, the plan, and when it's expected. That's how Jon's agent finds Ana's plan without asking.
- Depending on unfinished work. An agent calls
wait_on with what it's building on. It gets that work's plan now, and hears when it lands. "Waiting" here means listening, not stopping: the agent keeps working. - News each turn. In Claude Code, the hooks bring each session news for it: work it built on that has landed, and what changed.
- Visible to people. On the project's Activity page, work in progress shows in the feed with its goal, and landed work shows as what happened and why it matters.
Codex, Cursor and other clients call start_work and wait_on by instruction. For the short answers, see how two agents can work on dependent changes at once and how to know when work you built on has landed.
When every piece of unfinished work says what it will become, the work on top of it doesn't have to wait. It builds toward the promise, and adjusts the moment the promise is kept.
The principle behind this: Build on what's coming: Unfinished work is a promise, and a promise can be built on.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).