Scaling Across Teams

What changes after the pilot

A good pilot, as The 90-Day Pilot designs it, proves one thing: one task type, on one team, at one level, against a baseline and a stop rule. Scaling multiplies everything the pilot held constant. A result that held for one team's maintenance work does not transfer to another team's payment service; Maintenance & Migrations shows the same migration producing different numbers at two companies.

DORA's guidance on its AI Capabilities Model puts it in one line: "AI adoption is an organizational transformation." It recommends value-stream mapping so that "the efficiency gains from AI aren't just creating local optimizations that pile up work downstream" (DORA, December 2025). Twenty teams each speeding up their own coding can add up to the queue that When Code Gets Cheap, the Bottleneck Moves described.

Expect a dip as well. DORA's 2024 report warned that "Implementing a platform engineering initiative might lead to a temporary decrease in performance before improvements manifest as the platform matures" (DORA, October 2024, T2). The central work below is platform work; it costs before it repays.

The book's proposal is that three things have to be central, and most of the rest can stay local:

• The stance: which phases and task types may run at which level, and under what ceiling.
• Provenance: how every change records what the AI did and which human answers for it.
• The permission model: the controls that stop any team from granting more authority than its level allows.

Tool choice, prompts and workflows can stay with the teams. Zalando, whose programme is the case in section 15.6, says: "We have never centrally mandated the use of a single tool" (Zalando Engineering, August 2026). Centralise the rules about authority, not the brand of the tool.

Mandate or clarity

The first scaling decision most leaders face is whether to require AI use. Uptake is a real problem. In three field experiments covering 4,867 developers at Microsoft, Accenture and a Fortune 100 company, "around 30-40% of the engineers" did not even try the tool, although it needed no extra investment and plugged into their existing editor (Cui et al., T1, mixed independence; Economics, Risk and Measurement reads its productivity result). Licences alone do not produce adoption.

Some companies answered with force, and some with prohibition:

• Shopify. The CEO's memo of April 2025 says "Reflexive AI usage is now a baseline expectation at Shopify." According to press summaries, employees must justify why AI cannot do a task before requesting more resources, and AI competency becomes part of performance reviews and hiring (Digital Commerce 360, secondary; the memo itself was not retrieved).
• Coinbase. According to press reports of a podcast interview in August 2025, the CEO fired engineers who had not adopted AI tools within a week of being told to, without a good reason (Tech.co, secondary).
• Goldman Sachs. Its CIO, Marco Argenti, told CNBC in July 2025, "Initially, we will have hundreds of Devins [and] that might go into the thousands, depending on the use cases" (CNBC, 11 July 2025, as syndicated by NBC Chicago). This is a plan, not a result.
• Samsung, in the other direction, restricted generative AI on company devices and internal networks from May 2023, after an internal leak of sensitive data to ChatGPT a month earlier, according to Bloomberg as reported by TechCrunch (secondary; the Bloomberg report is paywalled and was not read).

None of the four has published a delivery, quality or incident outcome. A mandate is an adoption policy, and an adoption figure is not an outcome, by the reading rules of Case Studies. There is no controlled comparison of mandates against voluntary adoption.

What has been measured is clarity. DORA's 2025 AI Capabilities Model found that "a clear AI stance amplifies AI's positive impact on individual effectiveness and organizational performance, and can reduce friction for employees". It adds: "this capability does not measure the specific content of AI use policies, meaning organizations can achieve this capability regardless of their unique stance—as long as that stance is clear and communicated" (DORA, September 2025).

So a clear ban and a clear mandate can both score well. What the evidence rewards is people knowing what they may do. DX, which sells measurement software, takes a firmer line: "we strongly caution against top-down mandates or using metrics for individual performance evaluation" (DX AI Measurement Framework, vendor guidance). That is advice, not a measured result.

The book's position follows the evidence: make the stance unambiguous, and do not rely on force, because no one has shown that force works. The named cost is that clarity alone does not move the 30–40% who never try; that takes enablement (section 15.6).

Write the stance by level

"Use AI responsibly" is not a clear stance. A stance is clear when an engineer can answer, for the task in front of them, whether AI may do it, how much of it, and who checks. The maturity model already gives the vocabulary: a level per phase and task type, a risk ceiling, and the authority the AI holds. The grid below is the book's proposal for what a written stance contains. The Templates appendix carries a version to copy.

Two rules make the stance scale. First, teams climb by meeting entry criteria, not by asking. The Part II chapters each end with the evidence the next level requires; the stance points to them. A team that shows the evidence the level names gets it: for L3, machine-enforced routing rules, an exercised rollback, a verifier the agent cannot edit and the 90-day escaped-defect comparison. A team that cannot show them does not, however senior the sponsor. Second, stepping down needs no meeting. If a team's change failure rate crosses its trigger, the level drops first and the discussion follows. Measuring Success and When to Roll Back writes the triggers.

Write the stance on one page, version it, and announce each change. DORA measured clarity and communication; a policy nobody has read is not a stance. The wiki's notes on governance in practice and accountability and roles cover ownership.

Central and local controls, by level

A stance that lives only in a document is an instruction, and Security, Permissions & Blast Radius shows what instructions are worth when an agent holds the credential. The permission model is what makes the stance true. Its controls tighten as the level rises, and the share decided centrally grows with them. The split below is the book's proposal.

Each central control has a concrete mechanism today:

• Managed settings. Claude Code lets administrators disable its bypass mode in managed settings "where they can't be overridden" (Claude Code permissions, as of October 2026). The security chapter's migration steps cover it; at scale the point is that the setting is pushed to every machine, not left to each team. The Nx malware ran installed AI tools with their permission-bypass flags switched on, including Claude Code's --dangerously-skip-permissions.
• Code-owner review on agent configuration. Pillar Security showed that hidden Unicode in rules files can make Cursor and Copilot insert a malicious script without mentioning it, and advised treating AI configuration files "with the same scrutiny as executable code" (Pillar Security, March 2025, T1). Put instruction files, rules files, permission files and MCP configuration under required review across every repository.
• Per-organisation enablement. GitHub states that "Copilot cloud agent and use of third-party MCP servers are disabled by default", and enterprise owners can set the policy to "Enabled for selected organizations" (GitHub docs, as of October 2026). Use that switch to grant L3 tools only to the teams that have met the L3 criteria.
• A model gateway. Zalando routes model access through a LiteLLM proxy, which gave its platform team "a single point to measure adoption via: MAU, WAU, model, User-Agent", and runs it for about 2,000 monthly active users (as of August 2026). On old clients it is blunt: "For self-managed client installations, unfortunately blocking access is the only effective measure." A gateway is also where tool approval, model retirement and per-team budgets become enforceable.
• An inventory you do not rely on people to fill in. Zalando reports that it auto-detects AI model use "through scanning of deployed Docker images", after which owners are asked for documentation or a legal review. The wiki's agent inventory and registry and policy enforcement pages cover the pattern; policy as code for agents covers writing the rules so a machine checks them.

The named cost: central controls slow the team that is ready first, and every exception becomes a ticket. That is the price of stopping a team that is not ready from holding an L4 credential it does not know about, which is how every destructive incident in this book began.

Provenance: who answers for the change

When AI writes part of every change, someone has to be able to say later what it wrote and who accepted it. Open-source projects had to decide this first, in public, and they split into three camps.

The stated reasons for bans are copyright, quality and ethics. For a company, the third camp is the workable default, and the kernel's format is the simplest to copy. The "latest" build of the kernel documentation (as of October 2026) gives this format and example; the 7.2 release documentation uses Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2] instead, so check the build you copy from:

Assisted-by: LLM [TOOL1] [TOOL2]

Assisted-by: LLM coccinelle sparse

The format is still moving. The development (linux-next) version of the same page, as of October 2026, drops the Assisted-by format and points to a separate document on tool-generated content, which asks for disclosure in cover letters and changelogs without fixing a tag; it keeps the rule that agents must not add Signed-off-by. Treat the trailer's syntax as yours to fix and its principle as settled: the AI is attributed, and only a human certifies.

That principle gets harder as the level rises. At L2 a human reviewed every diff, so the reviewer can sign. At L3 and L4 no human reads every diff, so who signs? The kernel's rule assumes a human submitter, so it does not say. The book's proposal: the agent never signs; at L2 the approving reviewer signs; at L3 and L4 the change carries the name of the human who owns that task class's routing rules or verification record, and that person answers for the class. The attribution must be machine-readable, because the L3 entry criterion, an escaped-defect rate for AI-run work against a human baseline, cannot be computed without it. The Templates appendix has the provenance policy, and the wiki's note on disclosure and content provenance covers the wider practice.

Licensing terms around provenance change too. Microsoft's Customer Copyright Commitment states that "as of April 3, 2026, there are no additional required mitigations" for GitHub offerings: "Use of the Duplicate Detection filter feature is no longer required for CCC coverage" (Microsoft Learn, page updated July 2026). A governance checklist written in 2024 that requires the filter for indemnity is now wrong on that point. Volatile terms like this live in Regulatory and Licensing Status (as of October 2026); check them against your own contracts.

Enablement and the platform team

Clarity tells people what they may do; enablement is what gets the 30–40% to try. The evidence here is thin. This book's research found no non-vendor enablement programme that has published before-and-after adoption or outcome numbers. The one programme with such numbers, Booking.com's, is published by its measurement vendor and is observational; The 90-Day Pilot reads it with that label. The best-described programme has no numbers at all.

Zalando: enablement without a mandate · T3 · engineering blog

Zalando's snapshot of agentic engineering (August 2026) describes a programme with five parts, alongside the proxy and inventory in section 15.4:

• A guild: weekly one-hour sessions "with 20-min slots for presentations or demos", recorded.
• Labs: on-site sessions "for ca. 20 people" lasting one to four hours; "over the course of 3 days we can run 6 sessions with ca. 120-150 participants across multiple locations".
• Guided hackathons: about ten topics chosen in advance, "tackled in a 2-3 day hackathon (with open sign-ups)".
• Standing trainings: two a month, "using MCP servers and building agents with pydantic-ai".
• An AI section on the Tech Radar.

One design rule stands out. Trainers "state explicitly when manual coding is expected from attendees", because "the temptation of participants to use coding agents as a shortcut to achieve results is high". Enablement that teaches people to delegate can also teach them to skip the learning; People: Roles, Skills and the Junior Pipeline takes that up for juniors.

The programme also shows the stance in practice. Tool choice is left to engineers ("based on available models and their own preferences (IDE vs. CLI)"), while access and model retirement run through the central proxy. Its risk-based review bot, read in Code Review, is the same pattern in the merge system.

What it does not show. Whether the guild, labs or hackathons changed adoption, delivery or quality, or which part mattered. It is a design to copy, not evidence that the design works.

The platform carries a trade-off. DORA counts a quality internal platform among the seven capabilities that amplify AI, but with it, AI's neutral effect on reported friction "is made harmful"; The AI-SDLC Maturity Model reads that finding. Guardrails add friction. Budget for the platform team to remove friction elsewhere, and do not read early complaints as failure.

Budgets belong to the platform too. Usage pricing without per-team budgets fails fast. Economics, Risk and Measurement covers Uber's reported overrun (T4, secondary). A gateway that meters per team, paired with an outcome metric per team, makes spend a decision rather than a surprise.

Regulation and performance reviews

For most software teams, regulation asks for literacy and documentation, not a ban on coding assistants. Two points belong in the stance; the dated detail is in Regulatory and Licensing Status (as of October 2026).

Literacy already applies. According to the European Commission, the EU AI Act's AI-literacy duty for providers and deployers has applied since 2 February 2025 (as of October 2026). An enablement programme like Zalando's can double as the record that you took measures, so keep attendance records.

Keep AI metrics out of individual reviews. Annex III of the Act lists as high-risk systems used "to monitor and evaluate the performance and behaviour of persons" in work relationships (Annex III, point 4(b), in the Future of Life Institute's consolidated text). Whether an AI-driven developer-productivity score falls under it is an inference that needs legal review, not a settled reading. The practical answer does not depend on the legal one: DX's advice against "using metrics for individual performance evaluation" and its warning that "Metrics like code generation volume are particularly susceptible to gaming" point the same way. Shopify's memo, as summarised in the press, does the opposite. Measure AI at team level, by flow and stability, as Measuring Success and When to Roll Back sets out. Where works councils or unions exist, the wiki's note on worker consultation and co-determination applies before any such metric is introduced.