Claude Sonnet 5 and Claude Opus 5 each got the brief as a single prompt. Then Opus 5 got it again, as a Jira epic worked end to end by a team of agents on a software development playbook.
The brief was the classic arcade game Asteroids with a fixed feature list: steering and shooting, waves of rocks, a hyperspace escape button, an explosion when your ship is hit, a saved high score, and sound effects. Claude Sonnet 5 and Claude Opus 5 each got it as a single prompt: one message, one answer, no follow-ups. The third run got the same brief as a Jira epic split into four tickets and handed to a team of AI coding agents.
All three started from the same repository, and you can check that rather than take our word for it. Every arm's source is published, alongside the brief they were given. The three scaffold files they were handed, the data contract and the world constants and the test fixture, are byte-identical across all three arms, while every file they wrote themselves differs.
From there the SideButton portal ran its software development playbook: pre-defined know-how for how a dev team works, from picking up a ticket to releasing a tested result. The playbook gives every agent a role. Engineer agents built the three parts (movement, graphics, sound), a reviewer sent each piece back until it passed, an integrator assembled the game, and a QA agent played it before release. The whole chain ran end to end in Jira and GitHub, the tools teams already use.
The best measure of multi-agent orchestration is how rarely you need to check on it.
The first two games below are a first answer, published as is. The third is what you get when you orchestrate AI agents: reviewed, tested, released.
Same brief: what got built, and how well it works.
| Dimension | Sonnet 5 | Opus 5 | Opus 5 + SideButton |
|---|---|---|---|
| Design | simple | advanced | advanced |
| Hyperspace | ✓ | ✕ lost | ✓ |
| Collision animation | ✕ sound only | ✕ sound only | ✓ wreck + impulse |
| UX | canvas text · high score persists | canvas text · no high score kept | end card + best score + toast |
| Sound | basic | fuller | richest |
| Lines of code | 1,080 | 1,425 | 2,266 |
| Lines of tests | none shipped | none shipped | 2,278 |
| Lines of docs | 341 in-code | 487 in-code | 793 in-code + README |
| Code quality | ★★★★★ clean, untested | ★★★★★★ clean, untested | ★★★★★ review-hardened |
| Render sharpness | 800×600 fixed | high-DPI aware | high-DPI aware |
| Draw calls per frame | 7 · sparse scene | 29 · multi-pass glow | 13 · efficient glow |
| FPS · frame cost | 60 · 0.11 ms | 60 · 0.13 ms | 60 · 0.12 ms |
| Overall | ★★★★★ 5.7 / 10 | ★★★★★★ 4.7 / 10 | ★★★★★ 9.8 / 10 |
A stronger AI buys polish, not completeness. Opus 5 built the best-looking one-shot and quietly dropped the most features. The playbook run used the very same Opus 5. The difference is where the work stops: a one-shot stops at the first answer; the playbook stops when every review has passed and the game is tested. The paper trail proves it: a reviewer agent refused the movement code until a bug was fixed, the one-shots came with zero tests, and the team wrote 2,278 lines of them.
Every agent in this test ran on the same free open source MCP server. The difference was never the engine.
You don't need a smarter AI. You need to run it like a team.
