Find likely issues
Spot suspicious code, common bugs, and missed edge cases for a reviewer to inspect.
AI code review vs governed delivery
Review tools inspect the diff. SDF runs the loop before merge.
AI code review tools inspect code after generation. SDF starts earlier with the executable verification loop: scope, receiver-owned guidance, configured checks, evidence, risk, limits, and reviewer handoff stay visible while the change is being shaped.
The difference is timing and context. SDF makes intent, scope, acceptance criteria, standards applied, risk, executed checks, verification truth, and human ownership visible while the change is still being shaped.
SDF is not an AI code review bot. The SDF CLI is the executable mechanism; the installed front door is the repo-local operating layer.
The real problem
The PR should not be where trust is invented.
Buyer signal
The same pattern shows up quickly once teams let agents write more production-bound code.
- More generated work reaches review. Reviewers need the missing context earlier.
- Diff comments are not enough. Teams still need scope, evidence, and ownership.
- Leaders want control without tool lock-in. Governance has to work around the AI tools already in use.
These are problem signals, not Software Dark Factory performance claims.
AI-assisted development can put more work in front of reviewers. Inspecting code after generation is only one part of the problem.
The harder question is whether the agent understood what clean code, TDD, refactoring, architecture boundaries, and team patterns mean in this repo before it turned ambiguity into code.
unclear intent
thin acceptance criteria
weak verification evidence
unknown AI contribution
hidden risk or scope drift
reviewers rebuilding context
Where review tools help
AI code review is useful. It is not the whole control system.
AI code review tools can catch likely mistakes, suggest local improvements, and give reviewers a faster first pass after code exists.
SDF does not replace reviewers, code review tools, static analysis, CI, security review, or engineering judgement. It helps the work arrive with captured context, executed checks, evidence, and boundaries those decisions need.
Improve local code
Suggest simpler structure, naming, style, or small refactors inside the diff.
Reduce first-pass load
Give early feedback before scarce human attention goes deep.
Where review tools stop
The missing question is whether the work is ready for review.
Most review tooling begins when the diff exists. By then, the agent has already chosen implementation shape, followed or invented patterns, made test decisions, and turned ambiguity into code.
SDF starts earlier so the first governed change arrives through a reviewable proof loop: the PR shows captured context, acceptance criteria, risks, limits, executed verification, and a checked reviewer handoff before the team decides whether to merge.
What was the change supposed to do?
What boundaries kept it small?
Which repo patterns and standards shaped it?
What checks actually ran?
What risks and limits remain?
What does the human reviewer still need to decide?
AI code review vs governed AI-assisted delivery
SDF sits around the tools your team already uses.
Codex, Claude Code, Cursor, Copilot, and whatever comes next can all help produce work. CI, static analysis, code review, and security review still matter.
SDF is the governed delivery layer around that ecosystem: team standards shape the work, evidence records what happened, verification shows what ran, and people still make the decision.
AI code review
Useful feedback on the diff
- When it starts
- After generation, when code exists and the PR is ready for comments.
- Primary question
- Does this code look okay?
- Reviewer context
- Inline comments, style suggestions, and local issue spotting.
- After merge
- Comments usually stay attached to the diff and review conversation.
- Decision boundary
- Can inform review, but should not decide what ships.
Governed delivery
Evidence around the change
- When it starts
- Before and during the change, while standards, tests, scope, and evidence can still shape the work.
- Primary question
- Is this change acceptable, with enough context, evidence, verification, and open decisions for a human merge decision?
- Reviewer context
- Intent, acceptance criteria, executed checks, verification truth, risk notes, limits, and evidence links.
- After merge
- The evidence archive remains durable, and post-merge finalisation is explicit when a team configures it.
- Decision boundary
- Keeps approval, merge, deployment, repair, and acceptance with the team.
Who this is for
For leaders who can see the review gap forming.
This page is for CTOs, engineering leaders, tech leads, Staff Engineers, and platform teams adopting AI-assisted engineering.
If the team already has review tools but still lacks delivery evidence, SDF is the product to evaluate; the installed front door is the repo-local layer it runs against.
AI output is rising
More generated work reaches human review.
Context is scattered
Intent, scope, and testing are hard to reconstruct after the fact.
Control must stay human
Review, approval, merge, and engineering judgement remain with the team.
How SDF helps
Assessment, first governed change, team operating model.
The buyer path starts with readiness and assessment. If the evidence supports it, the next proof is one bounded first governed change.
That first governed change proves the loop: a bounded change shaped by standards, examples, playbooks, test expectations, verification truth, evidence, risks, limits, and a checked reviewer handoff in one surface.
A useful proof can then become a team operating model: receiver-owned guidance, configured checks, evidence expectations, and reviewer handoff habits adapted to the repo.
Before the PR
Scope, acceptance criteria, repo patterns, playbooks, design expectations, risk, and verification expectations are captured before the diff hardens.
Inside the PR
The reviewer sees what changed, which standards shaped it, which checks executed, what remains uncertain, and what is not being claimed.
After the proof
A useful first proof can inform the team's repeatable operating model for the repo.
Always complementary
SDF does not replace AI code review, CI, static analysis, security review, or human judgement.
Next step
Use AI code review. Do not stop there.
Start with the free readiness check if fit is unclear. Use the assessment journey when you need the path to a first governed change.
AI code review helps with comments on the diff. SDF runs the executable verification loop before merge, helping teams get AI-assisted changes into a reviewable, evidence-backed, merge-ready state faster, with context, executed checks, limits, and reviewer handoff visible.