What you need to know
- A harness, not a model, is on top. EPAM's AI/Run developer agent leads SWE-bench Verified at roughly 76.8% as of mid-June 2026, ahead of Anthropic's roughly 73.2%, per the leaderboard tracked by Epoch AI.
- AI/Run is built on frontier base models, not a new one. The gains come from agent engineering — planning, repo-aware retrieval, tool use and iterative test-run-fix loops.
- SWE-bench Verified is narrow. It is a 500-task, human-validated subset measuring issue resolution on real Python GitHub repositories, where the agent's patch must pass the repo's own tests. It is not general coding ability.
- This is an ownable skill. Indian and UK builders cannot train a frontier model in a garage, but they can absolutely engineer a strong harness — and that is increasingly where the differentiation lives.
Treat the base model as a swappable component. The teams winning on SWE-bench Verified design the loop first — retrieval, planning, test execution, repair — then drop the best available model into it. If your agent's quality collapses when you change the underlying model, the value was in the harness all along, and that is good news: you can keep improving it without waiting for the next release.
What actually happened on the leaderboard
SWE-bench Verified has quietly become the benchmark that engineering teams care about, because it is the one that looks most like real work. Each task is a genuine GitHub issue from a real open-source Python project. The agent is given the repository and the issue, and it must produce a patch that makes the project's own test suite pass. There is no partial credit for a plausible-looking diff. Either the tests go green or they do not.
As of mid-June 2026, the top of that leaderboard is held not by a frontier lab's flagship model but by a software services firm's agent. EPAM's AI/Run developer agent sits at roughly 76.8%, ahead of Anthropic's own entry at roughly 73.2%, according to the SWE-bench Verified tracker maintained by Epoch AI. Leaderboards move week to week, so treat those figures as a snapshot rather than a settled ranking — but the shape of the result is the story.
The key fact to internalise is what AI/Run is. It is not a new base model. It is a harness — a scaffold of planning, retrieval, tool use and verification — that EPAM has built on top of existing frontier models. EPAM describes it as a proprietary developer agent, not an open-source release, so you cannot simply clone it. What you can do is learn from the category of engineering it represents.
Why the harness now beats the model
For two years the implicit assumption in coding-agent benchmarks was that the score tracked the base model. A better model meant a higher number. That assumption is breaking. When a services firm's scaffold can edge ahead of the model maker's own entry, it tells you the marginal point on SWE-bench Verified is being earned in the engineering around the model, not inside it.
Consider what a strong harness actually does on an issue-resolution task. It reads the issue, then retrieves the handful of files in a large repository that are relevant — a non-trivial problem when the codebase is hundreds of thousands of lines. It plans an approach rather than diving straight into edits. It runs the repository's tests, reads the failures, and repairs its own patch in a loop. It keeps a working memory of what it has tried so it does not thrash. None of that is the base model's job. All of it is engineering.
The factors that move the number
It helps to separate the two layers explicitly. The table below contrasts what the base model contributes with what the harness contributes — and it is the right-hand column that teams can own and iterate on.
| Capability | Comes from the base model | Comes from the harness (ownable) |
|---|---|---|
| Code generation quality | Yes — raw reasoning and synthesis | Partly — via better prompts and context |
| Finding the right files in a large repo | No | Yes — retrieval and ranking design |
| Planning before editing | Partly | Yes — scaffolded multi-step planning |
| Running tests and reading failures | No | Yes — tool wiring and test-loop design |
| Repairing a failed patch | Partly | Yes — iterative repair loop and stop conditions |
| Not repeating dead-end attempts | No | Yes — working memory and trajectory design |
Read down the right-hand column and you have a job description. Most of what separates a 50% agent from a 76% agent on this benchmark is engineering that sits outside the model. That is the part a small team in Bangalore or a two-person consultancy in Manchester can practise, measure and sell — without a single GPU spent on pre-training.
What this means for builders in India and the UK
The reflex when a new state-of-the-art lands is to wonder which lab to bet on. That is the wrong question this time. The right question is whether you can build the loop. Frontier base models are a commodity you rent by the token from a handful of providers. Harness engineering is a craft you can compound over months, and it is portable across whichever model is cheapest or best this quarter.
For a Bangalore product team shipping an internal developer assistant, this changes the roadmap. Rather than waiting for the next model release to lift quality, you invest in retrieval over your own monorepo, wire your CI tests into the agent's loop, and gate merges on green tests. For a London fintech building a code-review agent under regulatory scrutiny, the verifiable test loop is not just a quality lever — it is an audit trail, because every accepted change carries the evidence that the suite passed.
SWE-bench Verified is a strong proxy, not a guarantee. It measures issue resolution on Python repositories where good tests already exist. It says nothing about front-end work, system design, security review, or code quality beyond "the tests pass". An agent can produce a patch that turns the suite green while quietly degrading readability or introducing a subtle regression the tests do not cover. Do not read a leaderboard position as a promise about your codebase. If you want to understand what the headline number does and does not include, our explainer on how to read the SWE-bench leaderboard walks through the caveats.
How to build a harness that earns its keep
You do not need EPAM's resources to apply the same principles. A test-driven agent loop is the highest-leverage thing most teams are not yet doing, and the architecture is not exotic.
- Make retrieval repo-aware. Do not paste the whole repository into context. Index it, and at task time retrieve the files most likely to matter for the issue. Rank them. The agent's first job is finding where to look.
- Force a plan before edits. Have the agent state the change it intends to make and the tests it expects to affect, before it writes a single line. Plans catch wrong turns early.
- Run the real tests in the loop. Wire the repository's own test command as a tool. After every patch, run it, capture the failures, and feed them back. This single loop is the largest source of gains.
- Gate on green, with a stop condition. Accept a patch only when the relevant tests pass, and cap the number of repair iterations so a stuck agent does not burn tokens forever.
- Keep a working memory. Track what has been tried so the agent does not re-attempt the same failed approach. This is cheap to build and pays back immediately.
The same discipline applies to how you evaluate the agent. A pass/fail score at the end hides where the loop went wrong. You want to see the trajectory — which file it retrieved, what it planned, which test failed, how it repaired. Our guide to evaluating agents by trajectory, tool call and outcome is the companion piece to this loop, because you cannot improve a harness you cannot inspect.
Every article here is written by a Verified Builder. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →The benchmark caveat, in one place
It is worth being precise about what the number measures, because the gap between benchmark variants is where a lot of confusion lives. SWE-bench Verified is the 500-task, human-validated subset — every task was checked by a human to confirm it is well-specified and solvable. That makes it cleaner than the full SWE-bench, but also narrower. There are harder and broader variants, and the spread between them tells you how much headroom remains; we cover that in our look at the gap between SWE-bench Verified and the Pro tier.
None of this diminishes the AI/Run result. It reframes it. A 76.8% on Verified is a serious engineering achievement on a meaningful task. It is just not a claim about every kind of coding, and the people who will benefit most from it are the ones who treat it as a recipe to reverse-engineer rather than a scoreboard to admire.
The bottom line
The state-of-the-art in coding agents has, for now, been set by a harness rather than a model. That is a structural opening for builders who do not run frontier labs. The base model is a rented commodity; the loop around it is yours to engineer, measure and improve. Invest in retrieval, planning, test-driven repair and trajectory-level evaluation, and you are building the exact capability that just topped the leaderboard — on infrastructure you already have.
Primary sources: the SWE-bench Verified tracker at Epoch AI and EPAM's own announcement at epam.com.