Case Study: AI Coding Rollout at a 100-Dev Team, Quarterly Data

This is an AI coding rollout case study at a 100-developer engineering organisation. The team sustained a 28% productivity lift through month six and a 32-entry shared skill library — but the headline that mattered to the leadership team was simpler: both tools survived contact with developer preference, the productivity panel survived contact with the CFO, and the quarterly board update produced extension funding rather than scrutiny.

The org runs four product squads, twelve services, and a split-personality editor culture — roughly 60% IntelliJ-family, 30% VS Code-family, and a long tail of Vim and Emacs holdouts. A previous single-tool pilot had been abandoned at the 30-dev mark because mandating one editor created more friction than the AI tooling removed. This rollout took the opposite stance from day one: tolerate the editor choice, standardise everything else.

What follows is the playbook that worked. Situation, the four approach pillars — dual-tool rollout, shared skill library, hook and memory discipline, the productivity panel — and outcomes tracked across two quarterly reviews. Names and specifics are anonymised; numbers are exact.

The engineering organisation had attempted a Claude Code rollout twelve months prior. The pilot covered roughly 30 developers, ran for ten weeks, and was quietly retired before reaching general availability. The post-mortem reached the leadership team with three findings: developer adoption stalled at ~45% inside the pilot cohort, half the cohort was using a different editor than the one the pilot mandated, and the metrics panel commissioned to justify the rollout produced numbers neither engineering nor finance trusted.

The new rollout was scoped explicitly to fix those three failures at once. The first reframe was the most important: the previous pilot had treated editor choice as a controllable variable. This rollout treated it as a constraint. The second reframe was the metrics panel — rebuilt from scratch around engagement and quality signals rather than raw output. The third was governance: quarterly board updates were committed to before the rollout began, not bolted on after the first complaints.

The strategic insight from the prior pilot is worth naming directly: a developer-tooling rollout at 100-dev scale is not primarily an engineering problem. The engineering work is real but compressed. The hard work is governance, communication, metrics that survive cross-functional scrutiny, and tolerance for local variation in places where the variation is not load-bearing. The tool mandate had failed because the team got the load-bearing layers backwards.

The first architectural decision was to fund both Claude Code and Cursor licences for every developer in scope. The cost delta against a single-tool rollout was material — roughly 1.7× licence spend — but the team treated it as buying optionality rather than buying tools. The framing communicated to engineering was unambiguous: the standards layer is the skill library, the hooks, the memory templates, and the productivity panel. The tool is what each developer prefers to drive.

That stance produced a specific working pattern. Claude Code ran predominantly as a terminal-and-CLI surface for refactors, multi-file edits, codebase navigation, and review automation — heavy users in the JetBrains cohort kept their IDE and used Claude Code in a side pane. Cursor ran predominantly as an in-editor surface for line-level completion, in-context generation, and inline review — heavy users in the VS Code cohort kept their editor and reached for Claude Code only when a task needed terminal automation.

The friction the dual-tool stance produced was not zero. Two specific issues showed up in the first quarter. First, version drift: Claude Code and Cursor ship at different cadences, and the skill library had to be authored against the lower-common-feature surface of the two. Second, prompt portability: a prompt tuned to Claude Code's terminal context occasionally produced different output when invoked from Cursor's in-editor context — same model class, different surrounding context. Both issues had observable fixes; neither justified retreat to a single-tool mandate.

The skill library was the rollout's standards layer. Each skill was a versioned bundle of instructions, allow-listed tools, and an example trace — invokable from either Claude Code or Cursor via a shared registry. The starting kit shipped with nine skills authored by the platform team in week one. Six months later the library held thirty-two, with roughly half contributed by squad-level engineers and reviewed by the platform team before merge.

The growth curve was not linear. The library grew quickly in weeks two through six as squads identified obvious repeating tasks — JIRA-to-PR scaffolds, service-template generation, dependency audit reports. Growth slowed deliberately in weeks seven through twelve as the platform team imposed a contribution review process. The slow-down was a feature, not a bug; the team wanted the curve to flatten before unreviewed skills proliferated.

The most important governance decision was who could ship a skill. Initial proposals from squad engineers ranged from "anyone with merge rights" to "platform team only". The compromise that held: any engineer can propose, but every skill needs a platform-team reviewer and an example-trace test before it lands in the shared registry. Squad-local skills are permitted but namespaced and excluded from the global library — a release valve that reduced contribution friction without diluting the shared catalogue.

Hooks and memory templates were the third pillar — and the one that almost broke. At a 30-dev shop, hook configuration is a single shared template that everyone copies. At a 100-dev shop spread across four squads and twelve services, the same shared template approach produces conflicts within weeks: a squad needs a pre-commit hook the platform template doesn't cover, a service needs a memory exclusion the rest of the org doesn't want, an engineer overrides settings.json locally and the override silently propagates through skill invocations.

The rollout produced a discipline layer in response. Hook and memory configuration was split into three named tiers: a global tier owned by the platform team, a squad tier owned by each squad's lead engineer, and a personal tier owned by the individual. Each tier was versioned in source control, audited quarterly, and explicitly documented in the developer onboarding. The discipline cost roughly two hours of platform- team time per week and produced fewer than ten configuration incidents across the six months.

The non-obvious finding was that the discipline got harder, not easier, as the rollout matured. At week two, the platform-team tier was three hooks and four memory entries — trivial to maintain. At month six, the global tier was eleven hooks and twenty-three memory entries — a meaningful surface area, and a steady drumbeat of small platform-team work to keep current. The squad tier's surface area grew faster still. Teams that attempt this should plan platform-team capacity assuming the discipline gets harder over time, not lighter.

The metrics panel was the part most likely to repeat the prior pilot's failure. The prior pilot had used raw output metrics — lines of code, PRs per week, time-to-merge — and the numbers had been rejected by both finance (because they showed unattributable variance) and engineering (because the measurement felt punitive). The replacement panel was rebuilt from scratch with three goals: the engineers had to consent to the measurement, finance had to be able to reason about the attribution, and the panel had to behave the same way at the individual, squad and org levels.

The panel that shipped weighted four signals: skill invocations with successful trace completion, PRs accepted with no review-cycle defects, developer-reported friction (a two-question weekly pulse), and defect-rate drift across the twelve services. Raw output volume was deliberately excluded. Lines of code and PR count were available in the dashboard but relegated to context cards rather than headline metrics. The engineers signed off because the panel measured outcomes they cared about; finance signed off because the four signals triangulated each other.

The shape of the curve is worth noting: the lift was front- loaded into months two and three, plateaued through month four as hook discipline absorbed attention, and reached steady state at month five. The flat months four and onward were not a failure — they were the engineering team converting acute productivity wins into sustained capacity, which the panel captured as a quality-side signal rather than an output-side signal.

The panel survived the first quarterly board update on its own merits and was ratified for the second. That ratification became the rollout's most valuable asset: a productivity measurement the executive team trusted enough to extend funding against. The two-question weekly pulse fed back into the panel as a leading indicator — when developer-reported friction ticked up two weeks in a row, the platform team treated it as a priority signal and audited the global hook tier.

The outcomes section is short on purpose. Three numbers carried the second quarterly board update — productivity lift, library scale, and adoption depth — and a small set of stability signals confirmed the gains were not paid for in quality. The executive team extended the program; the engineering team absorbed the rollout into its ongoing platform work without ceremony.

Quality-side signals confirmed the lift was real. Defect rate across the twelve services drifted slightly downward over the six months — not a step change, but no regression. PR review cycle counts were stable. The two-question weekly pulse trended mildly positive from month three onwards. Developer satisfaction in the annual engineering survey, conducted at month seven, registered the rollout as one of the most-cited positive themes.

The cost ledger was uncomplicated. Licence spend ran at roughly 1.7× a single-tool rollout. Platform-team headcount stayed constant; the rollout absorbed about 0.6 FTE of platform-team attention through quarter one, falling to roughly 0.3 FTE through quarter two as the discipline matured. The executive team approved an extension and a modest expansion of platform- team capacity to support continuing library and hook governance.

Five replication notes from the six-month engagement. The pattern generalises across engineering orgs of similar shape and scale; the specifics of metric weights, library coverage and hook tiers will need re-tuning per environment.

1. Fund both tools deliberately.The 1.7× licence spend was the cheap line. The single-tool mandate that would have saved it would have cost more in adoption, goodwill and second-pilot-failure risk. Communicate this line in the executive deck as "buying tolerance," not as a procurement choice.
2. Build the skill library before the second tool. Nine starter skills covering the three highest-frequency tasks (review, refactor, scaffold) were the precondition for both tools producing comparable output. Without that substrate, the dual-tool stance becomes a two-culture problem within a quarter.
3. Plan platform-team time for hook governance. Hook and memory discipline gets harder, not lighter, at scale. Budget two to four hours of platform-team time per week for the global tier from week eight onward. The squad tier will demand similar from each squad lead.
4. Co-design the productivity panel with engineering and finance before week one. Engagement-weighted metrics produced cross-functional sign- off; raw-output metrics produced cross-functional rejection. The four-signal panel (skill traces, accepted PRs, friction pulse, defect-rate drift) is a portable starting template.
5. Commit to quarterly board updates before the rollout starts. Two formal reviews, same panel, same narrative shape. Executive air-cover compounds — the second review converted the rollout into a funded program rather than an experiment. Skipping the quarterly cadence is the single cheapest way to revert a rollout to pilot status.

One change we'd make on a redo: ship the productivity panel in week one with deliberately incomplete data, rather than at week six with the first three months ready. The panel-design conversation was the rollout's highest-leverage cross-functional artefact, and front-loading it would have compressed three weeks of executive uncertainty in the first quarter. The cost — looking a little under-prepared in week one — would have been worth it.

For engineering directors evaluating a similar move, the decisive question is whether the standards layer can be built and held one level above the tool. If yes, the dual-tool stance is on the table and the rollout pattern documented here applies with local tuning. If no — if the org cannot sustain a skill library, a tiered hook discipline and an engagement-weighted panel — the dual-tool stance will produce two cultures and should be deferred. Our team runs these engagements as part of our AI & digital transformation practice, and the playbook documented in our 30/60/90 day rollout plan and the companion 30-dev shop case study covers the pre-conditions in detail.