Version: v0.7 Draft
Status: Proposed human-led operating protocol for coding agents
Author: Timur Yusupov, PhD
SABRE is a compact way to use coding agents without letting one agent write, explain, and bless its own change.
Core rule:
One agent builds. Another agent challenges the uncommitted Git delta. The human owns scope, risk, and handoff.
SABRE is a disciplined habit: small slices, separate review, recorded findings, explicit handoff.
Coding agents are useful. They are also very good at producing confident change sets with confident explanations.
That is the danger.
A single agent should not be author, narrator, and judge of its own patch.
SABRE splits those roles:
- the builder implements one approved slice;
- the reviewer challenges the actual Git delta;
- the human decides what is in scope, what risk is acceptable, and when the work lands.
The unit of work is not a grand plan. It is a reviewable slice.
Before committing, ask another coding agent to review the uncommitted changes with a critical eye:
Review uncommitted changes. You are red team. Be critical.
This is minimal adversarial review, not full SABRE. It has value, but it leaves little audit trail.
Full SABRE keeps the slice, findings, fixes, checks, verdict, and residual risks in a daily record.
-
Start by scoping the work in dialogue with a coding agent.
-
Ask the coding agent to split the work into small slices and store them in today’s progress file:
Create a new progress file for today at docs/progress/YYYYMMDD.md.
Record the scoped work as small implementation slices.
Each slice must include:
- goal;
- why;
- affected modules/files;
- non-goals;
- acceptance criteria;
- risk class;
- reviewer focus.
Keep slices narrow. Do not add new scope. If something is unclear, mark it as an
open question instead of guessing.
- Ask another coding agent to review the proposed slices:
Review proposed slices. You are red team. Be critical.
Focus on scope, clarity, risk, acceptance criteria, and whether each slice is
small enough to review in one bounded session.
-
Human reviews the progress file. When satisfied, the human approves the slice list.
-
Ask the builder to implement one slice:
Implement Slice 1.
- Ask the reviewer to inspect the uncommitted changes:
Review uncommitted changes. You are red team. Be critical.
- Copy the findings back to the builder:
Fix it:
[paste reviewer findings here]
- Ask the reviewer to recheck the full current diff:
Fixed. Review the full current diff again.
-
Repeat until the slice is accepted, split, risk-accepted, or abandoned.
-
Commit, PR, or hand off using the project’s normal process.
-
Swap builder/reviewer roles for the next slice.
SABRE is not there to slow the work down.
It is there to stop bad work from moving fast in a convincing voice.
Context: I have observed that when two agents are allowed to iterate without human supervision -> they more often then not move horizontally perfecting one slice while pushing other slices back.
The horizontal "drift" you mentioned is exactly why autonomous multi-agent loops break down in production.
When you leave a builder and a reviewer agent completely unconstrained, they enter a cycle of diminishing returns. Their local objective functions force them to endlessly refit, reformat, and polish a minor task to satisfy every microscopic critique. They lose all macro-level situational awareness, meaning the immediate slice gets "perfected" over 15 iterations while the remaining features are pushed entirely out of the context window.
Inserting a forced manual bridge—even just via physical copy-pasting—fixes this in three ways:
Passive Auditing: The physical act of moving text forces a human-in-the-loop glance across the implementation delta. It provides a low-fatigue, high-signal understanding of the project's trajectory without needing a heavy code review.
Vertical Driving: It keeps the human as the strategic circuit breaker. You retain the authority to say: "The reviewer's point is technically valid, but this code is good enough for this slice. Disregard and move to the next milestone."
Token/Context Protection: It physically prevents agents from burning through massive token budgets on trivial, pedantic internal arguments.
Automation is a great long-term goal, but until agents understand "good enough to ship," keeping the human as the manual text bridge is the only reliable way to keep a project moving forward instead of sideways.