Published August 23, 2026
In the AI-native SDLC, agents write most of the code and run the first review passes, so the bottleneck moves from writing to the approval gate. RedMirror Reflection is the verification layer at that gate: it proves whether AI-generated code can reach a state it should not, and hands back a concrete reproduction. Humans then review proofs, not guesses.
This piece maps onto Anthropic’s AI-native SDLC playbook, which describes six stages rebuilt around agentic work while humans stay accountable at the gates. We take that framing as given and answer one question: where does verification belong?
The playbook’s central observation is that code is no longer the bottleneck. When an agent writes most of the diff and runs the first review passes, the constraint shifts to human-speed approval. A gate is only as good as what it can trust, and a pile of severity-ranked opinions still needs a person to decide which ones are real. That is the gap a verification step fills.
The playbook lays out six stages: plan, design, build, test, deploy, and maintain. Agents move through them quickly, drafting specs, generating plans, implementing code, running review passes, and watching production. Human judgment stays above the loop, reserved for the decisions that need it. The catch is volume. Once agents produce more change than any reviewer can read line by line, the old habit of eyeballing a diff stops scaling, and the review passes that replace it are still opinions until something checks them.
Verification is not a seventh stage bolted on at the end. It threads through the pipeline, and it earns its keep at test and deploy, where a change is about to become real.
| Stage | What agents do here | Where Reflection fits |
|---|---|---|
| Plan | Turn an idea into an accepted plan. | Name what must hold. The properties you will later verify (who may act, what must be conserved, what order is legal) are decided here. |
| Design | Collapse requirements and design into one session. | Those properties become explicit invariants instead of tribal knowledge, ready to check against the implementation. |
| Build | Implement against the accepted plan. | The coding agent proposes suspected bugs as it writes. Reflection stands ready to confirm or dismiss each one. |
| Test | Continuous evaluation woven through implementation. | The kernel searches every reachable state and proves whether a logic or state bug is reachable, with a reproduction. Zero tokens for the structural half. |
| Deploy | Layered review, then a governance gate. | Gate the pull request on proven bugs, not ranked opinions. A change that reaches a bad state fails; a bounded proof lets it through. |
| Maintain | Autonomous monitoring closes the loop. | Re-verify on every change. A later diff that breaks an invariant a past release upheld is caught the next time the gate runs. |
Because the arithmetic changed. A reviewer who could read a day’s worth of human commits cannot read a day’s worth of agent output, and skimming faster just means missing more. The playbook’s answer is layered agentic review, with human attention reserved for regulated and critical code. That is the right shape, but it leaves a question open: when an agent flags fifteen possible issues ranked by severity, which are real? Someone still has to decide, and that decision is the new bottleneck. Verification removes it for the class of bugs it covers, because a proven finding needs no second opinion.
Reflection models the subsystem as a state machine: the fields that vary, the transitions that can fire, and the invariant that must never break. A compiled kernel then explores the reachable states. A finding is a concrete sequence of steps that drives the code into a state it should not reach, an attack path you can replay, not a hunch. When no such path exists within the budget, you get a bounded proof instead. The kernel, not the model, decides, which is why a small or local model is enough to drive it. In our benchmark, that design held precision steady even with weak models in the mix.
They answer different questions, and they compose. A linter pattern-matches syntax and style. An AI reviewer reads the diff and offers an opinion about what looks risky. Reflection asks whether a specific bad state is actually reachable, and proves the answer either way. It sits after the first two, at the gate, and turns their signal into something a human can act on without re-reading the code.
| Layer | Question it answers | What you get |
|---|---|---|
| Linter / SAST | Does the code match a known-bad pattern? | Syntactic warnings, often noisy on logic bugs. |
| AI reviewer | What looks risky in this diff? | Ranked opinions a human must triage. |
| Reflection | Can the code reach a state it must not? | A replayable proof, or a bounded proof of safety. |
The bugs Reflection is built for are the ones that slip past the first two layers: missing authorization, broken object-level access (IDOR), value that is not conserved, illegal ordering, unbounded growth, and integer under- and overflow. These are logic and state bugs, not typos, and they are exactly the shapes an AI writes confidently and a linter waves through.
Reflection ships as a single offline binary and speaks the Model Context Protocol, so your existing coding agent drives it. Install it, activate a licence, and point it at the agent you already use.
curl -fsSL https://dist.redmirror.io/install.sh | sh redmirror-reflect license activate <key> redmirror-reflect init claude # or cursor, codex, gemini, windsurf, pi, ci, ...
For the deploy gate, run it in CI and fail the pull request only on findings the kernel has proven. It covers JavaScript, TypeScript, Python, Go, Rust, Java, C#, Ruby, PHP, and C++, and everything stays on your machine, so neither your code nor your model leaves it. See the reference on gating pull requests on proven bugs and on the verify step for AI-written code.
Reflection is the verification layer at the test and deploy gates. After a coding agent writes and self-reviews a change, Reflection proves whether the code can reach a state it should not, such as a missing authorization, an IDOR, broken value conservation, or unbounded growth. It returns a concrete reproduction or a bounded proof, so the person at the gate reviews proven findings instead of ranked guesses.
Because code is no longer the bottleneck. When agents write most of the diff and run the first review passes, a person cannot read every line, and severity-ranked opinions still need a human to judge which are real. A verification step answers that mechanically: it either produces an attack path that reaches the bad state, or a proof that none exists within the budget.
Agentic review produces opinions ranked by severity, where a model decides what looks risky. Reflection produces proofs: a compiled kernel, not the model, decides a finding is real by reaching the bad state with a reproduction you can replay. It complements the review passes already in the pipeline by giving the gate something it can trust without re-reading the whole diff.
The structural half of the check costs zero tokens because the kernel does it, not a model, and it runs as a single binary on your own machine, so nothing is uploaded. You spend model tokens only when your own agent proposes what to check, and a small or local model is enough because the kernel is the gate that decides.
Yes. Reflection can run in CI and fail a pull request only on findings it has proven, so the deploy gate blocks on reachable bugs rather than on style warnings or unverified alerts. Proven means the kernel reached the bad state and can reproduce it.
Reflection is the verify step for the AI-native SDLC, and it runs entirely on your own machine. Install the binary, point it at your code and your own model, and your coding agent finds real bugs and proves each one. A free 7-day trial, no card, then $4.99/month, cancel any time.
Put a verification gate between your agents and production, without sending a line of code to a vendor.
Get started · 7-day free trial The code-review bottleneck →