Rolling Out AI Coding Agents to 30,000 Engineers: The Control Plane Nobody Talks About
Every enterprise conversation about AI coding agents starts with the same question: which tool? Claude Code, Codex, Cursor, Windsurf. It's the least important decision you'll make. Over three years at Capital One we ran most of them — some in production, some as proofs of concept — and reached 30,000+ users across Claude Code and Cowork alone. The tool mattered far less than the layer we built around it.
The tool is the easy part
An AI coding agent is, functionally, a very capable new employee with shell access, a model endpoint and no context about your company. Rolling one out safely means answering the same questions you'd ask about any privileged system: who can use it, what can it reach, what does it send where, how much does it cost, and how would you know if something went wrong?
The five layers of the control plane
- Access: SSO, role-based access and an enterprise gateway in front of every model call. We integrated through AWS Bedrock and an API gateway so that no tool talked to a model provider directly.
- Budgets: per-user, per-minute token limits. Without them, one runaway agent loop can burn a team's monthly budget before lunch.
- Configuration as code: centrally managed settings, a standard project memory file (CLAUDE.md), hooks and an MCP allow-list. Guardrails have to travel with the tool, not live in a wiki.
- Data controls: guardrails tuned to your data classification, so sensitive data never leaves where it should stay.
- Telemetry: OpenTelemetry for both cyber logging and developer-productivity metrics. If you can't answer "what did the agents do yesterday?", you're not ready to scale.
Treat Risk and Cyber as co-designers
The single most useful thing we did was bring Risk, Cyber, the technology controls team and the Model Risk Office in at design time rather than review time. When the control plane is something they helped shape, approval stops being a gate and becomes a pattern they can reuse for the next tool.
If your security team first hears about the rollout in a review meeting, you've already lost six weeks.
Release cadence is a feature
Models now ship every few weeks. Engineers notice immediately when they're stuck on last quarter's model. We built change management and testing specifically for model launches so a new version could be validated and rolled out in days. That speed did more for adoption than any internal marketing campaign.
Cost is a design constraint, not an afterthought
Token spend scales with usage, and successful adoption means more usage. Prompt caching, a model router that sends simple tasks to cheaper models, and tuning effort levels per use case kept unit costs predictable as adoption grew.
What I'd tell a CTO starting today
- Pick a gateway pattern before you pick a tool. It makes tools swappable.
- Ship configuration centrally from day one; retrofitting is painful.
- Measure adoption and outcomes separately — seats are not impact.
- Run a champions programme. Peer examples beat training decks.
- Budget for model churn. Your rollout is never "done".
If you're planning a rollout of AI coding agents and want a second pair of eyes on the architecture, that's exactly the kind of work I do now.