Driving Adoption

Buying licenses is not adoption. Spreading AI-enabled engineering across an org takes deliberate mechanisms -- champions, tiger teams, internal talks and hackathons, and making the supported path the easy path -- so practices actually take hold rather than stalling after the pilot.

The Pattern

Buying licenses is not adoption. Getting AI-enabled engineering to actually take hold across an organization takes deliberate mechanisms: engineers training engineers, internal talks and hackathons that spread practice peer-to-peer, and -- most durably -- making the supported path the easy path so the right way is also the path of least resistance. Mandates underperform proof. As Meta's Ian Thomas frames it, "code wins argument" becomes "proof wins argument": adoption spreads when engineers see colleagues getting real value, not when leadership decrees it, because "if you get a top-down mandate, engineers can be quite skeptical."

The risk that motivates the deliberate version: handing out tools without onboarding doesn't just stall -- it makes bad practices worse, faster. One engineering org described by Tomasz Maj (AI DevCon London 2026) treated onboarding, not enthusiasm, as the real problem and reached 93% adoption (only 6 of ~150 developers not using AI) by getting engineers to teach engineers -- "find nerds that will help nerds" -- running sessions in person, setting a shared baseline (what is a model, what is a token) before the cool tools, and making it continuous with homework between sessions where people try something and report back what worked and what failed. He partnered with an external firm specifically to grow internal trainers rather than become a permanent dependency, and noted the material needs refreshing every couple of weeks.

Why It Matters

Tool pilots routinely succeed and then stall: a few enthusiasts get huge value while everyone else drifts back to old habits. Adoption is a distribution problem, not a procurement one. The organizations that scale it treat enablement as real work -- surfacing wins, lowering the activation cost, and meeting teams where they are.

It also requires taking resistance seriously rather than routing around it. Cecilia Borg, drawing on her work as interim CTO at podcasting company Acast (a 110-person, remote-first product org), takes the senior-developer backlash seriously -- some skepticism about bloated code and mounting technical debt is well earned. Her playbook is small steps and guiding principles: give people time to learn a tool that at first "feels like eating with your non-dominant hand," have engineering managers negotiate with product to slow velocity so teams can run hackathons and explore, and don't ship without taming the bots on testing and review (see automated-review-verification).

The honest tension: adoption can cost productivity before it pays. Daniel Langkilde, CEO of Kognic, reported three months into an acceleration push that the org had "likely lost productivity over the last three months due to the time required to learn new things" -- the classic short-term-for-long-term trade-off -- and that code quality was "(probably) slightly worse than before, but we're sooo much faster that the degradation is worth it. Probably." And success relocates the bottleneck rather than removing it: as coding and review time collapse, the constraint moves to the backlog, to product strategy, and to the designers, PMs, and analysts the same momentum now has to reach. Personal productivity gains do not automatically become organizational ones. Driving adoption is therefore inseparable from calculating-roi and from honest measurement, not self-congratulatory dashboards.

Last reviewed: 2026-06-25