Is Sonnet 4.6 truly the king of code? We tested it on refactoring legacy Java, writing Rust compilers, and debugging React race conditions.
What We Put Sonnet 4.6 Through
Calling any model “the best for code” only means something if you stress it on work that actually breaks weaker tools. We ran Sonnet 4.6 on three jobs that fail for different reasons: refactoring legacy Java (large surface area, unclear ownership, brittle tests), sketching pieces of a Rust compiler-style pipeline (strict ownership, types as contracts, little room for hand-wavy APIs), and chasing a React race condition (timing, stale closures, effects that fire in the wrong order).
The goal was not a leaderboard score. It was to see whether the model stays useful when the problem is messy, multi-file, and easy to “solve” with a patch that looks right and still ships a bug.
Legacy Java Refactors: Scope Control Beats Cleverness
On legacy Java, the failure mode for coding models is usually overreach. They rename too aggressively, invent abstractions the team never asked for, or “modernize” a module without respecting call sites that live outside the open files. Sonnet 4.6 was strongest when we constrained the task: name the public API that must not change, list the packages in scope, and require a short plan before any edit.
Where it helped most was mechanical but judgment-heavy work: extracting a service from a god class, threading a dependency through constructors instead of static helpers, and updating callers so behavior stays aligned with existing tests. Where it still needed a human was product intent—whether a dead path should stay for compatibility, and which “temporary” flag is load-bearing. Treat it as a careful junior with infinite patience for diffs, not as the owner of the migration strategy.
Rust Compiler-Style Work: Types as the Spec
Asking a model to help with Rust compiler-adjacent code is a stress test for precision. Ownership, lifetimes, and error types punish vague design. Sonnet 4.6 performed better when we framed the problem as a pipeline with explicit stages—lex, parse, lower, type-check—and asked for small interfaces between them rather than one giant “write a compiler” prompt.
It was useful for sketching AST shapes, visitor patterns, and error reporting that carries span information through the stack. It was less reliable when we left the intermediate representation underspecified; then it filled gaps with plausible but inconsistent choices. The practical pattern: lock the data structures first, then ask for one stage at a time, and only accept code that compiles against the types you already committed to.
React Race Conditions: Reproduce Before You Patch
Race conditions in React rarely yield to “add another useEffect.” They show up as double fetches, state updates after unmount, or UI that reflects an older request because a newer one finished first. With Sonnet 4.6, the quality of the fix tracked the quality of the repro steps we gave it: sequence of user actions, which state is shared, and which request is allowed to win.
It was effective at proposing patterns that actually address concurrency—abort controllers, request IDs, effect cleanup, and separating “load” from “commit to state.” It was less useful when we only pasted a component and asked “why is this flaky?” without a timeline. For UI races, force the model to narrate the interleaving it believes is happening, then implement the guard that makes only one interleaving valid.
- Scope the files and invariants before any multi-file edit.
- Prefer typed interfaces and stage boundaries over open-ended generation.
- For bugs, demand a repro sequence and a failing assertion before a fix.
- Review every change as if a confident teammate wrote it overnight.
Sonnet 4.6 earns a strong coding seat when you run it like a pair programmer with a tight brief: clear constraints, small steps, and verification you own. Used that way, it is less a magic “best model” label and more a reliable accelerator on the hard paths—legacy refactors, strict-typed systems work, and concurrency bugs that only show up when timing goes wrong.