When Sasha Rush posted a talk titled Training Composer, the headline was easy to miss. It was not simply that Cursor had built another coding model. The more important signal was that Cursor was showing the shape of a new moat in AI software: not bigger models, not cleaner demos, not another leaderboard jump, but a training loop built out of real developer work.
The coding-agent race is entering a more serious phase. The old question was: Which model writes the best code? The new question is: Which company can turn actual engineering workflows into a compounding training advantage?
That is why Composer 2 matters. Cursor says the model was trained through continued pretraining followed by reinforcement learning in realistic Cursor-style environments. Its reported results — including 73.7% on SWE-bench Multilingual and 61.7% on Terminal-Bench — are notable. But the benchmark scores are not the real story. The real story is the method: Cursor is trying to train agents inside the kind of messy, multi-step, tool-using workflows where professional software actually gets made.
That sounds obvious. It is not.
For years, AI coding progress was measured in sanitized tasks: complete this function, solve this issue, patch this repository, pass this benchmark. Those tasks were useful, but they flattened the work. Real engineering is not a single prompt and a clean answer. It is wandering through a codebase, misunderstanding something, opening the wrong file, running a test, breaking a dependency, backing out, noticing a naming convention, reading an error message, and finally making a small change that works because it fits the system around it.
That is the environment a useful coding agent must learn. Not code as text. Code as a lived workflow.
This is the first pillar of the new moat: real-world reinforcement learning.
Reinforcement learning for coding agents is not just about rewarding a model when tests pass. The hard part is teaching judgment across long trajectories. Which file should the agent inspect first? When should it stop searching and start editing? When should it run tests? When should it revert? When is a green test suite misleading? When is the smallest patch better than the clever refactor?
These are not autocomplete problems. They are software-engineering behavior problems.
Cursor’s advantage, if it can sustain it, is that its product sits directly inside that behavior. Every accepted diff, rejected suggestion, failed terminal run, rewritten patch, and abandoned agent trajectory is a potential signal. The IDE becomes more than a workspace. It becomes a data engine.
That is why OpenAI, Anthropic, GitHub, and Google are all moving toward the same terrain. The prize is not merely generating code. The prize is owning the loop where work is assigned, attempted, tested, reviewed, and merged.
The second pillar is more counterintuitive: messy data.
The AI industry has spent years worshiping clean data. Filter the web. Remove the junk. Curate the corpus. Prefer quality over quantity. That instinct is not wrong, especially when dealing with unsafe, duplicated, or legally risky material. But recent research debates, including Tatsunori Hashimoto’s thread on the “bitter lesson” for data filtering, point to a more complicated reality: at sufficient scale, large models may tolerate nominally low-quality data better than expected, and aggressive filtering can sometimes remove useful signal.
For coding agents, this matters because the best data may not look clean at all.
A failed edit is messy. A bad first guess is messy. A terminal log full of errors is messy. A developer rejecting an agent’s patch and rewriting three lines is messy. But that mess may contain the most valuable information in the system: what did not work, why it failed, and what a human considered acceptable instead.
The future training set for coding agents is not just pristine code. It is the residue of engineering work: tool calls, retries, tests, diffs, review comments, rollbacks, and outcomes.
This is where the “clean code corpus” moat starts to look weaker. Public code is abundant. Static code is scrapeable. But outcome-labeled agent trajectories inside real products are harder to copy. The useful signal is not merely what code exists. It is how software gets changed.
The third pillar is the most controversial: product-native benchmarks.
CursorBench and similar internal evaluations reflect a growing frustration with public benchmarks. SWE-bench, Terminal-Bench, and related tests have pushed the field forward, but the richer the coding-agent market becomes, the less any single public benchmark can capture. Real users ask vague questions. Real repositories have hidden conventions. Real tasks involve partial context, unclear intent, flaky tests, missing documentation, and judgment calls.
So companies are building benchmarks from their own workflows. That makes sense. It may even be necessary. A coding agent should be judged by whether it succeeds in the environment where it is deployed.
But this is also dangerous.
Product-native benchmarks can become self-serving. A model can be tuned to a company’s own harness, tools, permissions, and task style. A benchmark built from real usage may be more realistic, but it is also harder for outsiders to audit. The very thing that makes it valuable — its proximity to actual product behavior — makes it less comparable across companies.
That is the tension at the center of the new AI coding race. The best evaluations may be private. The most meaningful data may be proprietary. The strongest training signals may come from closed product loops. Progress may become more real and less legible at the same time.
For investors and technical leaders, this changes what should be measured.
Benchmark scores still matter, but less than before. The sharper questions are operational: How many agent-generated changes are accepted without rewrite? How often do they introduce regressions? How much senior review time do they save or consume? What is the cost per merged change? Does the agent improve on private repositories, or only on public tasks? Can the system explain why it changed what it changed?
The companies that answer those questions well will own the next phase of AI coding.
Cursor is early to this framing, and that is why the Composer work matters. But the moat is not guaranteed. OpenAI can enter the IDE. Anthropic can win developer trust with Claude Code. GitHub can own pull requests and enterprise workflows. Google can turn managed agents into cloud infrastructure. The loop Cursor wants to own is valuable precisely because everyone else can see it too.
The new AI coding moat is not a model. It is not a benchmark. It is not even an editor.
It is the loop: users create work, work creates trajectories, trajectories train agents, agents reshape the product, and the product captures more work.
That loop is the new frontier. And in software, as in every industrial revolution before it, the company that owns the feedback loop eventually owns the factory.
Sources: Cursor — Composer 2 Technical Report https://arxiv.org/html/2603.24477v2 Cursor — Composer 2 Product/Model Announcement https://cursor.com/blog/composer-2 Mohri, Duchi, Hashimoto — A Bitter Lesson for Data Filtering https://arxiv.org/html/2605.19407v1