{"id":13835,"date":"2026-05-27T15:09:28","date_gmt":"2026-05-27T15:09:28","guid":{"rendered":"https:\/\/cheesecakelabs.com\/blog\/"},"modified":"2026-05-27T15:13:25","modified_gmt":"2026-05-27T15:13:25","slug":"how-to-scale-ai","status":"publish","type":"post","link":"https:\/\/cheesecakelabs.com\/blog\/how-to-scale-ai\/","title":{"rendered":"Scaling AI: A 6-Month Path from Champions to Company-Wide"},"content":{"rendered":"\n

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?<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u2014 they are the ones that did this slower, smaller, and in sequence.<\/p>\n\n\n\n

The numbers don’t lie, and most companies are reading them wrong<\/h2>\n\n\n\n

Three pieces of public research are converging on the same finding from different angles.<\/p>\n\n\n\n

Writer’s 2026 Enterprise AI Adoption Survey<\/a> 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.”<\/p>\n\n\n\n

McKinsey’s November 2025 State of AI<\/a> 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.<\/p>\n\n\n\n

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

The DORA 2025 Accelerate State of DevOps Report<\/a> adds a third angle. 90% of software professionals are using AI day to day, spending a median of two hours daily with AI tools<\/a>, 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.<\/p>\n\n\n\n

Three lenses, one conclusion: the model is not the bottleneck, the licenses are not the lever, and the work is everything around the model.<\/p>\n\n\n\n

\n

For a practical starting point, our AI Readiness Assessment<\/a> can help you map where your organization actually stands before committing to a rollout path.<\/p>\n<\/blockquote>\n\n\n\n

Redefining the baseline<\/h2>\n\n\n\n

Before the playbook, the definition, because every rollout I have watched collapse did so because this step got skipped.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

What it is: <\/strong>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.<\/p>\n\n\n\n

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. <\/p>\n\n\n\n

That is a different operating model \u2014 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.<\/p>\n\n\n\n

Phase 1: The Champions (Months 1\u20132)<\/h3>\n\n\n\n

Two to four people \u2014 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.<\/p>\n\n\n\n

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 \u2014 it is the rails the rest of the org will use.<\/p>\n\n\n\n

Phase 2: The Pilot (Months 3\u20134)<\/h3>\n\n\n\n

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<\/strong> where the work fits the new operating model and where the people will be honest about what works and what does not.<\/p>\n\n\n\n

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 \u2014 not tokens consumed. Token spend is a vanity metric.<\/strong> The actual question is whether you shipped faster, with less rework, and whether engineers liked it more.<\/p>\n\n\n\n

BCG’s 10-20-70 rule<\/strong> 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.<\/p>\n\n\n\n

Phase 3: The Harness (Months 5\u20136)<\/h3>\n\n\n\n

This is where the work the champions and pilot squads did becomes infrastructure the whole engineering org can use \u2014 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.<\/p>\n\n\n\n

Automated code review, by t-shirt size.<\/em> 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 \u2014 without t-shirt sizing, every PR goes through the same gate and you bottleneck on senior review.<\/p>\n\n\n\n

Standardized spec templates.<\/em> 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<\/a> for how this fits into a broader workflow.<\/p>\n\n\n\n

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

Self-healing loops.<\/em> 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 \u2014 do not start here \u2014 but it is where the harness compounds the hardest.<\/p>\n\n\n\n

Team skills versioned.<\/em> 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\n

Read more: <\/strong>Plan Mode is the Deal-Breaker: Why Direct-Mode Coding with Agents Wastes Tokens<\/a><\/p>\n<\/blockquote>\n\n\n\n

Before you scale: governance that actually matters<\/h2>\n\n\n\n

Governance is where most rollouts I have watched fail, so here is what to lock before going company-wide.<\/p>\n\n\n\n

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

Tool and budget controls in CI.<\/em> –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.<\/p>\n\n\n\n

MCP allow-lists and audit logs.<\/em> 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.<\/p>\n\n\n\n

Prompt-injection defense.<\/em> If an MCP returns data that an attacker can influence \u2014 a CRM note, a support ticket, a public web page \u2014 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.<\/p>\n\n\n\n

Data residency and BAA, accurately.<\/em> 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 \u2014 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.<\/p>\n\n\n\n

The hiring question every CTO eventually asks<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

The interview shifts accordingly: <\/strong>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” \u2014 engineers with weekend projects, range across product, design, and infrastructure, evidence that they build things outside the day job.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Read more: <\/strong>Harness Engineering: Why \u201cDone\u201d Isn\u2019t the Agent Saying So<\/a><\/p>\n\n\n\n

The six-month sequence on a calendar<\/h2>\n\n\n\n