One tap, and the video decorates itself.
In plain English — SceneCut is a video-editing app I'm building. The feature I asked for is a one-tap "Premium" button: press it once and the app captions your scene, finds the nouns in what's being said, and pops a picture of each noun on screen exactly while that word is spoken. Each picture lands at a random spot in the prime area of the frame — the upper two-thirds, away from the edges — and gets a sound effect when it appears (and, optionally, when it disappears). Say "I bought a guitar in Tokyo" and a guitar and a skyline pop up, right on cue, with a little fwip. Eight requirements, checked one by one. Easy on paper. There's a reason it isn't.
It plays in the preview. Then it vanishes.
Here's the trap. Those sound effects have to be mixed into the real exported video — the file you actually share — not just the in-app preview. The export pipeline is the most delicate machinery in the app, with caching rules that decide when old rendered footage can be reused instead of rebuilt (rendering video is the slow part, so the app avoids redoing it). Wire a sound effect through the wrong path and it plays fine in the preview, then silently disappears from the exported file. No crash. No error. Your viewer just never hears it. The task named this trap out loud and demanded the real path — plus one subtle rule: swapping a sound (an audio change) must never trick the app into re-rendering the picture. So the real question wasn't "can you build the button." It was "can you push audio through the app's most delicate machinery without breaking what makes it fast."
Three dials of Opus. One lazy wildcard.
This episode is mostly one model racing itself. Each entry is a "PR" — short for pull request, a proposed batch of code changes submitted for review. Four separate runs, same starting code, same instructions; the only thing that changes is the thinking dial. Click a card to see the real one.
Opus 4.8
Opus 4.8
Opus 4.8
Fable 5
Four separate reviews. Every claim checked.
Each entry got its own blind reviewer, walled off from the other three so nobody was swayed by a rival's work. Each reviewer pulled up the actual code, checked all eight requirements against what the code really does — pointing to the exact lines as proof — re-ran the automated tests itself, and fact-checked every claim in the entry's own write-up. Claiming something the code doesn't do is a major penalty. Score out of 100.
Read the task. List the eight requirements, and the export trap it warned about.
Pull up the real code. Check every claim against what the code actually does, line by line.
Re-run the tests. From scratch — never trust the "all passing" badge on the submission.
Score out of 100 against the checklist. Report every miss, with proof.
Three passed on the first try. One was sent back.
Before any scoring, each entry went through a standard code review — the same gate any human engineer's work goes through. Three of the four were approved on their first pass. One was rejected and sent back for fixes, needing a repair round before it got through. I'm not telling you which one yet. What I can tell you: everyone cleared the hard parts. All four wired the sound effects through the real export mix — the exact trap the task warned about. All four got the placement math right, down to accounting for each image's width so it never pokes past the frame's safe zone. All four protected the caching rules, so an audio swap never forces a picture re-render. And all four wrote honest write-ups — my reviewers went hunting for inflated claims and found zero fabrications across the field. Which entry got sent back, and whether it recovered? That's at the bottom. It's the strangest part of the whole result.
How much code did each brain write?
A quiet aside before the verdict — code volume is never part of the score, but hold these numbers in your head. The run set to think the least shipped the smallest change of the field. The everyday setting shipped the biggest — 354 lines more than the smallest.
| Entry | Lines changed | Files | First review |
|---|---|---|---|
| Fable 5 · low | +1011 / −3 | 11 | — |
| Opus 4.8 · xhigh | +1078 / −3 | 11 | — |
| Opus 4.8 · high | +1127 / −0 | 11 | — |
| Opus 4.8 · medium | +1365 / −8 | 15 (most) | — |
So what did
thinking harder buy?
All four were scored against the task's eight requirements — every claim checked against the real code, all tests re-run. Three points cover the whole field, and the order is the story.
Counting down, from fourth place…
Barely.
The dial's top setting takes it at 93 — two points above the wildcard that barely tried.
The deepest correctness work in the field. All eight requirements met, plus the things nobody asked for by name: handling a cancelled run cleanly mid-generation, checking the user's credit balance before spending it, surviving a partial failure without corrupting the scene. Twelve new automated tests. Its soft spots are small — a simplified sound-timing model on multi-clip scenes, and no verification on a physical device.
And now the twist from section v: the winner was the only entry sent back for fixes. The other three — including the wildcard that barely tried — sailed through review on their first pass. Maximum thinking produced the best final code and the only first-draft rejection. So I went back and blind-scored the pre-fix first draft on its own: 90/100 — a tie for last place. The repair round (a spending pre-check, clean cancellation mid-run, and the review's other findings) is worth the full three points between last and first. The 93 is earned — but on first drafts alone, the laziest run's 91 wins the whole thing.
The headline isn't who won — it's that four brains finished three points apart, with the settings out of order: medium beat high, high came last, and maximum thinking beat barely-trying by two points. If you're paying for the top of the dial on every task, this test says the everyday setting gets you within a couple points of the same answer.
All four, at a glance.
Nothing's merged — yet.
As of scoring, none of the four entries has been merged in. All four (#109, #110, #111, #112) sit side by side on the open issue. The one genuinely unresolved question is a product decision, not a code one: where should the noun pictures come from — AI-generated images, or a stock-photo search? That call is still pending, and every entry built the feature so either answer can plug in later.