Building an AI-Native Development Platform at Scale

kilo · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: AI-native developer platforms

Kilo needed to build a development platform where engineers could orchestrate multiple AI coding agents, preserve trust at production speed, and keep feature delivery accelerating as coding work shifted from typing code to managing agent work.

Constraints:

Developers must keep enough context across repositories for orchestration to work.
Wrong model choice, slow suggestions, or missing context quickly erode trust.
Agent work can complete minutes, hours, or days after the original request, making evaluation harder.
Kilo wanted speed without turning feature ownership into broad collaboration overhead.

Architecture

Kilo organized its product and engineering system around developers as orchestrators. The platform exposes multiple out-of-the-box agents, including orchestrator, architect, code, ask, and debug agents, backed by repository context, model selection, instrumentation, and human review. Internally, Kilo paired the product model with one-engineer feature ownership so each developer could drive a feature end to end while using agents for code, debugging, and architecture support.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  developer-orchestrator[Developer Orchestrator] --> kilo-platform[Kilo Platform]
  kilo-platform --> agent-set[Agent Set]
  agent-set --> repository-context[Repository Context]
  agent-set --> model-router[Model Router]
  kilo-platform --> instrumentation[Instrumentation]
  developer-orchestrator --> human-review[Human Review]
  instrumentation --> human-review[Human Review]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Developer Orchestrator`	Human engineer who scopes work, manages agents, and remains accountable for output quality.	`Kilo Platform`, `Human Review`
`Kilo Platform`	AI-native development environment coordinating agents, context, models, and instrumentation.	`Developer Orchestrator`, `Agent Set`, `Repository Context`, `Model Router`, `Instrumentation`
`Agent Set`	Out-of-the-box orchestrator, architect, code, ask, and debug agents used for different software tasks.	`Kilo Platform`, `Repository Context`, `Model Router`
`Repository Context`	Codebase and cross-repository knowledge required for agent orchestration.	`Kilo Platform`, `Agent Set`
`Model Router`	Selects an appropriate model for each job to balance capability, latency, and cost.	`Kilo Platform`, `Agent Set`
`Instrumentation`	Captures signals about latency, usage, delayed task outcomes, and trustworthiness.	`Kilo Platform`, `Human Review`
`Human Review`	Human validation layer before accepting generated work.	`Developer Orchestrator`, `Instrumentation`

Data flow

A developer scopes a feature, routes work to Kilo agents such as architect, code, debug, or orchestrator, and relies on repository context plus right-model selection to execute tasks. Instrumentation monitors latency, usage, trust, and delayed orchestration outcomes; human reviewers inspect the resulting work before production.

“the developer is becoming the orchestrator. They're um managing AI agents, they're guiding the vision, they're doing the things that humans are are really, really good at. Um and then what we're also doing at Kilo, um and take this”transcript, stated

“And so we've really spent a lot of time on instrumentation just to make sure that we're knowing and getting as much signal as we can”transcript, stated

Why this architecture

Kilo's architecture follows the belief that developers become orchestrators rather than pure coders. Multi-agent roles let work split by task type, model routing avoids using the most expensive model for every step, instrumentation keeps trust measurable, and human review preserves accountability.

“But what's what's shifting is you're going to like 80% thinking, 20% coding or even less coding. And that's quite taxing. I mean, I think what what I've what's been really interesting to to observe is as someone joins the Kilo engineering team,”transcript, stated

“fast. What we're big believers in is um picking the right model for the job. You know, for those complex architecture tasks, yeah, start with a state of the art model. For when you're coding, debugging and you want to move fast, use”transcript, stated

Models used: task-selected state-of-the-art models · Kilo agent models

Scale

Kilo reports 25-plus trillion tokens processed since launch.
“from experience. We've had 25 plus trillion tokens processed since we launched in May, um and over 1.5 million developers. And so, what we've done is we've kind of combined some anecdotes from talking to users and actually the the data we mined to pull some lessons on”transcript, stated
Kilo reports over 1.5 million developers.
“launched in May, um and over 1.5 million developers. And so, what we've done is we've kind of combined some anecdotes from talking to users and actually the the data we mined to pull some lessons on”transcript, stated
Kilo says feature delivery moved from one feature every two to three weeks to one or two features per week.
“they were shipping one feature every two to three weeks, and Kilo included. Uh where we are today, it's orders of magnitude different. We are shipping one to two features a week.”transcript, stated
A latency peak at 200 milliseconds was enough to reduce usage.
“know, we even noticed that when our latency peaked at 200 milliseconds, usage went down. And I mean, I think that's what we've been obsessively focused on is monitoring how how usage is kind of trending, and um obsessing about how to make it faster and faster”transcript, stated

Alternatives considered (roads not taken)

Team-owned feature development with broad collaboration.

Rejected because: Kilo deliberately favors end-to-end ownership to preserve speed and accountability.

“we try to avoid collaboration at all costs. We are very anti-collaboration. Um big, you know, shout out to the PostHog team. They have a great blog post on kind of the downside of collaboration.”transcript, stated

Use the latest state-of-the-art model for everything.

Rejected because: That approach wastes money and slows ordinary coding work.

“if you throw everything at the latest state of the art model, you're spending a lot of money, you're essentially heating your home with inference.”transcript, stated

Treat orchestration like a single-repository problem.

Rejected because: The platform needs cross-repository awareness for real agentic development.

“when you're doing orchestration, it's not just it needs to know the it just needs to know one repo, it needs to know all your repos.”transcript, stated

Patterns

`multi-agent-orchestration` (agent-architecture)

Kilo exposes distinct orchestrator, architect, code, ask, and debug agents so developers can route work by task.

“five out of the box agents that come at Kilo. We've got our orchestrator, we've got our architect, code agent, ask agent, debug agent.”transcript, stated

`model-routing` (model-strategy)

Kilo treats model choice as part of the platform, routing simpler coding tasks away from expensive frontier models.

“you need the right model for the right task. And you need a tool that helps you”transcript, stated

`observability-tracing` (operations)

Kilo instruments usage and delayed orchestration outcomes to understand whether agentic features remain trustworthy.

“the task that's running and the result happens, you know, minutes, hours, days later. We found that's kind of when you start to get really, really challenging”transcript, stated

`human-in-the-loop-gate` (quality-control)

Generated work remains subject to human review, with discretion left to the developer.

“everything is reviewed by human. Maybe not every single line. We leave it to the discretion of the developer”transcript, stated

Tradeoffs

Engineering operating model

Chose One engineer owns each feature end to end over Team-owned collaborative feature delivery.

Rationale: Kilo uses single-owner features to match agent-accelerated work and reduce coordination overhead.

“every engineer owns a feature. It is not a team that owns a feature. There's only one engineer per feature.”transcript, stated

Model selection

Chose Route to the right model for the job over Send every task to the latest frontier model.

Rationale: The latest model is useful for complex architecture, but using it everywhere increases cost and latency.

“for those complex architecture tasks, yeah, start with a state of the art model. For when you're coding,”transcript, stated

AI autonomy boundary

Chose Developer-as-orchestrator with human review over Fully unattended agent output.

Rationale: Kilo frames the developer as the tastemaker and architect even as agents do more coding.

“They are the tastemaker, the architect,”transcript, stated

“everything is reviewed by human. Maybe not every single line.”transcript, stated

Gotchas (what bit them)

Trust can collapse at small latency thresholds.

Root cause: Developers turn off AI assistance after a few slow suggestions.

Resolution: Monitor latency and usage tightly rather than treating speed as a secondary UX metric.

“if you get in a few set of slow suggestions in a row, I'm turning off autocomplete.”transcript, stated

Agent orchestration needs broader context than a single repository.

Root cause: Real development tasks cross repository and ecosystem boundaries.

Resolution: Invest in context systems that know all relevant repositories.

“it needs to know all your repos. And so I'll give you an example.”transcript, stated

Delayed agent outcomes make feature trust hard to measure.

Root cause: The request can run through an orchestrator and complete long after the initial prompt.

Resolution: Spend heavily on instrumentation to capture trust and effectiveness signals.

“minutes, hours, days later. We found that's kind of when you start to get really, really challenging in understanding if, you know, the request to to the orchestrator”transcript, stated

Evaluation

Kilo evaluates through production signals: latency changes, usage drops, shipping velocity, trust instrumentation, and human review of generated work.

Metrics: Tokens processed · Developer count · Latency at 200 milliseconds · Feature shipping cadence · Usage trends · Human review outcomes

“usage went down. And I mean, I think that's what we've been obsessively focused on is monitoring how how usage is kind of trending”transcript, stated

“the proof is in production. Really don't believe me on these stats, just take a look at kind of our product roadmap”transcript, stated

Outcomes

Kilo reports more than 25 trillion tokens processed and over 1.5 million developers.
The team says feature shipping moved from every two to three weeks to one or two per week.
The product exposes five default agents for orchestrator, architect, code, ask, and debug workflows.

The source gives token, developer, latency, and shipping-cadence figures, all framed as production learning rather than lab-only benchmarks.

“We are shipping one to two features a week.”transcript, stated

“We've had 25 plus trillion tokens processed since we launched in May, um and over 1.5 million developers.”transcript, stated