Spend review time on the changes that need your judgment.
AI assistants write large pull requests fast. SwiftProof tells you which lines to read first: it maps the diff to risk signals, runs your checks in disposable containers, tries to reproduce issues with differential tests, and hands you a focused review plan with traceable evidence.
Latest v0.3.0 · Works without an AI provider · Never auto-approves a pull request.
$ swiftproof lint HEAD~1..HEAD
5 files, +120/-5 lines; 21 risk signals; 0 reproduced issues.
Focused review: 19 / 125 changed lines
(a prioritization aid, not a correctness guarantee).
Changed-line execution: not measured.
Reports: /home/you/shop/.swiftproof# Read the flagged lines first$ cat .swiftproof/CONFIDENCE_REPORT.md
Tests, vet, build and coverage all passed on this change. It also dropped the refund amount validation and let the support role issue refunds. SwiftProof put both at the top of the review plan, among 19 flagged lines out of 125.
Why it saves time
Stop reading AI-generated diffs top to bottom.
The expensive part of reviewing an AI-assisted pull request is not the risky lines. It is finding them among the helpers, tests and docs around them, then working out whether a suspicion is real. SwiftProof does that sorting and gathers the evidence before you open the diff.
Without SwiftProof every line, same attention
Check out the branch and run tests, vet and build by hand.
Read 125 changed lines in file order, helpers first.
Notice, with luck, that a validation call vanished from a refund path.
Write a throwaway test to find out whether it matters.
Approve without a record of what was actually checked.
With SwiftProof risk first, evidence attached
Checks already ran in an isolated container, with logs and hashes.
Open the report: 19 flagged lines, ranked by severity, with reasons.
Start with payment/refund.go, where the report shows the removed validation.
Let the optional reviewer try to reproduce the issue on base and candidate.
Keep the Markdown and JSON reports as the review record.
Less to read first
A deduplicated review surface counted in real changed lines, so large generated changes shrink to the parts that touch authentication, payments, validation, dependencies or public APIs.
No local setup per PR
Your test, typecheck, build and coverage commands run in disposable, network-less containers. Nothing of the candidate executes on your machine.
Know when to stop
Unverified areas and incomplete checks are listed explicitly, and --ci turns them into an exit code. You know what was covered and what still needs your judgment.
Example report
What you open instead of the raw diff
Excerpt of .swiftproof/CONFIDENCE_REPORT.md, produced by swiftproof review HEAD~1..HEAD --reviewer=false --ci (v0.3.0) on a small shop repository. The commit added catalog helpers with tests, reworked refunds and touched authorization. No AI provider was used.
.swiftproof/CONFIDENCE_REPORT.md
## Change Summary
120 additions / 5 deletions · 5 files changed
Exit code: 2. No confidence percentage is assigned.
## Automated Checks1
- PASS test (check-1; exit 0; 5982 ms)
- PASS typecheck (check-2; exit 0; 4866 ms)
- PASS build (check-3; exit 0; 2835 ms)
- PASS coverage (check-4; exit 0; 6416 ms)## Reproduced Issues2
No issue was reproduced by a passing baseline
and failing candidate experiment.
## Suggested Human Review3
- high auth/auth.go:7 (new): Authentication or
authorization function body changed
- high payment/refund.go:21–22 (new): Payment-sensitive
function body changed
- high payment/refund.go:25–26 (new): Exported Go
declaration added; Payment-sensitive function body changed
- high payment/refund.go:21 (old): Configured sensitive
path changed; No nearby test file changed;
Possible input validation removed
- medium catalog/format.go:9 (new): Exported Go
declaration added
… 11 more medium signals in catalog/## Review Surface4
Focused review: 19 / 125 changed lines.
## Changed-line Execution5
Of 67 added Go lines, 44 were executed at least once,
0 were not executed, 23 are not inside any
instrumented block.
Checks are done, and they are not the answer. Every configured command passed in an isolated container. That is exactly why the rest of the report matters.
Evidence, not opinions. A reproduced issue needs a test that passes on the base and fails on the candidate. Without an AI provider nothing is claimed here, and the report says so.
Your reading order. High signals first: an authorization rule and a refund path changed, and a validation call was removed with no nearby test change. That is where the bug is.
The size of the job. 19 of 125 changed lines carry a signal. Read those first, then decide how much of the rest deserves attention.
An observation, not a proof. The new refund code ran during the tests, yet no test asserts the amount check. SwiftProof reports execution but never presents it as proof that the code is tested.
How it works
Compare immutable commits
Both refs resolve to commit IDs. Renames, deletions, binaries and merge-base semantics are handled; only committed files are reviewed, so local edits never leak into the result.
Collect risk signals
Go AST comparison, labelled lexical heuristics and sensitive-path rules flag authentication, payments, dependencies, removed validation, unsafe constructs and missing tests.
Execute in a sandbox
Your test, typecheck and build commands run as argv arrays in disposable, non-root, network-less containers with CPU, memory, PID and time limits.
Reproduce, don't assert
An optional reviewer writes temporary tests. A test that passes on the baseline and fails on the candidate supports a reproduced issue; anything else stays UNVERIFIED.
From a first try to every pull request
Try it on your last commit with no configuration, no Docker and no API key. When you adopt it, commit a policy to your base branch: it is read from the base, so a pull request cannot loosen its own rules.
# try it: compare with the previous commit
swiftproof lint HEAD~1..HEAD
# adopt it: once, in your repository
swiftproof init
git add .swiftproof.json && git commit -m "Add review policy"
# on every pull request
swiftproof review --base main --ci
Capabilities
Focused review surface
Deduplicated review ranges with old and new coordinates, counted in actual changed lines, ranked by severity.
Differential evidence
Generated tests run on baseline and candidate in fresh environments. Go execution is verified from structured test events.
Changed-line execution
Optionally measure which added Go lines a recorded run executed — reported as an observation, never as proof of testing.
Bounded AI reviewer
Bring any OpenAI-compatible provider. Tools are bounded: redacted file reads, search and test runs. No shell, no URL fetcher.
CI ready
A reusable GitHub Actions workflow, meaningful exit codes, and JSON reports with commit IDs, evidence and artifact hashes.
Agent friendly
Coding agents run lint and review before handing work over, and report what was reproduced and what remains open.
What SwiftProof does not claim
A review tool earns trust by being precise about its limits. SwiftProof assigns no confidence percentages and never approves a pull request on its own.
Signals are reasons to investigate, not confirmed bugs.
Passing tests and a small review surface are not correctness guarantees.
An executed line is an observation, not proof that it is tested.
A model's assertion is never evidence; only a reproduced difference is.
Execution never falls back to your host when Docker is missing.
Put your review time where it matters.
Single static binary. AGPL-3.0 licensed. Git required; Docker only to execute repository code.
