How AI Adoption Deepens in an Engineering Org
5 stages of feature usage, and what to measure at each one
AI adoption is something most engineering orgs are still figuring out, and it’s only legible if you look at the right things. Watch which features people reach for and in what order, and you get a usable picture of how far the tooling has gotten into the work. The sequence is consistent across teams, which means you can locate your median engineer on it and know what the next step is going to require from you.
Kilo is available across the IDE, the CLI, and the web - and it’s model-agnostic, so our telemetry covers roughly 3 million developers and more than 40 trillion tokens without being shaped by one vendor’s product surface.
The pattern below is what shows up in that data, and it maps onto what teams tell us about their rollouts.
Five stages
Inline completion is stage one. Autocomplete lands immediately in every org because it asks nothing of the developer and changes no habits. Numbers here are high everywhere, so they mostly tell you the install worked.
Stage two is single-file agentic editing, where somebody describes a change and reviews a diff instead of typing it out. This is where a lot of orgs settle in for a long time. Usage looks healthy, developers like the tool, and the pipeline runs the way it always did.
Stage three is multi-file work with a plan in front of it, the point where a developer hands over something they can’t hold entirely in their head. This one depends on context infrastructure more than on enthusiasm. Codebase Indexing gives semantic search across the repo using cloud-hosted embeddings, and Plan Mode outlines architectural decisions in the project instead of the prompt, so nobody needs to re-explain the same service boundaries during a session. With those in place, stage three sticks. Without them, attempts fail often enough that people quietly go back to stage two.
Stage four is concurrency: parallel agents in the IDE and CLI, Cloud Agents running from the web dashboard with no local machine involved, and Sessions that persist across interfaces, so a task started by one teammate in the CLI can be finished in VS Code by another. Once someone is supervising work rather than performing it, their output stops being bounded by typing speed.
Stage five is the workflow carrying itself. Code Reviewer analyzes every PR the moment it opens with the model you picked, surfacing security, performance, and test coverage issues before a human looks. The Kilo CLI is used in autonomous mode to hook into CI/CD flows, and Cloud Agents are triggered by external systems with webhooks, automating code workflows while the team sleeps.
Stages one and two are individual conveniences that show up in developer satisfaction. Three through five are where org throughput moves, and they’re the stages worth instrumenting.
Governance from the top, selection from the bottom
AI tool adoption is happening (or being encouraged) at all heights. Bottom-up rollouts, where IC engineers recommend and settle on tooling, get you real usage because nobody had to be sold. In our conversations with enterprises, we’re hearing that AI tool discovery is increasingly happening this way. What this stream doesn’t always carry is shared practice, so you can end up with nine tools, four billing relationships, and no idea whether the payments team found something the mobile team could reuse. Top-down rollouts get you SSO, pooled billing, and a number for the board deck, but they tend to standardize on a single model provider on the way there.
Our managed org data suggests standardizing is the part to hold loosely. Multi-provider usage on team subscriptions climbed from 42% to 71% in a single quarter, following the curve individual developers were on about two quarters earlier. Bucket by volume and it gets sharper. Developers under 100 requests a month average around 1.5 providers, developers above 10,000 average more than 7, and 92% of that group works across multiple providers.
Experience is what drives that. Heavy users have hit enough edge cases to know which model handles which kind of task, so the deeper someone gets up the ladder, the more selection matters to them.
The combination that works is buying governance, security, and visibility centrally while leaving model choice with whoever is holding the ticket.
What to measure
Activation belongs in the report as a prerequisite. Beyond 80%, it stops carrying information.
Feature depth is a number to build the score around: distinct features and surfaces per active developer, weighted toward the later stages. It tells you where your median engineer sits and gives you something that moves when a rollout is working.
Workflow penetration measures how much of the pipeline runs through AI. Share of PRs that get an automated review before human review, share of agent sessions that end in a merged change, and share of bugs caught by the AI reviewer are good metrics to pay attention to.
Practice retention asks whether features like custom modes and skills get shared across a team or stay with their author. Shared modes mean your strongest engineers are duplicating their judgment into the org, which is the closest thing to institutional learning in any of this.
What can halt your climb rate
Most adoption stalls trace back to friction, and often policy rather than product.
The Pragmatic Engineer’s 2026 survey of over 900 engineers found roughly 30% hit usage limits monthly, with a mid-task token wall ranking among the most disruptive things that happen to them. Losing a session halfway through a refactor costs you the context you spent twenty minutes building, so the rational response is to stop attempting work that size, and stages four and five never fill in.
Approval workflows work the same way on a longer timescale. If exceeding a cap needs a manager’s sign-off, people scope the task down until it fits. Stack Overflow’s 2025 survey of more than 49,000 developers put autonomy and trust ahead of compensation as a satisfaction driver, and a usage cap speaks to both.
That’s one of the reasons why fixed-rate coding plans don’t always scale to the enterprise. The pricing is unclear, subject to change, and can backfire towards the end of the month. The better option is to build scalable systems using flexible tools with open pricing, so that you’re not guessing which parts of your policy require optimization.
None of this works without observability
Everything above assumes you can actually see feature depth, workflow penetration, and practice retention. Most orgs can’t, because their only instrumentation is a billing dashboard, and a bill tells you what something cost, not what it did.
Kilo’s usage analytics and AI ROI Dashboard cover the adoption question, showing which features and surfaces a team uses and how that shifts over time. The centerpiece is the AI Adoption Score, a single 0 to 100 number built from three weighted dimensions: frequency at 40%, how often developers use AI, depth at 40%, how integrated it is into actual development, and coverage at 20%, how broadly it’s spread across the team.
Cost Insights handles the finance question separately, plotting spend across 7, 30, or 90 days with the largest contributors by product and member, and Spend Alerts run at the org and personal level on rolling 24 hour, 7 day, and 30 day thresholds so anomalies arrive as notifications rather than as an invoice.
Auto Efficient is one feature that keeps the cost question from turning into a cap. It does session-aware routing, matching each task to the cheapest model that can handle it across 500+ models, and about 38% of the switching we see is developers doing that math by hand one task at a time. Automating it pulls blended cost per task down far enough that limits stop coming up.
For the rollout itself, seed with your heaviest users, have them build the custom modes and skills, and turn on Code Reviewer early since it makes AI a pipeline default rather than a personal choice. Then read feature depth at 30, 60, and 90 days using the actual usage data rather than a spend report.
Where this lands
An org at stage five looks specific. The median engineer supervises work rather than typing it, PRs get reviewed before a human opens them, the team’s best practices live in shared modes, and nobody is trimming a task to stay under a threshold. Every one of those is readable from feature data, and each one has a concrete thing standing in front of it that you can go remove.
Move at Kilo Speed. Get started with Kilo for Enterprise