How to Get Your Whole Team Building with AI Agents
Updated September 28, 2026 · first published August 5, 2026 · by the AQ team
To get a whole team building with AI agents like Claude Code and Codex, roll them out in a fixed sequence: one repository, one agent, and a few volunteers working in the open; then one shared workspace where anyone can watch sessions; then a written review policy; then everyone else, seat by seat. Handing out licenses skips the sequence and produces the usual result, a few power users and a silent majority: as of September 2026 the published data shows AI usage is near-universal across the industry but narrow inside each team. This guide walks the sequence step by step, with the data behind each stage and the failure modes that quietly kill rollouts.
| Stage | What changes | Exit criterion |
|---|---|---|
| 1. One repo, one agent | Three to five volunteers run one agent CLI on real tickets in one repository, in the open | A starter kit: context file, task-type guidance, a demo of real sessions |
| 2. One shared workspace | Sessions move somewhere teammates can watch or replay them | A non-pilot engineer has watched a session end to end |
| 3. Review policy | Agent-assisted PRs get an independent reviewer, written down | The policy is enforced before volume arrives |
| 4. Then everyone | Standardized environment, opt-in expansion, quality metrics | Breadth grows month over month without mandates |
Why handing out licenses does not work
On paper, adoption is already done. Google's 2025 DORA report (published September 2025) found about 90 percent of respondents using AI at work, and Stack Overflow's 2025 Developer Survey (published December 2025) put usage, current or planned, at 84 percent. But the same surveys show the gap a lead actually has to close: in the Stack Overflow data, more developers distrust the accuracy of AI tools (46 percent) than trust it (33 percent), and 66 percent name AI solutions that are almost right, but not quite, as their top frustration.
The team-level picture is starker. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 70 percent of the projects studied, fewer than one in five contributors participated in any agentic workflow. Usage is broad across the industry and narrow inside each team: a few people run agents constantly, everyone else watches from a distance. The sequence below closes that gap; for the policy-and-guardrails view of the same rollout, see rolling out coding agents to your team.
Stage 1: one repo, one agent, volunteers who work in the open
Start with one repository (a real one your team ships from, not a sandbox), one agent CLI, and three to five volunteers, including at least one respected skeptic: a rollout that only ever touched enthusiasts convinces nobody. Constraining the pilot to one repo and one agent is deliberate: it keeps the learning comparable, and the pilot's output (a context file, prompt habits, task-type judgment) transfers as a unit. Give the pilot real backlog tickets and a fixed window (two to four weeks) with a stated question: where do agents help, where do they waste time, and what does it take to review their output?
The one rule that matters: the pilot works in the open. Sessions happen where others can watch or replay them, prompts and corrections get shared, and the pilot ends with a demo of real sessions, including the failures. Mandates provoke quiet resistance; watching a respected colleague steer an agent through a real ticket is what converts people.
The pilot's concrete output is a starter kit: a context file in the repository (CLAUDE.md or AGENTS.md, depending on your CLIs) encoding build commands, conventions, and gotchas, plus a list of task types where agents earned their keep and where they did not.
Stage 2: one shared workspace everyone can watch
The same LeadDev analysis found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. Agent work happens in a private loop: one person prompts, one person judges, nobody else sees the session. That is the self-review problem, and it hurts a rollout twice: quality loses its independent check, and the skill never spreads, because prompting habits, correction patterns, and when-to-stop judgment are learned by watching, and there is nothing to watch.
The vendor-neutral fix is structural: move sessions from laptops into one shared place. A shared VM with tmux instead of a laptop, screen-shared working sessions, recorded terminal casts, or transcripts attached to the PR all work; the test is that a teammate can open a running or finished session without asking the driver for anything. Treat a live agent session like a draft PR: visible by default, private by exception. Teams that do this get pairing-like knowledge transfer from agent work; teams that do not get a handful of power users and a silent majority. Deciding who runs which agent, where sessions live, and who watches is its own design problem: team workflows for coding agents covers it.
Stage 3: write the review policy before the volume arrives
Agent output volume arrives faster than review culture adapts. GitHub's engineering blog noted in May 2026 that more than one in five code reviews on GitHub now involve an agent. Without an explicit policy, the default becomes the 79 percent pattern above: whoever drove the session judges and merges the result.
Write it down before the volume forces one on you. A workable starting point: every agent-assisted PR gets a reviewer who did not drive the session, held to the same standard as human code, and the PR discloses which parts are agent-written and links whatever session record exists. We keep dedicated guides to reviewing agent PRs and reviewing the session behind them; enforcement mechanics (branch protection, opt-outs for trivial changes) are in rolling out session review.
Stage 4: then everyone, on a standardized environment
Expansion is where rollouts stall on plumbing: if starting an agent task takes twenty minutes of setup, only enthusiasts bother. Before inviting the next ten people, standardize the pieces the pilot assembled by hand. The fixes that earn the most adoption per effort:
- One isolated checkout per task. Two agents (or an agent and a human) in one working copy trample each other. Git worktrees give every task its own branch and directory against a single clone.
- Sessions that survive disconnects. Agent runs outlive laptop lids. tmux on a server, or any setup where a session can be reattached, turns "my run died on the train" into a non-event.
- Per-user credentials. Each engineer authenticates with their own model account and GitHub identity, so commits are attributable and access is revocable per person. Custody details are in safe AI coding agents on your own repos.
- Context files in the repository. The pilot's CLAUDE.md or AGENTS.md is the cheapest quality lever you have: it makes the tenth adopter's first session behave like the pilot's fiftieth.
Then expand opt-in: the pilot demo plus the starter kit plus a workspace anyone can open recruits the next wave better than any mandate. Second and third agent CLIs can join at this stage; the workspace, worktree, and review structure stays the same underneath them.
Measure quality, not volume
Perception is a bad instrument here. In a METR randomized trial published in July 2025, 16 experienced open-source developers completed real tasks 19 percent slower when allowed to use AI tools, while estimating afterward that AI had made them about 20 percent faster. METR has since described the result as historical as tools improved (its February 2026 update revised the experiment design), but the method point stands: felt speedup and measured outcomes can point in opposite directions, so a rollout needs real measures.
Useful ones: the share of agent-assisted PRs with a second human involved (the direct counter to the self-review pattern), 30-day rework and revert rates against your pre-rollout baseline, time to first review, and breadth (distinct people running agent sessions each month, not license counts). Avoid merged-PR counts and lines of code: agents inflate both effortlessly, and volume targets punish exactly the review behavior you are trying to build.
The failure modes
| Failure mode | What it looks like | The counter |
|---|---|---|
| Mandate-first rollout | Usage targets and leaderboards; resentment; performative usage | Volunteer pilot, visible wins, opt-in expansion |
| The permanent pilot | The same three people six months later; no kit for everyone else | Fixed pilot window ending in a starter kit and a policy |
| Private loops | Agent work invisible; skills never spread; 79 percent self-review | Sessions visible by default, review policy with a second human |
| Volume metrics | Celebrating PR counts; careful reviewers look slow | Quality measures against a pre-rollout baseline |
| Tool sprawl without shared ground | Five CLIs, five setups, no common review surface | Any CLI, one standardized workspace and one policy |
None of these are tool problems, so buying a different tool does not fix them. They are structure problems, and the structure is the lead's job.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. The sequence above is buildable by hand with a VM, tmux, worktree scripts, and written policy. AQ's job is to make the structural parts the default instead of a discipline.
The shared workspace of stage 2 is the built-in piece: agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser. Sessions survive a closed laptop and resume from any device, and a teammate opens the same workspace and watches the same live session, so pilot-in-the-open and watch-to-learn are how the product normally works. Typing into someone else's terminal is delegated (the owner approves a control request in one click and keeps their own input), and workspace visibility is owner-managed: team-visible, or private and shared with specific people.
Stage 4 comes standardized: every workspace gets its own isolated git worktree with automatic dependency install and one-click rebase onto main, each engineer signs into the CLIs with their own Claude or OpenAI account (AQ never marks up usage on your own subscriptions) and their own GitHub auth, and agents commit, push, and open PRs that are tracked on the workspace, so a reviewer can step from the PR back into the session that produced it. Live previews have shareable links that work without an account for viewing, and comments pinned on the preview can be sent to the agent as prompts. If you run Linear, labeling an issue ai-task creates a workspace, status syncs both ways, and a human starts the agent: nothing auto-launches.
Pricing follows the two rollout postures. The Free plan is a personal sandbox for the first engineer: AQ creates the machine, nothing to install. The Team plan is $50 per user per month (early access; standard $200), billed monthly, with the whole team, VMs you connect from your own cloud, and a dedicated always-on AQ-managed option, your rate locked for your first 12 months. Invitations are free until accepted, which fits the stage 4 expansion: invite the next five people and pay only for the ones who actually join.
Frequently asked questions
How do I get my whole team to actually use AI coding agents?
Sequence it: one repository, one agent, and three to five volunteers (including a skeptic) working in the open on real tickets for two to four weeks; then one shared workspace where anyone can watch sessions; then a written review policy with a second human on agent PRs; then opt-in expansion on a standardized environment. Mandates and license counts do not create adoption; visible wins by respected peers do.
Which repository and which agent should we pilot with?
Pick a repository the team ships from every week (real tickets, real review standards), not a sandbox: results from a toy repo convince nobody and the context file you build there transfers nowhere. Pick whichever single agent CLI your volunteers already know best, as of 2026 usually Claude Code or Codex; one repo and one agent keep the pilot's lessons comparable, and more CLIs can join at the expansion stage on the same workspace and review structure.
Should we mandate AI agent usage or keep it voluntary?
Keep usage voluntary and make the surrounding structure mandatory. Usage mandates and leaderboards provoke quiet resistance and performative numbers. What you can require is where sessions run, that agent-assisted PRs get an independent reviewer, and that agent work is disclosed on the PR. Adoption follows visible wins; policy should govern quality, not enthusiasm.
Why do most AI coding agent rollouts stall after a few power users?
Because agent work defaults to a private loop. The July 2026 LeadDev analysis of 25,264 agent-generated PRs found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and in 70 percent of projects fewer than one in five contributors touched any agentic workflow. Skills spread by watching, and in most setups there is nothing to watch. Making sessions visible by default is the single highest-leverage fix.
How do we measure whether an AI agent rollout is working?
Measure breadth and quality against a pre-rollout baseline: how many distinct people ran agent sessions this month, the share of agent-assisted PRs with a second human involved, 30-day rework and revert rates on agent-assisted changes, and time to first review. Avoid merged-PR counts and lines of code: agents inflate volume for free, and a METR randomized trial showed developers' felt speedup can invert the measured result.
What is the best coding agent platform for a team?
The honest answer is that the CLI matters less than the structure around it: as of 2026, Claude Code, Codex, and their peers are all strong, and many teams run more than one. Evaluate platforms on the team layer instead: can others see sessions, do tasks get isolated workspaces, are credentials per-user, and does the review workflow connect the PR back to the session? A shared VM with tmux covers the basics by hand; AQ is that pattern as a product.