# Compare two coding agents' attempts at the same task and pick one

> Score two AI coding agents' solutions to the same task on a weighted rubric, pick one with reasons, and list what to cherry-pick from the loser.

- **Author:** [Erik Lindqvist (@erik_lindqvist)](https://promptabide.com/erik_lindqvist)
- **Tested on:** Claude · Opus 5.5
- **You fill in:** `task`, `attempt_a`, `attempt_b`, `priorities`
- **Published:** 2026-08-30
- **Updated:** 2026-09-24
- **Tags:** `ai-agents`, `code-review`, `coding`, `decision-making`
- **Keywords:** compare claude code and codex output, best of n coding agent comparison, evaluate ai generated code quality, which ai coding solution is better, rubric for judging ai code
- **Views:** 191
- **Likes:** 20

**Best for:** Developers who run the same task through two agents or two attempts (best-of-n) and need a fair, fast way to choose.

## Prompt

```
I ran the same task through two coding agents. Help me pick which result to keep.

Task: {{task}}

Attempt A:
{{attempt_a}}

Attempt B:
{{attempt_b}}

What matters in this codebase: {{priorities}}

1. Before scoring, trace each attempt against every requirement in the task, including boundary inputs. List where each one fails, with the input that breaks it.
2. Score each attempt from 0 to 10 on: correctness (40%), test quality (25%), footprint (dependencies, lines, files touched; 20%), readability (15%). Adjust the weights if my priorities call for it, and say how. Show the weighted totals.
3. Pick one. Say what would have to be true for the other to be the better choice.
4. List exactly what to cherry-pick from the losing attempt, if anything.
5. Write the follow-up instruction to send to the winning agent, to fix its remaining issues.

Judge the code, not which agent wrote it.
```

## Variables

- `{{task}}` — The task both attempts were given (e.g. Add a slugify(title) util: lowercase, ASCII only, hyphens, max 60 chars, no trailing hyphen)
- `{{attempt_a}}` — The first attempt: diff or code plus its tests (e.g. slugify.ts using normalize() and regexes, 2 tests)
- `{{attempt_b}}` — The second attempt: diff or code plus its tests (e.g. slugify.ts using the slugify npm package, 5 tests)
- `{{priorities}}` — What matters most in this codebase (e.g. Correctness first; we avoid new dependencies for small utils)

## Example input

````
task: Add a slugify(title) util for blog post URLs: lowercase, ASCII only, words joined by hyphens, max 60 characters, no leading or trailing hyphen.
priorities: Correctness first. We avoid new dependencies for small utilities unless there's a clear reason.
attempt_a:
```ts
export function slugify(title: string): string {
  return title
    .toLowerCase()
    .normalize("NFKD")
    .replace(/[̀-ͯ]/g, "")
    .replace(/[^a-z0-9]+/g, "-")
    .replace(/^-+|-+$/g, "")
    .slice(0, 60)
}
// tests: "Hello World" -> "hello-world"; "Café crème" -> "cafe-creme"
```
attempt_b:
```ts
import slugifyLib from "slugify" // new dependency added to package.json
export function slugify(title: string): string {
  const s = slugifyLib(title, { lower: true, strict: true })
  return s.length > 60 ? s.slice(0, 60).replace(/-+$/, "") : s
}
// tests: basic words; accents; punctuation stripped; exactly 60 chars; 61 chars cut at a hyphen with no trailing hyphen
```
````

## Output

*Produced by Claude · Opus 5.5.*

```
**1. Requirement trace**

*Attempt A*
- **Trailing hyphen after truncation: fails.** Hyphens are trimmed *before* `.slice(0, 60)`, so a title whose 60th character is a hyphen ends in `-`. For example, 59 letters followed by " post" gives 59 letters and a trailing hyphen.
- **Characters with no decomposition:** `"Straße"` becomes `"stra-e"`, because NFKD doesn't decompose `ß`, so the character is replaced with a hyphen. That's ugly but technically meets the spec.
- Lowercase, ASCII only, hyphens, and the leading hyphen rule: pass.

*Attempt B*
- Truncation: cuts, then strips trailing hyphens. Pass, and it's tested.
- The library transliterates many characters, including `ß` to `ss`.
- Lowercase, ASCII, hyphens: pass.

*Both*
A title entirely in a non-Latin script (for example Hindi) returns `""`. The task doesn't define this case, and neither attempt handles it.

**2. Scores**
Given your priorities, I've moved 5% of the weight from readability to footprint (correctness 40, tests 25, footprint 25, readability 10).

| | Correctness | Tests | Footprint | Readability | **Total** |
|---|---|---|---|---|---|
| A | 6 | 3 | 10 | 9 | **6.55** |
| B | 9 | 8 | 5 | 9 | **7.75** |

**3. Pick: B, narrowly on points, but A with fixes is better for you.**
On the rubric B wins, because its correctness and tests are stronger. But A's failures are a one-line fix plus tests, while B's cost is a permanent dependency for about six lines of logic, which your priorities specifically discourage. **Keep A, fix it, and port B's tests.** B is the better choice if you expect titles in many European languages, where its transliteration table adds real value.

**4. Cherry-pick from B**
- The 60-character and 61-character boundary tests, and the punctuation test.
- Its approach of truncating first, then stripping hyphens.

**5. Follow-up for Attempt A's agent**
> In `slugify`, move `.slice(0, 60)` before the leading/trailing hyphen trim so truncation can't leave a trailing hyphen. Add tests for: exactly 60 characters; 61 characters where the cut lands on a hyphen; `"Straße"` (document the current `"stra-e"` result); a title with no Latin characters (returns `""`, add a comment saying callers must handle it). Don't add dependencies. Paste the test output.
```

## Why it works

**Tracing requirements before scoring** stops the rubric from rewarding whichever answer looks tidier. It's what found A's truncation bug, which A's own tests missed. **Explicit weights with visible totals** make the judgement auditable, and letting **your priorities adjust the weights** means a no-dependencies culture is actually counted. Asking **what would have to be true for the other to win** keeps the verdict honest when the call is close. The **ready-to-send follow-up** turns the comparison into the next step, not just a verdict.

## When not to use it

It's not worth it for trivial tasks where both attempts pass your tests. Pick the smaller diff and move on. The trace is the model's reasoning, not execution, so run both test suites before deciding. For large features, comparing whole diffs in chat gets unreliable. Compare the key files, or have each agent's tests run against the other's code.

---

Canonical HTML: https://promptabide.com/bides/compare-two-coding-agent-attempts
Agent guide: https://promptabide.com/llms.txt · https://promptabide.com/agent-instructions.md
Sitemap: https://promptabide.com/sitemap.xml