The Capability Curve Is Your Roadmap, Not Your Benchmark
The abstract for this talk names the capability curve as the thing builders on Claude need to think about. I want to take that further. The curve is not a chart you look at once a quarter and feel impressed by. It is the variable that quietly resets your engineering plan every few months, and most teams I work with are not building for it. They are building around the last version of it.
I have spent the last year watching teams discover, sometimes painfully, that the workflow they wrote in the summer is overbuilt by autumn. The model got better. The scaffolding they built to compensate for its weaknesses now costs more than it earns. That gap, between the model you wrote your code for and the model you are actually calling, is where the real planning conversation lives.
Three things to take away
- The capability curve is not one line. Reasoning depth, tool use reliability, long-context recall, and code generation each have their own slope, and they do not move together.
- Code that "ages well" against the curve gets shorter as the model improves. Code that ages badly only works once it improves.
- Your job as the builder is to write less scaffolding, not more clever scaffolding.
Curves, plural
When people talk about "the capability curve" they usually mean a single line going up and to the right. That mental model is wrong, and it produces bad planning.
Reasoning depth has improved in steps, with each generation able to hold a longer chain of consequence without losing the thread. Tool use reliability has improved more smoothly, with each release reducing the rate at which the model picks the wrong tool or malforms an argument. Long-context recall has improved unevenly, with some generations unlocking new horizons and others spending their gains on retrieval quality inside the existing window. Code generation has improved fastest of all, partly because the training signal is so direct.
If you treat these as one curve, you make planning errors. You delay shipping a feature because you are waiting for reasoning to get better, when the only thing actually holding you back is tool reliability, which is already fine. Or you assume long-context recall has caught up to context length, and you stop chunking, and you find out the hard way that holding the window and using the window are different problems.
The first move when you read any capability claim is to ask which dimension it is on. Then ask what the curve looks like on the dimension you actually care about for the thing you are building.
What "writes itself shorter" looks like
A workflow I built in 2025 had a planner, a coder, a reviewer, and a verifier, all wired into a small graph. Each one was a separate Claude call with its own prompt, its own context, and its own failure mode. The planner produced a plan. The coder executed it. The reviewer caught the bugs the coder made. The verifier confirmed the tests passed. It worked. It was also a lot of glue.
A few model releases later, most of that graph collapsed into a single agent loop with a single prompt and a couple of hooks. The plan-then-execute pattern still exists, but it lives inside one session instead of across four. The reviewer is mostly redundant because the coder catches its own mistakes during the loop. The verifier became a hook that runs tests automatically after each change.
The shape of the code got shorter, not longer. That is what I mean by writing code that ages well. The structure I built was the right structure for the model I had, but the model got better at the same things the structure was compensating for, and the structure became dead weight.
The teams that struggle are the ones that keep the structure anyway. They have a multi-agent system because they had one, and the cost of taking it apart feels higher than the cost of running it. So they pay tokens forever for a problem that no longer exists.
What "only works once it improves" looks like
The other failure mode is the opposite. You see a demo of the next model doing something the current one cannot, and you write your product around the capability before the production model has it.
I have seen this with autonomous coding sessions. A research blog post shows a model running for two hours without going off the rails. A team gets excited and writes an agent loop that assumes the same level of autonomy. They ship. The production model is six months behind the research demo on that dimension. The agent drifts. The team has to backfill the supervision they should have built in from the start.
The pattern is the same in any direction the curve bends. Vision quality, mathematical reasoning, tool composition across many steps. There is always a version of the capability that exists somewhere, and a version of it that is actually shippable. The gap matters.
The discipline is to know which side of the curve you are coding for. If you are building a research prototype, you can sit on the steep part. If you are building production, you live where the curve is gentle and well-established.
Capability versus deployability
There is a related distinction that the talk's abstract gestures at without naming. A capability that exists in the model is not the same as a capability you can put behind a customer-facing endpoint.
The model can do the thing. The system around the model has to be reliable, observable, recoverable, cheap, and fast enough to meet the SLA. Those are not model problems. They are engineering problems, and they get harder as the model gets more capable, because the surface area of what the model can attempt grows.
Production-readiness is not on the capability curve. It is its own curve, and it lags. A useful exercise is to draw both curves on the same axes and notice the gap. The model curve sets the upper bound of what you could build. The deployability curve sets the floor of what you can actually ship.
Most teams I work with are constrained by the second curve, not the first. They are not waiting for a better model. They are waiting for the tools, evaluators, and operational patterns around the model to catch up.
The planning posture
Here is the planning posture I have settled on for the work I do.
Assume the model you are writing for today is the worst model you will ever ship on. Not the best. The worst. That assumption changes which code you write and which code you avoid.
You stop investing in scaffolding that exists to patch model weaknesses, because the patches will become liabilities. You invest in scaffolding that controls blast radius, because you will always need that. You invest in evaluators, because they tell you when the model gets better at your specific task. You invest in observability, because you need to know where the bottleneck has moved.
You write your prompts as if a future version of the model will read them. That sounds vague, but it is concrete in practice. It means writing intent clearly instead of stuffing the prompt with examples that compensate for the model not understanding the intent. The examples will become redundant. The intent will not.
You also build in places where the next model can do more. If the structure of your system assumes that every step needs human approval, you cannot easily relax that assumption later. If the structure of your system separates "the agent ran" from "the agent's work was accepted," you can dial the approval threshold as confidence grows.
What to do this quarter
Two exercises.
First, look at your current system and write down three pieces of scaffolding you would not build today. Long-context chunking that the window has outgrown. Multi-agent splits that one agent could handle now. Prompt templates that fight the model instead of guiding it. Each item is a candidate for deletion.
Second, write down one thing you have been delaying because "the model is not there yet." Then ask whether the model actually is the bottleneck, or whether you have been waiting for a deployability problem to solve itself. The deployability problem will not solve itself. You have to build it.
The capability curve does not give you answers. It gives you a planning input. If you read your roadmap against the curve every quarter, you stop being surprised by the changes the curve forces, and you start using it.
That is the shift. The curve is not a chart. It is a calendar.
Marco Kotrotsos, specializing in practical AI implementation for organizations ready to close the gap between AI hype and AI value. With 30 years of IT experience now focused purely on AI deployment, he works hands-on with companies to turn AI potential into measurable business outcomes.
This article is published in Autocomplete, a Medium publication about real-world AI for practitioners and decision-makers.
My free Substack newsletter, also called Autocomplete, can be found here: https://acdigest.substack.com.
Source talk: The Capability Curve at Code with Claude London 2026. https://youtu.be/DNRddIEoH3c