Pilot automated fixes on a single well tested repository for four weeks, with every category on manual approval, written success criteria and a stop rule. Expand only if acceptance is high, reverts are near zero and reviewers say the PRs save them time.
Pick the right first repository
The best pilot repository has three properties:
- Decent tests that run in CI and fail when something breaks.
- An active team that will actually review PRs within a day or two.
- Moderate stakes. Not the payments service, not an abandoned prototype either.
Avoid monorepos for the very first pilot unless that is where most of your risk lives, because one lockfile touches many teams. If you must, see how to secure a monorepo without slowing every team down.
Write the success criteria first
Decide before you start, and write them down:
- Share of PRs merged without edits (for example, above a target you choose).
- Number of reverted or hot-fixed changes (target: zero).
- Median time from PR open to merge.
- Reviewer sentiment, asked in a short survey at the end.
Your numbers should come from your own baseline. Do not borrow a benchmark from a vendor blog.
Week by week
Week 1: setup. Connect the repository, confirm required checks run on bot PRs, set CODEOWNERS, and keep all categories on Manual. Test the kill switch. Run a baseline scan and record findings count.
Week 2: review everything slowly. Reviewers use the fix PR checklist. Log every PR in a simple sheet: finding, version jump, files changed, outcome (merged, edited, closed), and why.
Week 3: tighten. Use week 2 notes to adjust scope. If many PRs were closed for the same reason, change the configuration. If reviewers found the descriptions lacking, say what is missing.
Week 4: decide. Look at the criteria. Hold a short retrospective. Choose one of three outcomes: expand to two or three more repositories, stay as is for another month, or stop.
What to record about problems
Every surprise is data. Write down the cause: missing tests, a bad version choice, a build quirk, a permission problem. A pilot that finds three fixable problems has done its job.
Expansion rules
Expand by repository, not by autonomy. Add more repos on manual approval before relaxing approval anywhere. When you do relax it, do it for one low risk category and write the merge criteria. The approval tier guide helps.
Stop rules
Stop and investigate if any of these happen: a reverted change reaches production, the bot opens PRs that bypass required checks, or reviewers stop reading PRs. Fix the cause before resuming.
Quick check
How long should a pilot run?
Four weeks is a reasonable default because it covers several release cycles for most teams. Shorten or lengthen it based on how often the repository ships.
Safeguard's remediation ships off with all categories on Manual, which fits this plan directly: you begin where the pilot needs to begin.
Last reviewed: 19 October 2026.
