The tools were never the hard part
When we started our agentic coding initiative, every conversation was about tools. Which agent, which model, which IDE, which vendor. It's the natural first question, and it's the least important one. We eventually reached 100% engineering onboarding across the division, with more than 80% of engineers still actively using the tooling in any given week — sustained, not a pilot spike — and a measured 10–15% lift in engineering capacity. Looking back, the tool choices explain almost none of that. Three things explain most of it.
Adoption is an operating-model change, not a rollout
The default enterprise playbook — buy licenses, run a pilot, publish a usage dashboard — produces exactly what it measures: logins. What moved our numbers was changing how work flows, so that using the tools was the path of least resistance rather than an individual's side experiment. We shifted quality gates left: agent-run validation and eval-style checks before a PR ever reaches a human. Pre-merge defect escape fell 40%, and review turnaround roughly halved — not because reviewers got faster, but because what reached them was already better. Once the operating model changed, adoption stopped being something I had to push. The engineers who felt the difference did the evangelizing.
Context is infrastructure
A coding agent is constrained by the quality of the context in front of it. That sounds obvious until you look at a real codebase and realize it was written for readers who already knew where everything was — the rationale, the constraints, the tribal knowledge that never made it into the repo. An agent dropped in cold does what any new hire would do: something plausible and wrong. So we started treating context as engineering infrastructure. We built a context-engineering framework for capturing the non-inferable knowledge — why the architecture is shaped this way, what must never change, where the bodies are buried — and made documentation freshness something that's maintained automatically, not aspirationally. This is the least glamorous work in the whole program and it had the highest return. Documentation used to be overhead justified by onboarding; now it's load-bearing at runtime.
The bottleneck moves
Once implementation gets cheap, the constraint doesn't disappear — it moves upstream. Lead time for our largest stories fell from a full sprint to three to five days, and the moment that happened, the scarce activities became framing the problem, specifying what good looks like, and judging the result. Most of the failure I've seen in AI-assisted engineering isn't bad output. It's a well-executed answer to the wrong question — optimized waste. The engineers who thrive in this environment aren't the fastest typists or even the best prompters; they're the ones who ask the right question before any code is written. Building an organization that selects for and develops that skill is, I think, the actual job of an engineering leader now.
If you're starting now
Start with the operating model, not the tooling menu — decide where agent work enters the flow and what verifies it before a human sees it. Treat context as infrastructure and fund it like infrastructure. And instrument outcomes, not activity: weekly-active is a vanity number unless capacity and quality move with it. The tools will keep changing under you every quarter. The organization you build around them is the part you get to keep.