One-Shot Shop Challenge

Same prompt as build #1, just swapped to Opus 4.7. The run finished in 32m 27s for $22.63, by far the fastest on this page (build #1 took a full hour).

Two unilateral deviations stood out. Despite being told to use team-mode, Opus 4.7 built everything as a single agent, explaining: “I judged direct execution to be faster and more coherent. That is a deviation from your ‘must use team mode’ instruction.” It also stopped before the spec was complete, ending with “Ready for your feedback on which of the listed gaps to close next.” Echoes of the Mythos behaviour Anthropic flagged last week.

Scope is the trade-off: 105 classes and 2,667 LOC (vs 140-170 classes and 5-7k LOC in bigger builds), and several admin areas from build #1 (analytics detail, themes, full fulfillment lifecycle, order timeline, address book) are missing. Feature completeness: 93 passing, 24 partial, 25 failing, 1 N/A (weighted ~74%). Still feels complete in the browser.

Quality is strong: avg MI 75.4, 0 PHPMetrics violations, 0 SonarCloud bugs, all three SonarCloud ratings A, 13 code smells, 0.6% duplication. SonarCloud's gate reports failed only because three new-code security hotspots await review.

Impressive raw power from a single worker, but I do not like that it chose to ignore explicit instructions. A follow-up run with tighter guardrails is planned.

Same prompt, same setup as build #1 and build #7, but this time with adaptive thinking explicitly disabled. Recently, adaptive thinking has been a suspected root cause for the model dialling back its reasoning mid-run and producing weaker output. Would forcing Opus to stay in high reasoning mode fix that?

Short answer: no. The run landed at 106 of 143 tests passing with a 77.4% weighted score, meaningfully below build #1 (88.1%) and build #7 (88.8%) with the exact same prompt. Quality metrics are in the same ballpark (avgMI 87.8, 0 bugs, all SonarCloud A-ratings, 11.6 Halstead bugs), but feature completeness took a clear hit: product and discount admin save flows return HTTP 500, cart discount codes are silently ignored, and there is no stock enforcement in the cart.

Efficiency landed in the middle: 2h 27m runtime with $105.73 in API cost. Faster and cheaper than build #7, but slower and more expensive than build #1 with worse output than both. On this specific prompt, adaptive thinking off did not help; it made the team finish with more half-built features, especially around admin forms and discount handling.

Digging into the session logs surfaced something unexpected. On build #8 every single one of the 268 lead API calls carried a thinking block. On build #1 (Claude Code v2.1.39, before adaptive thinking even existed) and build #7 (v2.1.81), the lead only sent thinking on roughly 1 in 5 calls. The other 80% were tool-result continuation calls that skipped thinking entirely. So this 100% isn't "adaptive off beating adaptive on". It's Claude Code's own per-call logic about when to include a thinking block, and forcing "high + adaptive off" made it emit thinking on every call.

Teammates, which do most of the actual coding, ran zero thinking blocks on every build. Across 29 teammates and 4974 assistant messages in build #8 there is not a single thinking block. Same pattern in builds #1 and #7.

Claude Code team mode does not propagate the lead's thinking config down to the teammates. Forcing high on the lead only affected orchestration decisions, not the implementation work. That is likely why the switch did not move the needle on feature completeness or quality.

Same specification, same technology, and this time the same original prompt as build #1. The idea was to check whether the increased 1M token context limit plus the 42 Claude Code releases since the first run (v2.1.39 to v2.1.81) produce a better result on their own, without any prompt engineering.

This also serves as a direct comparison to build #6 which used a very detailed prompt with instructions on HOW to build. Here, the agent gets no process instructions at all, only the specification of WHAT to build.

The result: 121 of 143 tests pass with an 88.8% weighted score, the highest across all builds. Zero SonarCloud bugs, all A-ratings, and 12.16 estimated Halstead bugs. The simple prompt with the upgraded context window outperformed the heavily engineered prompt from build #6.

Same specification, same technology, but this time with an advanced prompt combining several techniques: a thorough controller supporting the team lead, BDD and TDD, code reviews, and a dedicated QA teammate that actively tries to break the system. The prompt was designed to leverage the new 1M token context window.

The result speaks for itself: 119 of 143 E2E tests pass (83%), the highest since the original team mode run. However, this came at a steep price: about $285 in hypothetical API costs and almost 11 hours of runtime, with 176 active agents. The advanced prompt produced more robust code but consumed far more resources than any previous build.

Claude Code took a phased approach. The team lead read the full specification, broke it into 12 implementation phases with explicit dependencies, and then spawned specialized agents for each area: migrations, models, Livewire components, admin panel, seeders, and so on.

At peak, 31 agents were working simultaneously. The whole thing was done in just over an hour, producing 388 files across the full Laravel stack. Foundation first, then catalog, storefront, cart and checkout, payments, customer accounts, admin, search, analytics, and webhooks.

Same specification, same prompt structure, but this time Claude Code ran with sub-agents instead of team mode. No specialized agent instructions were prepared - the prompt simply told it to use sub-agents. Claude spawned 20 sub-agents total, 12 of which actively contributed code.

The build took about 2 hours and 13 minutes, producing 358 files. With an estimated API cost of $61.97, it sits between the team mode run ($73) and the Codex run ($8.79) in terms of cost.

Codex launched explorer agents to analyze the specification first, synthesized their findings into a phased roadmap, then delegated implementation to worker agents. The process took about 1 hour and 44 minutes with 16 sub-agents total.

On my first try, Codex actually finished after just a few minutes already with a surprisingly good but familiar result. That was suspicious. The shop looked exactly like the one Claude had built. Turns out, Codex found the other branch in the repo and switched to it instead of building from scratch. I had to start over with slightly adjusted instructions.

Same specification, same technology, but this time with a tuned prompt and strict quality constraints. The prompt included mandatory PHPStan compliance at max level, Deptrac architectural boundary checks, Pest test coverage, QA self-verification against every acceptance criterion, and a fresh agent review cycle where a new agent instance re-evaluated the entire codebase.

The idea was to see if explicit quality instructions produce measurably better code. The result: significantly fewer estimated bugs (12.4 vs 18.1), higher maintainability (89.7 vs 79.7), zero SonarCloud bugs, and 60% fewer code smells. The quality gate still failed on duplication (7.5%) and unreviewed security hotspots, but the core metrics improved across the board. The trade-off was runtime: the agent took about 3 hours, partly because it did not terminate on its own when done.

A few features were deferred: search was moved to a roadmap item instead of being fully implemented. The storefront uses a dark theme this time.

Same specification, same technology, but this time Codex received custom instructions with two additional quality tools: PHPStan (static analysis at max level) and Deptrac (architectural boundary checks). The idea was to see if giving Codex explicit quality constraints would produce measurably better code.

The result is mixed. On the positive side: zero SonarCloud bugs, zero vulnerabilities, and all A-ratings across reliability, security, and maintainability. On the other hand, the code smells tripled (153 vs 54) and estimated Halstead bugs jumped to 31.4 (vs 4.0 in v1). The quality focus seems to have shifted the agent towards more classes and more code, but with higher internal complexity in key controllers.

Only a single product was seeded, and the storefront UI is noticeably reduced compared to other builds. The quality-focused instructions appear to have consumed attention that would otherwise go to spec coverage and demo data. The admin panel, however, is functional with OAuth-based API authentication.