How do teams keep quality high at hundreds of changes a week?
By Soumen Sarkar · October 2026
Short answer: Teams keep quality high at hundreds of changes a week by putting their attention where mistakes are expensive, making every change carry its reasons, catching wrong calls early while they're small, and fixing forward in the flow of the work instead of slowing every change at the gate.
Can every change get a careful review?
Not with equal care, and trying makes things worse. At hundreds of changes a week, a team that reads every line of every change either becomes the bottleneck or starts skimming everything. Skimming everything is how the one dangerous change gets through.
Quality at volume comes from deciding where care goes, and making the rest cheap to fix.
Where should care go?
To the changes where a mistake is expensive to undo:
- Data: migrations, deletions, anything that changes what's stored.
- Money: prices, billing, payouts, refunds.
- Access: who can see or do what.
- Public interfaces: APIs, events and file formats other people depend on.
A mistake in a tooltip costs a minute to fix after it lands. A mistake in a migration can cost a weekend. Treat them differently on purpose, and say so in the team's agent instructions.
What keeps the rest safe?
Four practices, none of which need a gate:
- Tests and CI on everything. Agents write tests quickly; make them part of every change.
- Reasons on every change. What it's for, the calls made, what was assumed. A reviewer can check a change's thinking in a minute.
- Assumptions stated, not buried. The risky guesses are visible, so the person who knows can correct them early.
- Small fixes, fast. When something's wrong, fix it in the next change and say why, instead of reverting the world.
What does that look like in a real week?
Picture a hypothetical four-person team running twelve agents on a public API, about two hundred changes a week. Most of them are endpoint tweaks, docs and tests, which merge once CI passes and the reasons read sensibly.
On Wednesday one change alters the rate-limit response in API · lib/api/limits, a public interface. Its reasons flag an assumption, "clients ignore the Retry-After header", as high stakes. The lead reads that change slowly, knows two large clients rely on the header, and corrects it. The agent keeps the header, adds a test for it, and the change merges the same afternoon.
That one change got twenty minutes of attention. The other hundred and ninety-nine got the minute each deserved.
Where does Campfyrr help?
Campfyrr doesn't run CI and doesn't approve or block anything. What it adds is the context that makes this split work: every change's reasons, written in Claude Code at commit or pull request; high-stakes assumptions marked and shown first; decisions that clash caught the moment they're logged, with the newer call standing; and a weekly card on the Activity page counting wrong assumptions and clashes caught.
The measure to watch is rework: work done twice because a mistake was found late. At agent volume, quality means catching things while they're still small.
Words used here
- High-stakes assumption: A high-stakes assumption is an assumption that touches data, money, access, public interfaces or deleting things, so being wrong costs more and it should be checked first.
- Reasons: Reasons are what a change is for, the calls made in it, and what was assumed, attached to the change for whoever reviews it.
- Correction: A correction is the fix to a wrong assumption or call, made by someone who knows better and sent back to the work that relied on it, without stopping anyone.
- Rework: Rework is work done again because it was built on something wrong: a mistaken assumption, a clashing decision, or a plan that changed without anyone hearing.
The principle behind this: Fix forward: We don't guard the gate. We correct the course.
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).