Choose a pilot group of six to ten experienced developers who work on different kinds of code, include one skeptic and one dedicated reviewer, and avoid teams on regulated or high blast radius systems for the first round. Seniority matters because pilots depend on people who can spot a wrong answer.
What the pilot is for
A pilot answers three questions: does the agent help, what does it break, and are the controls workable. You learn the second and third only if the group is varied and honest. A group of enthusiasts will tell you the first and miss the rest.
Who to include
Experienced developers. People who know the codebase well review agent output faster and catch subtle errors. Early rounds with newer developers hide problems, because they cannot tell a plausible answer from a correct one.
Two or three kinds of work. For example, a service team, a front end team, and an infrastructure or tooling team. Different work shows different failure modes.
One skeptic. Someone who expects to dislike it and will say so with evidence. Their notes are worth more than praise.
One dedicated reviewer. A person whose task is to read agent produced pull requests closely and log what they find.
A security contact. Someone who reads the logs weekly and can adjust controls fast.
Who to leave out for now
| Group | Why wait |
|---|---|
| Teams on regulated data systems | Raise the cost of a mistake before controls are tuned |
| Teams that own authentication or payments | Highest impact if a flaw is merged |
| Contractors with limited onboarding | Policy and training may not have reached them yet |
| Teams in a release crunch | They will skip the feedback steps |
These are first round choices, not permanent bans. Add them in later rings once the controls hold. See AI coding agent rollout rings with gates.
Steps to run the selection
- Ask for volunteers and nominate a few. Volunteers alone skew toward enthusiasts.
- Check the mix against the list above and fill gaps.
- Write the ground rules on one page: allowed tools, data limits, review rules, how to report problems.
- Set a feedback rhythm. A short weekly note beats a long end survey.
- Agree the exit criteria before day one, so the decision is not made on mood. Go or no go criteria covers that step.
Watch for pilot bias
Pilot participants know they are watched, and they use the agent on the tasks it handles well. Ask them to also try it on a few ordinary tasks and a few hard ones, and record the results of both. Without that, the numbers flatter the tool.
Safeguard provides policies, pull request gates, and asset discovery, which can help you see which repositories and tools the pilot actually touches.
Quick check
How big should a pilot be?
Small enough that one reviewer can follow it and large enough to cover different work. Six to ten people is a workable range for many teams.
Should managers be in the pilot?
Only if they write code daily. Otherwise their feedback is secondhand.
Last reviewed: 19 October 2026.
