Scaling AI: A 6-Month Path from Champions to Company-Wide

Every couple of months I get a version of the same call. A CTO rolled out Claude Code or Cursor to the engineering org, licenses paid, a training session ran, and three months in, nobody can point at a number that says the spend paid off. The question is always the same: what went wrong?

What went wrong is the assumption baked into the rollout. “Adopt AI” is being treated as a procurement decision: pick a vendor, buy seats, send the email, watch productivity climb. The vendors encourage this framing because they sell licenses, not organizational redesign. The CTO bought what was on offer.

The actual work is organizational. It runs six months at minimum, it has phases that must happen in order, and it looks more like rolling out a new operating model than a new tool. The teams pulling ahead in 2026 are not the ones with the most licenses — they are the ones that did this slower, smaller, and in sequence.

The numbers don’t lie, and most companies are reading them wrong

Three pieces of public research are converging on the same finding from different angles.

Writer’s 2026 Enterprise AI Adoption Survey interviewed 1,200 C-suite executives and 1,200 non-technical employees. 97% of executives say their company deployed AI agents in the past 12 months. 29% see significant ROI from generative AI, and 23% from agents specifically. The most striking line in the report: 54% of C-suite leaders say adopting AI is “tearing their company apart.”

McKinsey’s November 2025 State of AI report reaches the same shape from the operational side. 88% of organizations now use AI in at least one business function, up from 78% in 2024. 39% attribute any level of EBIT impact to AI.

About 6% qualify as high performers, defined as greater than 5% EBIT impact. The single variable that correlates most strongly with high-performer status is workflow redesign, and only 21% of organizations have done it.

The DORA 2025 Accelerate State of DevOps Report adds a third angle. 90% of software professionals are using AI day to day, spending a median of two hours daily with AI tools, and 80% report productivity gains. But the headline finding is this: AI amplifies what is already there. Mature DevOps practices convert AI gains into delivery performance. Weak practices get amplified in the opposite direction, sometimes producing measurably worse outcomes after adoption.

Three lenses, one conclusion: the model is not the bottleneck, the licenses are not the lever, and the work is everything around the model.

For a practical starting point, our AI Readiness Assessment can help you map where your organization actually stands before committing to a rollout path.

Redefining the baseline

Before the playbook, the definition, because every rollout I have watched collapse did so because this step got skipped.

AI culture is not buying everyone a license, running a one-hour training, or treating AI as an isolated productivity tool for engineering. It is not replacing engineers with agents, and it is not speed at any cost.

What it is: engineers and builders working closer together, with a shorter distance between intent and shipped code. Investment in the harness as a continuous practice, not a one-time project. Engineers moving up a layer, from typing code to orchestrating agents. Speed with quality, because the gates and the judges keep the floor high. Decisions made on production data queried by agents through MCPs, instead of guessed from sprint planning.

The honest version of “we have an AI culture” looks like an engineer who runs five agents in parallel before lunch, queries production data while deciding what to ship, talks directly to the PM and designer in the afternoon, and writes a spec the next morning that an agent implements during another meeting.

That is a different operating model — and it does not happen because licenses got bought. It happens because the harness, the role design, the org chart, and the metrics all got rebuilt around the new layer.

Phase 1: The Champions (Months 1–2)

Two to four people — not “everyone who is interested,” but specifically: one product manager already curious about AI, one tech lead who is receptive, one engineer who already has the product-engineer or forward-deployed-engineer instinct, and one platform or infrastructure person who can build the early harness. Champions get rewarded with time, autonomy, and voice, in that order.

Over those two months, champions do three things: they build their own setup until it is durable, they write the first two or three shared skills, and they identify which one or two squads should be the pilot. Their output is not features — it is the rails the rest of the org will use.

Phase 2: The Pilot (Months 3–4)

One or two squads. Pick carefully: one with a new project and no legacy debt, one with planned refactoring work. Do not pick the squad running a production incident this quarter, the squad with the friction-resistant tech lead, or the squad that volunteered because they wanted to play with new tools. Pick the squads where the work fits the new operating model and where the people will be honest about what works and what does not.

Pilot squads use what the champions built, write more skills, and build the spec templates the broader org will inherit. The measurements that matter here are feature cycle time, rework rate, and developer eNPS — not tokens consumed. Token spend is a vanity metric. The actual question is whether you shipped faster, with less rework, and whether engineers liked it more.

BCG’s 10-20-70 rule is worth keeping in mind during this phase: 10% of the value comes from technology, 20% from data and process, 70% from people and process. The champions and pilot phases exist precisely because the 70% does not happen by buying tech.

Phase 3: The Harness (Months 5–6)

This is where the work the champions and pilot squads did becomes infrastructure the whole engineering org can use — and where teams most often quit because the work is unglamorous. There are five pieces worth investing in, and you will not finish all five in two months. Pick one or two.

Automated code review, by t-shirt size. Small PRs auto-approve after agent pre-review. Medium PRs get human review with the agent’s findings attached. Large PRs require pair plus agent. The routing is the move — without t-shirt sizing, every PR goes through the same gate and you bottleneck on senior review.

Standardized spec templates. How your team captures features becomes the standard input for every agent. Specs go in the repo at docs/specs/, versioned like code, using the same template across the org. The variance you eliminate by standardizing is worth more than the flexibility you preserve by staying loose. See our practical overview of AI for software development for how this fits into a broader workflow.

Central MCP with governance. One audited MCP server for production database access, one for Datadog, one for Sentry — access controlled, logs audited, secrets scanned. Without this, every engineer rolls their own and you have a security and compliance problem waiting to surface.

Self-healing loops. An agent that opens its own PR to fix a detected bug. Sentry fires, an MCP routes the error to a triage agent, the triage agent files an issue, a worker agent picks it up and opens a PR with a fix and tests. This is advanced — do not start here — but it is where the harness compounds the hardest.

Team skills versioned. All shared skills committed to a single repo, code reviewed, and tagged. This is the institutional knowledge layer: when someone leaves, the skill stays; when someone joins, the skills are their orientation.

Two of these done well will outperform five done badly. Pick the two with the highest leverage for your team and work them in the open.

Read more: Plan Mode is the Deal-Breaker: Why Direct-Mode Coding with Agents Wastes Tokens

Before you scale: governance that actually matters

Governance is where most rollouts I have watched fail, so here is what to lock before going company-wide.

Enterprise CLAUDE.md as a policy gate. Anthropic supports four levels of CLAUDE.md hierarchy: Enterprise, User, Project, and Directory. The Enterprise level is where company-wide policies go — what is allowed in prompts, what is forbidden, what gets scanned. Lock this before scaling.

Tool and budget controls in CI. –allowedTools restricts what tools agents can invoke in automated runs. –max-budget-usd caps spend per run. Neither is exotic, and both are easy to forget until your CI bill triples in a month.

MCP allow-lists and audit logs. Every MCP server connecting to anything sensitive should be on a vetted allow-list with every call audited. If your central production-DB MCP cannot answer “what did agent X read from the users table last Tuesday,” you are not ready to scale.

Prompt-injection defense. If an MCP returns data that an attacker can influence — a CRM note, a support ticket, a public web page — that data can contain prompt-injection payloads. The defense is layered: sanitize input, restrict the tools an agent can call after reading untrusted data, and sandbox the agent for untrusted operations. Do not skip the threat model.

Data residency and BAA, accurately. Anthropic offers a Business Associate Agreement on the direct API via sales. Zero Data Retention is available to eligible enterprise customers via approval, with carve-outs — Batch API, Files API, Skills API, code execution, and MCP connector calls are out of scope. EU data residency is not included by default on Claude Enterprise; strict EU-only processing runs through AWS Bedrock in Frankfurt or Google Vertex AI EU regions. Tell your compliance team the accurate version before you sign, not after.

The hiring question every CTO eventually asks

The pyramid flattens. Fewer pure juniors writing boilerplate, more mid-senior generalists who own outcomes end-to-end. The “junior implements, senior reviews” ladder gets squeezed because the implementation step is now mostly agentic. The roles that survive and grow are the ones with judgment under ambiguity.

The interview shifts accordingly: less LeetCode, more taste, spec authoring, judgment, and the ability to architect agentic workflows. Boris Cherny at Anthropic described Anthropic’s hiring filter as “side quests” — engineers with weekend projects, range across product, design, and infrastructure, evidence that they build things outside the day job.

That filter is spreading. The engineer with one stack and ten years of feature factory experience is the profile most under pressure. The engineer with a side project, opinions about product, and comfort operating across the full stack is the profile that compounds.

Read more: Harness Engineering: Why “Done” Isn’t the Agent Saying So

The six-month sequence on a calendar

• Months 1–2: Champions and tooling. Workshop, individual setup, champions identified by name, first two shared skills committed. The output of this phase is not features — it is a working group of two to four people who fluently use the tools and have started building the early harness.
• Months 3–4: Pilot pods. One or two squads adopt the new workflow on real work. First spec templates committed, first harness retros run, measurements baselined across cycle time, rework rate, and eNPS.
• Months 5–6: Harness layer. Code review automation, one central MCP, skills versioned and tagged, governance locked. The harness becomes something the broader org can adopt without learning from scratch.
• Month 7+: Rollout. All of engineering migrates to the new workflow. Formal governance in place, metrics on a dashboard, and the culture flywheel starts because the gap between early adopters and the rest of the org narrows to a week instead of six months.

The temptation in every conversation is to compress this — skip the pilot, just train everyone; skip the harness, the engineers will figure it out; skip governance, legal will catch up later. Every time a team has tried this, they have spent three more months recovering from the consequences than they saved by skipping. The sequence is the playbook, and maturity is not speed.

Four things to do before Monday

• Name two to four champions by Friday. Send them a short note: “You are the working group that figures out how we adopt AI. Time, autonomy, voice. Bring me a plan in four weeks.” Then get out of their way.
• Pick the pilot squad and the pilot project before the end of the month, and kick off the pilot within two to four weeks. Do not run a third pilot — two is the maximum.
• Commit the first spec template and the first shared skill to the repo. Not five: one of each. The point is to establish that this is how your company captures knowledge now.
• Pick one metric and measure it for six months: cost per feature, cycle time per feature, or rework rate. Put it on a dashboard and look at it every two weeks. Most rollouts fail because no one was holding a number that said whether they were working.

The companies that look prescient three years from now will not be the ones who bought the most licenses. They will be the ones who treated AI adoption as the organizational redesign it actually is — champions before pods, pods before harness, harness before rollout, measurement throughout. If your team is somewhere between the champions phase and the harness phase and wondering what month three actually looks like, reach us out. The diagnostic is usually faster than the conversation about whether to do the diagnostic.