iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Developers do not adopt AI coding agents because a benchmark says a model is powerful. They move from autocomplete to chat, then to single-agent tasks and multi-agent orchestration only when each stage proves reliable, understandable and worth the risk. That is the central finding Brendan O’Leary presented in a QCon AI session recorded June 2, 2026, and transcribed by InfoQ on October 15, 2026.
The presentation analyzes Kilo Code gateway telemetry covering more than 25 trillion tokens and 1.5 million developers in its conference abstract; by the recording, O’Leary said the system had processed more than 40 trillion tokens. The figures describe Kilo Code’s early-adopter cohort, not the software industry as a whole, but they offer unusually large-scale evidence about what makes agentic coding useful in practice.
What the presentation measured
Kilo Code is described as an open-source agentic engineering tool with command-line, VS Code, JetBrains and cloud-agent surfaces. Its gateway allows users to access more than 500 models, giving the team a view of model requests across different workflows.
The analysis is behavioral telemetry rather than a controlled adoption study. It excludes anonymous and internal users, removes automated traffic and excludes autocomplete from most analyses. The users are not a random sample: many deliberately sought open-source, configurable tooling, so they are likely more technically curious and more tolerant of experimentation than the average developer.
One trend is clear inside this cohort. During the eight weeks leading through April, Anthropic’s share of gateway requests fell from 11.2% to 6.5% while users and request volume tripled. That change does not establish that one provider became better or worse; it shows that developers increasingly combine models as they find different models useful for different tasks.
O’Leary’s strongest warning is against treating these percentages as an industry-wide adoption rate. The presentation does not provide a representative rate, a causal experiment or robust comparisons by department, programming language or task type.
Adoption is a ladder, not a switch
Developers generally climb four stages. Reliability at a lower stage determines whether they will grant an agent more autonomy at the next one. The longer the agent runs without a useful signal, the harder it is for a person to notice and correct a wrong turn.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Stage | Autonomy | Feedback loop | Context and retrieval | Routing and observability | Failure cost |
|---|---|---|---|---|---|
| Autocomplete | Suggests a small edit; the developer accepts or rejects it | Immediate | Usually limited to nearby code and editor state | Often little model choice; intermediate decisions are not relevant | Low; an incorrect suggestion is easy to discard |
| Chat | The developer directs each exchange | Seconds to minutes | Conversation history and manually supplied files or instructions | Some model choice; reasoning is visible mainly through the response | Moderate; errors consume attention and time |
| Single agent | Executes a multi-step coding task | Minutes | Requires dependable retrieval of repository files, conventions and task details | Model routing and progress reporting become important | Higher; an agent can edit several files or pursue the wrong plan |
| Orchestration | Multiple agents coordinate work | Longer, sometimes with extended periods between useful updates | Broad, structured context shared across tasks and agents | Provider-independent routing and detailed intermediate signals are essential | Highest; recovery is difficult when the system fails silently or loses state |
This ladder explains why a team can use chat every day yet hesitate to authorize autonomous agents. The later stages lengthen the feedback loop and increase the amount of context that must be correct before an agent can be trusted.
Why benchmark scores do not predict workflow adoption
Benchmark capability is only one input into a working system. A model can score well and still be a poor fit if it cannot retrieve the repository information a task requires, if routing forces every task through the same provider, or if developers cannot see how it reached an intermediate decision.
In O’Leary’s account, trust and workflow fit are stronger adoption signals than a headline score. Developers repeatedly test whether an agent gives them the right context, makes progress they can inspect and responds quickly enough to correct. A tool that is slightly less capable but predictable and observable can therefore earn more use than a stronger model hidden behind a long, opaque loop.
“What we’ve learned over these 40 trillion tokens we’ve seen, is that adoption really depends on if the system can earn trust,” O’Leary said.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
The three technical breakpoints
1. Context construction
Agents cannot act on files, conventions or requirements they never receive. O’Leary calls a well-designed retrieval system the “number one thing to get right” and recommends treating context as infrastructure, not as a feature added after the model is selected.
For an engineering team, that means building repeatable retrieval for the repository and the task rather than asking every developer to paste background into a prompt. Useful context can include the relevant modules, local coding conventions, build commands, test expectations and the issue or design decision being implemented. The retrieval process should be consistent enough that two runs of the same task start with materially similar information.
2. Model routing
Different tasks favor different models. The gateway’s access to more than 500 models illustrates why a single-provider assumption can become a constraint as usage grows. Routing can select a model for code generation, repository analysis, testing or a specialized language, while preserving a common interface for developers.
Provider independence also reduces the risk that a change in one model, price, limit or availability will halt an internal workflow. The observed fall in Anthropic’s request share, from 11.2% to 6.5% over eight weeks as the cohort expanded, is evidence of diversification within Kilo Code’s users—not a universal market-share measurement.
3. Feedback loops
Feedback must become more detailed as autonomy increases. Autocomplete can be judged immediately; an orchestrated system may run for a long time before producing a final patch. Showing only the final output leaves developers with no way to tell where the system went wrong.
O’Leary argues that tooling should expose the context supplied, the decisions made and the intermediate progress, not just the files changed. Those signals let a developer stop an incorrect plan early, distinguish a retrieval error from a model error and decide whether to continue, revise the task or switch models.
“Your tooling has to surface what agents decided not just what they did.”
How trust develops—and how it disappears
Trust is asymmetric: many successful interactions can establish confidence, while one visible failure can destroy it. A rollout that gives a new agent broad permissions before users understand its behavior creates exactly the kind of high-cost failure that stalls adoption.
O’Leary recommends beginning with developers who are patient with ambiguity and willing to iterate. Their successful examples provide social proof for more skeptical colleagues. Senior engineers can benefit especially when they understand the system and know how to provide precise context; established patterns, conventions and tests make agent work more reliable.
The practical implication is to make autonomy earned rather than assumed. Start with tasks where a person can inspect the result quickly, instrument the agent’s intermediate work, and expand its permissions only after the team has evidence that the feedback loop is adequate.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A staged rollout for engineering organizations
- Map current usage. Separate autocomplete, conversational help, single-agent tasks and multi-agent experiments. Record where developers already accept suggestions and where they abandon an agent.
- Choose low-cost pilot tasks. Begin with work that has clear tests, bounded file scope and an easy human review path. Avoid making an early pilot depend on undocumented tribal knowledge.
- Build retrieval before adding autonomy. Establish how the system finds repository files, conventions, task requirements and validation commands. Treat retrieval quality as a platform capability owned by the engineering organization.
- Keep routing flexible. Support more than one model or provider so teams can match models to tasks and continue operating when a provider changes limits or behavior.
- Expose intermediate signals. Log the context used, plan, tool calls, decisions, test results and current status. Give developers a clear stop or revise action before a long run compounds an error.
- Measure recovery, not just completion. Track how quickly a developer detects a wrong path, how much work must be reverted and whether the agent’s output passes the team’s normal checks. A fast recovery loop is a better readiness signal than a single impressive demo.
- Expand by demonstrated trust. Share successful examples from the pilot group, then invite more skeptical users to try comparable tasks. Increase autonomy only when the system’s context, routing and feedback behavior remain dependable.
What the 25-to-40-trillion-token view can—and cannot—say
The scale makes the telemetry valuable as a real-world signal: it captures repeated choices by more than 1.5 million developers using a gateway across many models and interfaces. It also reveals that multi-model use is increasing within this population and that adoption is tied to the quality of the surrounding workflow, not simply to a model’s benchmark position.
It cannot tell an organization which department, language or task will perform best, nor can it prove that a particular routing or retrieval design caused adoption. The senior-engineer advantage described by O’Leary is qualitative, and the cohort’s early-adopter composition limits generalization.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →The durable lesson is operational. Developers grant agents more authority when the system supplies the right context, can choose an appropriate model and shows enough of its reasoning and progress for a person to intervene. Without those conditions, teams tend to remain at chat—not because they reject agents in principle, but because the next rung has an unacceptable cost of failure.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
