author · the code stage

AI writes it.
It doesn't get the last word.

Author is where the code gets written, one gated step at a time, against a spec it has to answer to. This is the fast part. It just can't ship on faith.

Request access
the problem

AI saved you an hour. Review took it back.

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.

what it catches

One piece it leaned on never existed.

The code looks right. It imports a hook that was never real, traces to a slot on the reference that holds nothing, and a human review slides right past it. The check does not.

three imports trace to a real hook · the fourth traces to nothing
how it stays on contract

Gated, step by step.

written to the spec
Every change answers to the spec from Capture, not to a vibe. The model has a target that is written down, not guessed at.
checked at each step
Work advances one gate at a time. Each step has to pass before the next opens. Nothing lands because it looked fine.
drift turned back
Anything that strays from the spec is refused before it hits your branch. The catch happens at commit, not in production.
a record of why
Every change traces back to the ask. When someone asks why the code is like this, there is an answer, and it is written down.

This is where the vibing happens. It's just bounded.

where the work happens

In your editor. Reviewed as you go.

Author runs where you already work. The model proposes a change, you run it, you see it, you change it. The difference is the review. It does not wait for a pull request at the end. Every step is checked against the spec the moment it's made, so the review keeps pace with the writing instead of piling up behind it.

propose
The model writes the next change against the spec, not against a vibe.
run and see
You run it and watch it work, in the editor you already have open. No context switch to decide whether to trust it.
reviewed at the step
The gate checks the change the moment it lands, not days later in someone's queue. Review is continuous, not a bottleneck at the end.
you keep the last word
You direct it, accept it, or turn it back. The speed is the model's. The call is yours.
why you can trust the catch

Whatever writes the code shares its blind spots.

A model that reviews its own output brings its own mistakes to the review. So the checks that catch drift are the ones that owe the code nothing. The maker writes it. A pilot re-checks every step against the contract. A watcher, outside the whole system, checks the pilot.

See the three checks
what happens when it drifts

It doesn't paper over. It stops.

Most tools smooth a bad line into something that compiles and move on. Author does the opposite. When a change can't tie back to the spec, it halts, and that refusal is the point.

it halts
The step stops instead of shipping. Not a warning buried in a log. A hard stop, at the commit, before the branch ever sees it.
it names the reason
The refusal says what broke. The import that resolves to nothing, the change that touched a file it had no business in, the requirement it can no longer satisfy.
it repairs to real ground
The fix is not a better guess. The line is rewritten to something that actually exists, and the claim lands where you can check it.
or it escalates
If there is no honest repair, it comes back to you with the reason instead of inventing one. A stop you can act on beats a pass you can't trust.
where it sits

Author is one stage of five.

The spec it builds against comes from Capture. The checks it has to pass come from Rehearse. It is one stage on a track that runs from a rough ask to a proof at the end.

See the whole pipeline