Roll out Syntic Code to a team
Getting a team to use a coding agent well is mostly a people problem. The software takes minutes to set up; the habits take a few weeks. This section is a practical playbook for the person leading that effort: what to prepare, how to run a pilot, how to talk about it, and how to find the colleagues who will help others along.
Nothing here is required. Take what fits your team and skip the rest.
Pages in this section
| Page | Use it to |
|---|---|
| Communications kit | Announce the rollout, run a pilot, and share weekly tips. Includes message templates to adapt. |
| Champion kit | Help the early enthusiasts on each team answer questions and spread good habits. |
A rollout in five steps
Decide the guardrails first
Before anyone installs anything, agree on the rules you need and enforce them with managed settings. Typical first choices:
- Deny reads of secrets:
Read(.env),Read(*.pem), your cloud credential folders. - Turn off bypass mode with
permissions.disableBypassPermissionsMode. - Approve the MCP servers people may use (see Managed MCP servers).
- Set a minimum version so everyone gets the same safety fixes.
People are more relaxed about trying a new tool when they know the boundaries are already in place.
Prepare two or three repositories
Pick repositories the pilot group works in every day. In each, run /init to have Syntic Code study the project and write a first SYNTIC.md, then edit it by hand: build and test commands, conventions, folders to leave alone. Commit a shared .syntic/settings.json with allow rules for the safe, frequent commands (tests, linters, git status). See Memory and Settings files.
Run a small pilot
Start with five to fifteen people who volunteered. Give them two to four weeks, a channel to ask questions in, and one short check-in each week. Ask them to note what worked, what was annoying, and what they stopped doing by hand.
Widen in waves
Add one team at a time, each with a champion who took part in the pilot. Use what the pilot learned to update SYNTIC.md files, permission rules and your internal tips.
Keep it fresh
Share one tip a week. Review the managed settings every quarter. Retire rules nobody needs and add ones that would have prevented a real mistake.
What to measure
Pick a few signals and look at them every two weeks. Avoid turning them into targets for individuals.
| Signal | Where it comes from |
|---|---|
| Weekly active users | OpenTelemetry export: syntic.session.count, tagged by team with OTEL_RESOURCE_ATTRIBUTES. |
| Spend per person and per repository | syntic.cost.usage and syntic.token.usage from the same export. See Manage costs. |
| Where people get stuck | Questions in your support channel, and the pilot check-ins. |
| Safety | Permission refusals (syntic.tool_decision events with reject) show which rules are doing work, and which are getting in the way. |
| Satisfaction | A two-question survey at the end of the pilot: “Would you keep using it?” and “What one thing would make it better?” |
Common blockers and what helps
| Blocker | What helps |
|---|---|
| ”It keeps asking me for permission.” | Add allow rules for the routine commands in the project settings, or show people permission modes. |
| ”It doesn’t know how our project works.” | A better SYNTIC.md. Ten good lines beat a page of general advice. |
| ”I’m not sure what I’m allowed to use it for.” | A short written policy in the announcement, matching the managed settings. |
| ”It costs too much.” | Show cost habits and set subagent caps by policy. |
| Network or sign-in problems | Network configuration and sign-in troubleshooting. |