Sonnet 4.5 and Gemini 3 made coding the frontier battleground

Coding is a useful frontier comparison because it leaves evidence. Code runs or does not. The diff is reviewable or it is not. Tests pass or fail.

That does not make coding benchmarks complete. It makes the failure easier to inspect than a charming paragraph.

For Sonnet 4.5 and Gemini 3, the useful questions are operational:

• did the model read surrounding code?
• did it keep the patch small?
• did it run relevant checks?
• did it leave the repository easier to continue?
• did it explain a tradeoff a reviewer could challenge?

Computer-use systems add physical state. A model can click the wrong account, accept the wrong modal, or type into the wrong field. Screenshots, focus, browser state, and timing become part of the evidence.

Receipts should include:

• files read
• commands run
• tests attempted
• generated patches
• failures
• assumptions
• skipped checks and why

The model is only one component. A serious coding setup also needs scoped workspaces, permission boundaries, logs, intermediate state, relevant tests, and a reviewer allowed to reject confident nonsense.

Different surfaces change the job. An IDE exposes diagnostics. A sandbox exposes snapshots and command logs. A browser exposes visual state. A CLI exposes shell history and repository context.

Measure patch acceptance, reviewer corrections, test relevance, recovery after command failure, file-touch count, and over-broad edits by task class. The real battleground is not generic coding skill. It is participation in a maintenance loop without turning every task into archaeology.