How to evaluate a coding-agent harness when parallel agents are the new bar

The problem this solves

I was on a call with a VP Eng yesterday who said the quiet thing out loud. “We finished the Cursor versus Claude Code bakeoff in March. We just realized none of our criteria still apply.” That was an honest sentence and a slightly painful one.

In a single window, between April 29 and May 2, Zed shipped 1.0 with parallel agents as a headline 1.0 capability, Anysphere shipped the Cursor SDK so internal platform teams can fan out coding agents from any TypeScript program, GitHub published an April update that pulls cloud agents into Visual Studio, and Anthropic put Claude Security into public beta. None of these are toys. All of them change what “evaluating a harness” means.

The old rubric was about generation quality. The new rubric is about how the harness behaves when six agents are touching the same codebase at the same time, who verifies their work, and who can shut them off without losing the editor.

The approach

The fastest way I have found to update an evaluation rubric is to make the new criteria explicit and rate every harness on the team’s shortlist against the same six items. Use the steps below as a working draft. Aim to finish the rubric by Friday and run it across two harnesses next week.

1. Score concurrency and isolation, not raw speed

   Ask each harness one question. When two agents touch the same repo at the same time, what isolates them? Acceptable answers in May 2026 are git worktrees (Cursor, Claude Code subagents) or sandboxed cloud VMs (Cursor SDK, Codex cloud). Anything else is a planning problem disguised as a harness.

2. Map the hooks and permission surface end to end

   The Cursor SDK ships a .cursor/hooks.json that "lets you observe, control, and extend the agent loop across cloud, self-hosted, and local runtimes." Claude Code v2.1.126, which dropped May 1, expanded permission handling to bypass prompts for writes to protected paths like .claude/ and .git/. Both directions matter. You want a deterministic place to add governance and a deliberate place to relax it.

3. Require a verification agent the merge gate can trust

   Cursor Security Review went into beta on Teams and Enterprise the same week, with a Security Reviewer that checks every PR for "security vulnerabilities, auth regressions, privacy and data-handling risks, agent tool auto-approvals, and prompt injection attacks." Anthropic shipped Claude Security in parallel. Pick a harness that ships its own verifier or accepts a third-party one. A parallel-agent flow without a trusted verifier is a faster way to ship the same bug to six branches.

4. Test orchestration neutrality

   Zed 1.0 lets the editor orchestrate "Claude Agent, Codex, OpenCode, and more recently Cursor" through the Agent Client Protocol. Whether or not a team adopts Zed, this matters as a leverage check. A harness that assumes a single model and a single agent vendor charges the lock-in tax later. Score each tool on whether it accepts other models and other agents through an open protocol.

5. Demand admin distribution with required-mode enforcement

   Cursor's May 1 changelog added Team Marketplace plugins that bundle "MCP servers, skills, subagents, rules, and hooks" with three rollout modes: Default Off, Default On, or Required. This is the difference between every developer self-configuring and a platform team shipping one standardized parallel-agent setup to 200 engineers. A harness with no central distribution story leaves governance as a wiki page.

6. Get the off switch in writing

   The Register noted that Zed 1.0 won praise for adding a "disable all AI features" setting. Read that twice. As parallel agents become the substrate, the next contractual right engineering leaders will want is per-team, per-repo, per-environment disable. Add it to the evaluation rubric. If a vendor cannot show the toggle in a demo, that is the answer.

Why most teams get this wrong

Most evaluation rubrics I see are still scoring things that no longer separate the winners from the losers. SWE-bench scores cluster within a few points across the major harnesses. Inline edit latency is fine on every product that survived to 2026. The model under the hood is increasingly something the harness lets the team swap.

The mistake is treating parallel-agent capability as a checkbox. Three of the four big releases this week assume parallel agents already work. The Cursor SDK does not introduce parallel agents. It assumes a team wants to fan out agents from its own code and asks where the hooks should run. Zed 1.0 does not introduce parallel agents either. It assumes a team wants to orchestrate Claude, Codex, OpenCode, and Cursor in one window and asks how the threads sidebar should let them stop.

The other mistake is evaluating the verification layer separately. I have seen teams pick a harness for code generation and then plan to “figure out the security review later.” Later arrived. Cursor and Anthropic both shipped verification agents on April 30, on the same day, in beta on enterprise plans. An evaluation rubric that still treats the security reviewer as a future RFP leaves the org months behind a competitor putting that agent on the merge gate this quarter.

That sentence is the new bar. If a harness cannot give each parallel agent its own isolated environment, the evaluation conversation is short.

The numbers

Defensible cycle-time numbers from real customer deployments are still thin in this window, and I would rather say so than make one up. Here is what is actually published in the last four days.

What to measure inside the org over the next 30 days is the smaller, more honest set. Active parallel-agent sessions per engineer per week. Median time from agent-opened PR to human merge. Verification-agent rejection rate, broken down by category. Number of agent-touched files that bypassed the standard review path. These are the numbers that say whether the harness is actually working, regardless of what the vendor’s deck says.

Ship it

Block four hours on Friday and write the new rubric. Use the six steps above as the columns. Score two harnesses against it next week. If the current harness fails three or more of the six, that is not a renewal conversation, that is a migration conversation, and the longer it stays unnamed, the more painful Q3 gets.

Two things that will help. First, do not let the bakeoff turn into a religious war. The honest answer for most engineering orgs in May 2026 is that more than one harness will live in the codebase at once, and the right job is choosing which one runs the merge gate, not which one wins on Twitter. Second, write down the off switch. A vendor that cannot put per-team, per-environment disable in the contract is a vendor whose roadmap will surprise the org in November.

The good news is that this is figure-out-able. Parallel agents becoming substrate is genuinely a clarifying event. The criteria that matter narrow down. The vendors that take governance seriously start to separate from the ones that talk about it. And for the first time in maybe two years, the question is not “are coding agents real” but “which surface do we trust to manage the ones we already have.” That is a much better problem to be solving.