No. A claim that a product generates fixes shows it can open pull requests, not that teams merge them or that the fixes work. Ask for four numbers on a sample like yours: fixes proposed, fixes that passed tests, fixes merged and fixes later reverted. Then measure the same on your own repositories.
The funnel behind the claim
A fix passes through several stages before it matters, and each stage loses some:
- Proposed: the tool opens a pull request or patch.
- Builds: the change compiles and installs.
- Passes tests: your test suite succeeds with the change.
- Reviewed: a person looks at it and understands it.
- Merged: it lands in the main branch.
- Holds: it is not reverted later.
A vendor may quote the top of the funnel because it is the biggest number. The bottom is what you pay for.
Questions to ask
| Question | Why |
|---|---|
| What share of proposed fixes build and pass tests? | Shows basic quality |
| What share are merged, and by whom? | Shows trust |
| How often are merged fixes reverted? | Shows hidden harm |
| Which fix types does the tool handle, and which does it leave to people? | Shows scope |
| Is any step automatic, or does every change need approval? | Shows control |
Ask for the measurement method and the type of customer, so you can judge whether it matches you.
Run a small trial
- Pick five repositories with decent tests and a few known vulnerable dependencies.
- Let the tool propose fixes for ten findings, or as many as exist.
- Record, for each: did it build, did tests pass, would a reviewer merge it, and what did review change?
- Time the review. A fix that takes longer to review than to write by hand has not saved anyone effort.
- Merge a few into a branch and run a longer test cycle.
Watch for fixes that bump a version across a breaking change, that touch lockfiles unexpectedly, or that pull in a different license. Reviewers should be able to see why the change is safe.
Control comes first
Ask how much control you have. Sensible defaults are that nothing merges without a person approving, with categories of change you can set to manual, to review or to auto. For any automation, ask what happens when tests fail and how to stop it quickly.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what evidence accompanies a proposed fix, since that is what a reviewer needs to merge with confidence.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests. It is off by default, and every category starts on Manual, so nothing merges without your decision. Test it with the funnel above, starting from the free scan at gold.safeguard.sh/scan.
Quick check
What is a good merge rate?
There is no universal figure. It depends on your tests and risk tolerance. Compare tools on your own repositories, and watch reverts as well.
Should fixes ever merge automatically?
Only where you have chosen that, for low risk categories with strong tests. Start with manual approval and relax slowly.
Last reviewed: 19 October 2026.
