A Coding Agent That Picks Its Own Models, and Why One Engineer Hit a 95% Merge Rate

The interesting move here is not that a coding agent uses good models, it's that Atomic reads public benchmarks and documents its own reasoning for which model fits which task. Ray Fernando relays a claim from an engineer who reports a 95% merge rate using Atomic, having shifted trivial work off Claude Code entirely. The clip frames this as a shift toward a principal-engineer style of working, where the human sets direction through prompts and skills while the agent handles model routing. Open weights models like Kimi K3 and GLM 5.2 sit at the center of that routing.

The 95% Merge Rate Claim

The headline anecdote is a 95% merge rate. An engineer told Ray he had "completely moved off" Claude Code for trivial tasks and now runs those directly through Atomic, using the Claude subscription as the underlying model access. Read this carefully. The engineer did not abandon the model, he changed the harness sitting on top of it. The claim is about workflow and merge outcomes, not about one model beating another in isolation.

A 95% merge rate is a workflow metric, not a benchmark score. It measures how often the agent's output gets accepted into the codebase without rework. That number depends as much on task selection and orchestration as on raw model quality, which is exactly the point Ray is making about the "principal engineering approach."

Self-Documenting Model Selection

The core mechanism Ray describes is model routing that explains itself. Atomic reads popular coding benchmarks and maps model strengths to task types, then documents that mapping so the reasoning is visible rather than hidden. In his words, Atomic "knows what model is good for what task" and is "self-documenting in the way" it makes those calls.

This matters because most agent frameworks hard-code a single model or make you pick one manually. A system that ingests live benchmark data and writes down why it chose Kimi K3 for one job and GLM 5.2 for another turns model selection into an auditable decision instead of a black box. The self-documentation is the differentiator, not the routing alone.

The Benchmarks Feeding the Decisions

The video shows two benchmark leaderboards on screen, both referenced as inputs to Atomic's routing. The first is a FrontierCode Leaderboard, displayed as a set of line curves plotting model performance. The second is DeepSWE, shown both as a scatter of models across a cost-versus-score frontier and as a horizontal bar chart ranking individual models. Ray also names Artificial Analysis as a third source.

Together these represent three different lenses on coding model quality: a frontier coding benchmark, an SWE-style task benchmark, and an aggregator that normalizes results across providers. Feeding all three into one routing decision is more defensible than trusting any single leaderboard, since each benchmark has its own blind spots and gaming risks.

Why Open Weights Models Are the Story

Ray singles out the "open source model thing" and points to Kimi K3 doing "incredibly well in the benchmark." His explicit recommendation is Kimi K3 and GLM 5.2. The subtext is that open weights models have reached a level where a routing agent can lean on them for real work, not just experiments.

This is the practical case for open weights in agentic coding. When an agent can route trivial tasks to a strong open model and reserve premium closed models for the hard cases, the cost structure of running a coding agent changes. The 95% merge rate anecdote and the open model recommendation are two halves of the same argument: pick the right model per task, and much of that "right model" can be open.

Key Takeaways

• The differentiator is self-documenting routing, not the models themselves. Atomic reads benchmarks and records why it picked a given model for a given task, making model selection auditable.
• A 95% merge rate is a workflow claim. It reflects task selection and orchestration as much as raw model quality, which is why Ray frames it as a principal-engineering approach.
• Three benchmarks feed the decision. FrontierCode, DeepSWE, and Artificial Analysis each cover different ground, and combining them hedges against any single leaderboard's blind spots.
• Open weights models carry real work now. Ray's recommendation of Kimi K3 and GLM 5.2 signals that open models are strong enough to handle trivial and routine coding tasks directly.
• The harness changed, not the model. The engineer kept his Claude subscription and swapped the layer on top, which is the actual source of the reported gains.
• Model routing is becoming a first-class product feature. The value is shifting from which single model you pick to how well a system distributes work across many models.

Resources

• Artificial Analysis - Independent benchmarks comparing AI models on quality, speed, and cost across providers.