The Unglamorous Middle of AI Tooling Adoption

Every engineering leader I talk to right now is at roughly the same place: they've seen the demos, they believe the tools are real, and they are trying to figure out how to move a team of humans from "I'll try it sometimes" to "I can't imagine shipping without it." That middle part — the adoption curve between early excitement and durable habit — is where the interesting work actually lives. And it is considerably less glamorous than the benchmarks suggest.

We've been through this with a 12-engineer cross-functional team shipping iOS, Android, React Native, and Unity products. Claude Code and Cursor are now default workflows. It took longer than I expected, succeeded for reasons I didn't fully anticipate, and almost failed twice for reasons that had nothing to do with the tools themselves. Here is what I would tell myself a year ago.

Context is the product

The first thing that surprised me: out of the box, these tools are a fraction of what they become once they know your codebase. Everyone understands this conceptually. Very few teams invest in it seriously. We spent real time writing CLAUDE.md files, architecture decision records, and in-context API notes that told the model what our conventions actually are — not generic best practices, but the specific choices our team made and why. That investment paid back quickly and kept paying.

The engineers who complained that Claude Code "doesn't understand our patterns" were almost always the ones who hadn't given it any patterns to understand. Once we fixed that — once the context was good — the same people became the strongest advocates. The tool hadn't changed. The input had.

The engineers who got the most out of AI tooling were the ones who treated context as engineering work, not setup overhead.

This generalizes. Every mobile platform we ship has its own idioms: Swift's actor isolation model, Kotlin coroutine patterns, React Native's bridge constraints, Unity's physics tick timing. None of that is obvious to a general-purpose model. The teams that documented it got leverage. The teams that skipped it got frustration.

Start with the skeptics

The instinct is to start with the enthusiasts — the people who are already excited, who will give you positive signal fast. I'd argue that's backwards. The enthusiasts will adopt regardless of what you do. Their experience tells you almost nothing about whether the rollout will stick across the whole team.

We ran a quiet experiment: paired Claude Code with two of our most skeptical engineers on a well-scoped problem they were already stuck on. We didn't pitch it. We just sat down with them and worked through it together. By the end of the first session, both of them had changed their position — not because I convinced them, but because the tool addressed the exact friction they had named. One of them became the de facto evangelist for the Swift side of the team.

Skeptics have better objections. When they convert, they convert with credibility. And if the tool can't win them over on a real problem, you've learned something important before you've scaled anything.

Evals before you scale, or you're just moving bugs faster

This is the one I feel most strongly about, and it is the one teams skip most reliably. If you roll out AI-assisted code generation to twelve engineers without tightening your eval harnesses first, you will ship more code faster — and some fraction of that additional velocity will be additional defects. The model is confident in ways that are sometimes wrong. Engineers working quickly will miss what the model misses. Review latency doesn't automatically scale with output volume.

Before we went team-wide with AI-assisted generation on our highest-risk flows, we built structured-output schemas for the outputs that mattered most, added automated eval checks for the patterns most likely to go wrong, and made guardrails part of the PR template. That work felt slow at the time. It felt fast in retrospect, when we didn't have a regression incident to explain in a postmortem.

The eval harness is the thing that lets you move faster without the error rate climbing in lockstep. Without it, AI tooling is a gas pedal with no brake. Most teams figure this out after they've needed the brake.

What it looks like now

A year in, Claude Code and Cursor are default-on for every engineer on the team. We have CLAUDE.md files in every major repo. We have evals running in CI on our most critical output paths. New engineers get onboarded to AI tooling the same week they're onboarded to the codebase — it's part of how we work, not a bonus feature for people who opted in.

The biggest change isn't in individual output. It's in what kinds of problems the team is willing to take on. The work that used to feel too expensive to prototype gets prototyped. The refactor that wasn't worth the sprint gets done in a day. The bar for "good enough to investigate further" has shifted — and that's where the compounding value is.

If you're in the unglamorous middle of your own AI tooling rollout — past the demos, not yet at durable habit — I'm happy to compare notes. Reach me at arun@arunjalota.com.

Arun Jalota is a Technical Director in Toronto leading a 12-engineer mobile team and driving AI tooling adoption. Reach him at arun@arunjalota.com · LinkedIn · GitHub.