What is a champion in a coding agent rollout?

A champion is one engineer per team who gets access to the coding agent before everyone else, converts a real team workflow to use it, tunes the shared project configuration, and then onboards colleagues in small batches. They are the team's first line of support, so questions about the codebase don't all route to one central person.

Why not enable a coding agent for the whole team at once?

Switching everyone on at once tends to produce lumpy adoption (a few heavy users, everyone else barely engaged), teams that never move past using the agent as a chat box, and no working example on the team's own codebase. A champion-led rollout produces that example and a tuned configuration before broad use starts.

What should a shared coding agent configuration contain?

At minimum: a project-level agent context file (such as `AGENTS.md`) with conventions and build/test instructions, an agreed set of tools and integrations, a permission posture, and reusable versioned procedures for repeated tasks. Keep it in the repository so it is reviewed and versioned like code.

How long does a champion-led rollout take?

In the pattern described here, a champion spends about two weeks converting one real workflow, then runs batches of roughly five peers. Total time depends on team size; the point is that each batch starts from a better baseline than the last.

Does this apply to embedded teams specifically?

Yes, and more strongly. Generic demos don't transfer to cross-compiled toolchains or hardware-dependent tests, so a local working example matters more. The build has to be reproducible for the agent before anything else in the configuration helps.

Rolling Out Coding Agents to an Engineering Team, Champions First, Then Batches

A coding agent rollout is the work of getting a whole engineering team productive with the tool, not just giving everyone a licence. The pattern I recommend is champion-led: one engineer per team gets access first, proves the agent on a real workflow from that team, and then onboards their peers in small batches. Switching everyone on at once is the most common way I see this go wrong.

The cost of a bad rollout rarely shows up as a line item. It shows up as licences paid for and barely used, a handful of enthusiasts whose habits never spread, and a quiet return to the old way of working after a few weeks of confused first prompts. On an embedded team there is a second cost: an agent nobody configured properly is an agent nobody trusts near the firmware, so the investment never reaches the code where it would matter most.

Why does switching everyone on at once fail?

The all-hands launch looks efficient: one announcement, one onboarding session, everyone starts on Monday. It fails in three predictable ways.

Lumpy adoption. A few engineers use the agent heavily and the rest barely touch it. The practice never standardizes, so the team never sees the real gain, and the heavy users’ knowledge stays in their heads.
Stalling at basic chat. People use the agent as a question box and never get to the workflows that pay off: running the build, iterating against tests, using packaged procedures. Access is not adoption.
No local proof. Generic demos don’t transfer to a cross-compiled toolchain, a HAL, or a hardware-in-the-loop rig. Without one working example from their own codebase, sceptical engineers have no reason to change how they work.

A mass launch hands the hardest part of adoption, making the agent work on this codebase, to everyone at once with nobody responsible for it.

What a champion actually does

A champion, the one engineer per team who gets access first, does three jobs no announcement can do.

Converts one real workflow. Not a toy. Something the team already does every week: generating host-side unit tests for a driver, drafting the review summary for a change, reproducing a bug from a trace. Two weeks is usually enough.
Absorbs the early friction. The broken build invocation, the permission prompts, the missing context about how the project is laid out. The champion hits these first and fixes them in the shared configuration, so the next five people don’t.
Becomes first-line support. Questions go to someone who knows the team’s code, not to a central “AI person” who becomes a bottleneck.

On an embedded team, that first workflow does not have to be invented from scratch. It is what you get from the first steps of my offering. The audit diagnoses what stops an agent from building and testing your project, and the training course teaches the fixes on a training codebase. The champion’s first real workflow is then usually “the agent builds and verifies this project on its own”, followed by “the agent writes and runs tests against it”. That is a working example the rest of the team can watch and repeat, which a vendor demo is not.

The course is built for exactly what this article describes. The people in the room are the champions: a small group who come out able to build those first workflows, to set up the shared configuration described below, and to turn a workflow into something the next engineer can pick up. The batches that follow then run on the champion’s example, not on mine.

The champion’s real output is not their own productivity: it’s a working example, a tuned configuration, and a local expert.

Why the shared configuration matters more than the licences

What the champion tunes should land in the repository, not in their personal setup. That means a project-level baseline every engineer starts from:

a shared agent context file (an AGENTS.md, or whatever your agent reads) with the project’s conventions and how to build and test it;
an agreed set of tools and integrations the agent may use;
a permission posture: what the agent may run without asking;
reusable, versioned procedures (packaged prompts or scripts) for the tasks the team repeats.

Because these files live in the repo, they get reviewed, versioned, and rolled back like any other code. That’s the same argument I made in Best Practices for Coding Agents Start With a Legible Codebase, applied to a team: legibility for one agent session only lasts if the configuration is shared, not personal. Forty personal setups drift apart; one reviewed baseline improves once for everyone.

On an embedded team the build is where this bites first. If the agent can’t build and test the project reproducibly, nothing else in the configuration matters; see Reproducible Embedded Builds, or Becoming Your Agent’s Synchronization Point.

The licence gives an engineer an agent; the shared configuration gives them an agent that already knows the project.

How should the batches work?

Once the champion has a working workflow, they onboard peers in small groups. My default is around five people per batch, with a short session built on the team’s own example rather than a vendor demo.

Session on the real workflow. The champion walks through the converted workflow on the team’s codebase, including the failures they hit and how the configuration handles them.
Each person converts one task of their own within the following week, using the shared baseline.
Feedback goes back into the configuration, not into a chat thread. A new convention becomes a line in the agent context file; a repeated procedure becomes a shared, versioned procedure.
Next batch. Repeat until the team is covered, then the champion’s role shifts to keeping the baseline current.

Each batch starts from a better baseline than the previous one, which is the opposite of what happens with a single launch.

The options I considered

The champion pattern is not the only way to roll out a coding agent. The real options are:

All at once. Lowest coordination cost on day one, highest cost afterwards, for the reasons above. Reasonable only for a very small team where everyone is effectively a champion.
Central enablement team. A platform or “AI” group configures everything and trains everyone. It works for org-wide policy (spend caps, which models are allowed) but it doesn’t know each team’s code, so it becomes a bottleneck for the codebase-specific part.
Opt-in only. Let whoever wants it use it. This is lumpy adoption by design: the enthusiasts thrive and nothing standardizes.
Champion, then batches. Slower to reach full coverage, but every team gets a local example, a local expert, and a tuned shared configuration before broad use starts.

In practice I combine the last one with a thin central layer: org-wide settings like model defaults and spend limits stay central, while everything about this codebase belongs to the team’s champion. The rest of my writing on this topic is collected under best practices for coding agents.