Once AI coding tools spread past a few early adopters, the same gap appears in every organisation: dozens of teams are figuring out the same things independently, badly, and in private. One team has a great prompt library nobody else can see. Another quietly discovered a tool setting that leaks data. A third is still arguing about whether they are allowed to use AI at all.
The usual response is to stand up a "center of excellence" (CoE) to coordinate it. The instinct is right; the execution usually is not. Most CoEs drift into one of two failure modes: a committee that produces guidelines nobody reads, or a gate that slows teams down until they route around it. Either way, the shadow usage the CoE was meant to eliminate gets worse, not better.
We help organisations build the version that works: a small enablement function that teams call because it makes them faster, not one they avoid. Here is how to set it up.
Be clear about what problem it solves
A CoE is worth creating when adoption has outgrown informal coordination. The symptoms are specific.
- Teams are duplicating effort: re-solving prompts, configs, and workflows in isolation.
- Knowledge is trapped in individuals and does not spread.
- Standards are inconsistent: every team has a different answer on tools, security, and review.
- Risk is uneven: some teams are careful, others are one prompt away from a data incident.
If none of those are true yet, you do not need a CoE; you need a good usage policy and a couple of informal champions. The CoE earns its existence only when scale has made coordination a real job.
What it should own, and what it must not
The fastest way to kill a CoE is to make it a checkpoint. Its job is to enable and standardise, not to approve every use. The line between the two is the whole game.
| The CoE owns | The CoE does not own |
|---|---|
| Curating approved tools and recommended settings | Approving each individual use of a tool |
| Shared prompt libraries, patterns, and playbooks | Writing the code for teams |
| Training, onboarding, and internal enablement | Owning delivery for product teams |
| Tracking adoption and surfacing what works | Policing developers or chasing metrics for their own sake |
| Being the escalation point for hard questions | Being a gate every change has to pass |
Anything in the right-hand column turns the CoE into friction, and friction is exactly what pushes engineers back to unofficial tools. The principle is constant: make the approved path the easy path, and the CoE becomes a service teams pull from rather than a tax they pay.
Staff it small and part-time first
A CoE does not need to be a new department, and starting with one is a mistake. Begin with a small, cross-functional group drawn from people already doing the work.
- A lead who owns enablement and is accountable for adoption outcomes, usually a senior engineering manager or staff engineer, not a new hire.
- Champions embedded in teams: respected engineers who spend a slice of their time helping their own team and feeding learnings back. This embedded model spreads practice far better than a central team broadcasting at everyone.
- Security and legal as advisors, looped in for tool evaluation and policy, not sitting in the core group day to day.
Keep it part-time and lightweight until the value is proven. A CoE that starts as five full-time hires has to justify a budget before it has demonstrated anything, which warps its incentives toward looking busy.
Run it as a service with a real backlog
The functional CoE behaves like an internal product team serving engineers as its users. That framing keeps it honest.
- Maintain the approved toolset and the recommended configuration, so tool choice is made once centrally instead of re-argued by every team.
- Curate shared assets: a prompt and pattern library, example workflows, and a place to put them where they are actually found.
- Own onboarding so every new engineer gets the same structured introduction to the tools instead of absorbing whatever their neighbour happens to do.
- Run a feedback loop: office hours, a support channel, and a visible backlog of requests from teams. What teams keep asking for is the roadmap.
Measure adoption honestly, not theatrically
A CoE has to show it is working, and this is where many quietly corrupt themselves, by reporting license counts and prompt volumes that prove activity, not value.
- Track outcomes: delivery signals like cycle time and change failure rate, and the share of teams on the approved path versus shadow tools.
- Track enablement reach: how many engineers are onboarded and active, not how many keystrokes were saved.
- Avoid vanity metrics: lines of AI code or raw acceptance rates measure usage, not benefit, and optimising for them produces exactly the fake productivity math that erodes trust in the whole effort.
The test is simple: would this metric still look good if the tool were quietly making things worse? If yes, it is the wrong metric.
Our view
A center of excellence is the right structure once AI adoption has outgrown informal coordination, but only in one form. The version that works is small, embedded, and run as a service that makes the approved path the fastest one. The version that fails is a central gate that approves uses, polices developers, and reports activity metrics; it recreates the shadow usage it was built to prevent.
Start light, staff it from people already doing the work, give it a real backlog driven by what teams ask for, and measure outcomes rather than theatre. Done that way, the CoE does the one thing that actually scales AI adoption: it turns what your best teams already figured out into the default everyone inherits.
Sources
- DORA,
Accelerate State of DevOps, on platform teams and delivery outcomes, accessed 2026-06-10 - Team Topologies, Skelton and Pais, on enabling teams and platform-as-a-service models, accessed 2026-06-10
- McKinsey,
The economic potential of generative AI, on conditions for realising developer productivity, accessed 2026-06-10
Frequently asked questions
- When does an organisation actually need an AI coding center of excellence?
- A CoE earns its place once informal coordination has broken down at scale. The concrete symptoms are teams duplicating prompt and config work in isolation, knowledge trapped in individuals, inconsistent standards across teams, and uneven risk exposure where some teams are one prompt away from a data incident. If none of those are true yet, a usage policy and a few informal champions are enough.
- What should an AI CoE own — and what must it stay out of?
- The CoE should own curating approved tools and recommended settings, shared prompt libraries and playbooks, onboarding, and tracking adoption. It must not approve individual tool uses, write code for product teams, or act as a gate every change has to pass. Anything in that second category turns the CoE into friction and pushes engineers back to unofficial tools.
- How should we staff an AI CoE without creating a new bureaucratic department?
- Start with a small, cross-functional group drawn from people already doing the work: a senior engineering manager or staff engineer as lead, plus embedded champions in each team who spend a slice of their time helping their team and feeding learnings back. Security and legal sit as advisors, not in the core group. Keep it part-time until the value is proven — starting with five full-time hires forces budget justification before anything is demonstrated, which warps incentives toward looking busy.
- What metrics should an AI CoE actually report to prove it is working?
- Track delivery outcomes — cycle time, change failure rate, and the share of teams on the approved path versus shadow tools — and enablement reach: engineers onboarded and active. Avoid vanity metrics like lines of AI code or raw acceptance rates, which measure activity not benefit. The test for any metric: would it still look good if the tool were quietly making things worse? If yes, it is the wrong metric.
