The model writes a feature in seconds. Then a senior engineer spends the
afternoon reading it, because nobody trusts what came out. The time you saved writing, you spend again checking.
And things still slip through, because a tired human reading generated code is exactly the wrong tool for the
job.
where the review moved
The gate sits before your branch.
The model commits as fast as it can write. Each commit is checked against the
spec at the gate. What holds goes on to main, already reviewed. What drifts is turned back at the commit, before
a person ever has to read it.
one commit · four checks against the spec · pass all and it's on main, fail one and it comes back with the reason
what the gate checks
Not the style. Whether it's true.
A linter checks how the code looks. The gate checks whether it does what the
spec asked and whether every part it leans on is real.
imports resolve
Every symbol the code calls is checked against what actually exists. The hook the model invented
because it felt like it ought to exist is caught here, not at runtime.
meets a check
The change has to satisfy an acceptance check from Rehearse. If nothing in the spec asked for it,
that is a flag to look at, not a feature to merge.
stays in scope
It touches only what the spec scoped. A change that quietly edits a file it had no reason
to reach gets turned back with the diff attached.
traces to the ask
The commit carries a line back to the requirement that asked for it. Six months on, the answer to
"why is this here" is already written down.
what you get
Pull requests that arrive already checked.
works with your stack
Bring the repo you have. The spec is built from your code and your requirements, not a green-field
template you have to bend your project to fit.
gated, step by step
Work advances one gate at a time. Each step passes before the next opens, so a branch never gets
large and wrong at the same time.
drift refused at commit
Anything that strays from the spec is turned back before it hits your branch. The catch
happens at commit, not in production, and not in a reviewer's inbox.
a record of why
Every change traces back to the ask. When a teammate asks why the code is like this six months on,
there is an answer, and it is written down.
Let the model go fast. Just don't let it ship on faith.
where it sits
This is the Author stage.
Writing code is one stage of a longer pipeline. It builds against a spec that
Capture wrote and checks that Rehearse set, and it hands off to Field and Track once it holds. You can start here,
with the repo in front of you, and pick up the rest when you need it.