Fix forward: correct the course, don't guard the gate
By Soumen Sarkar · October 2026
We don't guard the gate. We correct the course.
What does it mean to fix forward?
Fixing forward means catching mistakes early, while they're small, and correcting them in the flow of the work instead of stopping the work to prevent every one of them up front. It's the third VibeFlock principle: we don't guard the gate, we correct the course.
No team that moves at agent pace will be perfect. What it can be is honest, quick and accountable. That isn't lowering the bar. It's how the bar gets raised, every day.
Why does it matter at agent pace?
Because a gate turns every change into a wait. When a small team lands dozens of changes a day, a gate that holds each one until someone has checked everything about it becomes the slowest part of the team. Changes queue. Agents stall. And the reviewer, faced with a pile, reads less carefully, not more.
Gates also catch mistakes late. By the time a change reaches the gate, the wrong assumption inside it has been built on for hours. Fixing it means unpicking everything stacked on top.
Fixing forward moves the attention earlier. The aim isn't fewer checks. It's checks that happen as the work happens: a wrong assumption caught in the first hour, a clashing decision caught the moment it's made, a change reviewed by what it was for and what it assumed. Mistakes still happen. They just stay small.
What keeps a mistake small?
Three things, and none of them is luck. The mistake has to be visible: an assumption that was stated, a decision that was recorded, a change that carries its reasons. It has to reach the right person quickly: the one who knows billing sees the billing assumption, not a general queue. And the work around it has to be easy to adjust: the risky call kept in one place, so changing it means a few lines rather than a rewrite.
When all three are true, a wrong call costs minutes. When any one is missing, the same wrong call quietly grows until somebody trips over it.
What does it look like in a working day?
Take a scenario: a four-person team with about a dozen agents, shipping a new annual plan.
Mid-morning, one of Priya's agents is building the checkout summary. It doesn't know whether tax should be shown separately on the annual total, so it assumes yes, says so, and keeps going. Tomás, who owns billing, sees the assumption an hour later. It's wrong: on annual plans the team shows one total, tax included. He corrects it in a sentence.
The agent hears the correction on its next turn. It changes the summary, and says what it changed and why. Total cost: a few minutes, because the assumption was named and visible while the work was still fresh. Had it been a silent guess, it would have surfaced at review, or worse, on a customer's receipt.
That afternoon there's a second kind of mistake. Maya's agent, working on the pricing page, decides to show the annual discount as a percentage. But a standing decision from two months ago says savings are always shown in currency, because customers found percentages hard to compare. The clash is caught the moment the new decision is recorded: the newer call stands, the older one is marked replaced, and the change shows in the feed. Maya reads both reasons, records the currency rule again, and the agent follows it. Nobody shipped the inconsistency, and nobody had to stop the work to find it.
When the changes go up for review, Sam reads each one by its reasons: what it's for, the calls made, what was assumed and what was corrected along the way. He spends his attention on the one change that touches how annual renewals are charged, and moves quickly through the rest.
What do people do?
You fix what you find, where you find it, and you say why. In practice:
- Correct, don't block. When you see a wrong assumption, correct it in a sentence. The work keeps going in the right direction.
- Review by reasons. Start with what a change was for and what it assumed. That's where most mistakes live. See reviewing a pull request an agent wrote.
- Say why when you fix. A fix with a reason teaches the next agent. A fix without one gets undone.
- Spend attention by stakes. Look hardest at the changes that touch money, data, access and public interfaces.
What do agents do?
An agent changes course the moment it learns it was wrong, and says what it changed. It doesn't defend the earlier call or quietly patch over it. It reads the correction, adjusts the work, and records what changed so the reviewer and the next agent can see it.
Isn't this just shipping anything and cleaning up later?
No. Fix forward is not "ship anything". It's a bet that most mistakes are cheap to correct when caught early, and that catching them early beats trying to prevent them all at a gate. That bet holds for most work. It doesn't hold for all of it.
- Some mistakes can't be fixed forward. Deleted data, a customer charged twice, a broken public interface others depend on. These deserve a careful look before they happen, and they get it first.
- Tests and checks still run. Fixing forward is about how people spend their attention. It doesn't replace the automated checks a team relies on.
- Small only works if it's early. A mistake found in the first hour is small. The same mistake found after a week of work on top of it isn't. Fixing forward depends on things surfacing fast.
- Honesty is the price. It only works if people and agents say plainly what they assumed and what they got wrong. A team that hides its mistakes can't fix them forward.
For more on keeping the standard high at volume, see quality at hundreds of changes a week.
How does Campfyrr make it hold?
Campfyrr doesn't approve or block anything. It makes mistakes visible early, so the fixes stay small.
- Assumptions are on record as they're made, and each one has its own page, linked from the Activity feed, where the person best placed to check it answers in one click: "Right, keep going", the likely answers, or "Correct it…". A correction reaches the agent at its next turn.
- High-stakes assumptions come first. Anything touching data, money, access, public interfaces or deleting things is marked "High stakes" and shown at the top.
- Decisions are checked as they're recorded. A new decision is checked against the ones that stand, and when one clashes, the newer call stands, the earlier one is marked replaced, and the change shows on the Activity page.
- Every change carries its reasons. On commit or pull request, the change's reasons are written for the reviewer: what it's for, the calls made, what was assumed and what was tried and dropped.
- The team can see if it's working. A weekly card on Activity counts clashes caught and wrong assumptions caught.
What does a team gain?
A team that fixes forward spends its care where it counts. Most mistakes are caught in the flow of the work and cost minutes. The few that can't be undone get a person's full attention, first.
We don't guard the gate. We correct the course, quickly and honestly, and the bar goes up every day.
Questions this answers
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).