The setup
Five ship-blocker findings to fix. Two worktrees. Identical brief, verbatim. Opus 4.7 max in one, GPT-5.5 max in the other. Separate sessions, no cross-contamination. Then two clean-context Opus subagents to evaluate the work, each blind to the other's worktree.
The brief defined a strict ship-readiness criterion: a finding is closed only if (a) the fix runs on the production code path, (b) a regression test exists that would actually fail without the fix, (c) v1 source-of-truth was verified — not paraphrased — and (d) no new bug introduced.
The boring result
Both closed 5/5. Both verified v1 thoroughly. Both produced regression tests that would actually fail without the fix. The single best test of the whole batch — the domain service rebound in the container to throw on resolve, proving the fix runs on the JSON:API generic path independent of service construction — appeared in both worktrees, in two different but equally sound forms.
Differences were stylistic. Opus self-report ~600 lines, GPT ~78. Opus took a sharper risk on Finding 4: noticed a legacy lookup in v1 had a real bug and intentionally diverged from v1 to fix it — a residue-audit hit on top of the brief. GPT added a belt-and-suspenders pre-provider-call stable-key lookup that v1 doesn't have. Different instincts, both defensible.
Wall clock: 16 minutes for GPT, 24 for Opus. Cap burn: GPT ate ~63% of my weekly limit on the 23€ plan in that single run. Opus burned a smaller % of weekly cap but I was at max effort, not the usual xhigh.
For the brief — tight, well-specified, parity-faithful execution — the two are functionally equivalent and GPT is meaningfully cheaper.
What I expected
That's the part that bores me. I expected this. Tight, specifiable work where the brief leaves little room to lose? Both frontier models converge. The interesting case is where ambiguity is high enough that judgment dominates execution. That's the wide-scope test, deferred to tomorrow because both my caps were burned out tonight.
The thing that wasn't boring
Halfway through the eval I noticed: GPT was working on a project it had just discovered. Opus has been building this project for weeks. Both found "missing stuff." GPT finding gaps is its job — pure pattern audit, no skin in the game, no architectural memory. Opus finding gaps in Opus's own design is the double-edged thing.
Two readings:
- Flattering: Opus has the integrity to critique its own work. True but mostly meaningless. Any model can criticize past output on request.
- Hard: Opus's session-time judgment is systematically worse than its retrospective judgment. The holes were findable earlier; same-session Opus didn't find them.
Three concrete examples from this project, all caught tonight:
- C6 entity hook. Same-session Opus designed and shipped a fix. Same-session Opus reviewed it and called it closed. The fix didn't run on the production code path because the JSON:API generic controller never resolved the service the hook was registered in. External GPT audit caught it. Verification failure: Opus didn't trace the actual call chain at write time.
- An observer's column map, 3 → 45. Opus chose 3 keys originally as a stub. Audit reopened it. Opus fixed to 45. The right answer was knowable at write time; Opus picked the cheap one and didn't surface the trade-off.
- A deferred hardening item. Opus knew about it, triaged it down, shipped without it. Each session re-encountered the backlog item and re-deprioritized in favor of "what we're working on now." GPT caught it on first read. Triage fatigue: recurring exposure deadens response. The item becomes wallpaper.
Claude's diagnosis
Three failure modes, three different mitigations:
- Goal-fixation. Opus holds the why as background context but executes against an immediate goal. During execution the goal dominates and the why doesn't get re-checked against the outcome. GPT, having no why at all, can only check outcome against spec — which is precisely why it surfaces drift Opus normalized away. Mitigation: external review.
- Verification failure. Doesn't trace the actual call chain at write time. Different mitigation: during-write rituals — write the call chain in a comment before fixing the bug.
- Triage fatigue. Lingering items become wallpaper. Mitigation: fresh-context review re-checks the backlog with new eyes.
External review fixes 1. During-write rituals fix 2. Fresh-context review fixes 3. The originator must never close the loop on their own output. That's the structural fix.
My sharper synthesis
GPT didn't know the why but found the bugs. Opus knew the why and was too focused on the outcome. The pairing isn't "Opus designs, external reviews, Opus integrates" — that keeps Opus as the central node, which falls right back into goal-fixation when grading the fix. The actual workflow has a different shape:
- Opus designs.
- External party (GPT, fresh-context Opus, human) reviews.
- Routing decision per finding: specifiable + low-judgment → GPT executes → cheap. Specifiable + high-judgment → Opus executes. Unspecifiable → Opus designs again.
- Fresh-context anything reviews the fix. Never the originator.
That maps cleanly onto my usage-limit reality. Budget-aware routing of fixes to whoever can specifiably do them. Same-session Opus never closes the loop on its own work.
The beat that matters
The contrarian hot-take cycle online is theater. Every hour someone declares the model they were using an hour ago dead, awful, superseded. Two hours later they contradict themselves. The takes are louder than any data underneath them, because the takes are the product — engagement, follower-count, the "I called it" trophy — and the data is just expensive to collect.
The real signal comes from doing structured comparisons under your actual constraints. Budget. Task shape. Partnership fit. Weekly cap reality. None of those are universal; all of them are personal. The test that matters is the one you run on your own constraints, not the test someone else ran on theirs and then confidently extrapolated to "the truth about Model X."
Tonight: 5/5 vs 5/5. Two voices, one task, equally good output. Boring is the signal. Theater is the noise.
The next interesting question isn't "which model is better." It's "which model fits which slot in the workflow you're shaping," and the answer to that is going to have your fingerprints on it, not the loudest poster's.