For a while, the AI coding conversation sounded like a single question: How close can we get to “universal” intelligence by scaling up? But in practice, developers don’t live in benchmarks. They live in tickets, pull requests, CI failures, and deadlines. And that’s why Claude 3.5 Sonnet quietly became the developer’s model of choice for code generation and analysis—despite not being the obvious “flagship” pick.

The “mid-tier” model that shipped the goods⌗

In the typical model lineup narrative, “best” almost always means “biggest.” The marketing gravity goes to the headline model—more capability, more ambition, more compute. The smaller sibling is often treated like an economy option.

Claude 3.5 Sonnet flipped that script for developers.

The surprising part isn’t that Sonnet can code. Most modern frontier models can produce working code when you give them a clear prompt. The surprise is that Sonnet feels operationally useful: it tends to hit the sweet spot where you can iterate quickly, get coherent reasoning, and avoid the “draft-your-own-architecture” problem that plagues weaker models.

Developers discovered it the way they always discover good tools: not by reading a press release, but by running a real task end-to-end. “Can it refactor this without breaking things?” “Can it update the call sites and imports correctly?” “Will it suggest a test strategy instead of dumping random assertions?” Sonnet answered those questions with fewer follow-ups than many expected from a non-flagship model.

Why speed and cost matter more than you think⌗

Coding with AI is a feedback loop. You don’t just want one perfect output—you want a dialogue that converges quickly. In that loop, time and cost are not “secondary concerns.” They determine whether you can actually use the model repeatedly, throughout the day, on the kinds of problems that show up in production engineering.

Here’s what that looks like in practice:

  • Refactoring work rarely fits in one prompt. You ask for a change, you review the diff, you catch a logic edge case, you re-prompt with constraints (“preserve behavior,” “keep API stable,” “update tests accordingly”).
  • Test generation often needs iteration. You’ll accept an initial test suite, then realize you need more coverage for a boundary case, or you want to switch from integration tests to unit tests for determinism.
  • Codebase explanation is not a one-shot activity. You ask the model to summarize a module, then you ask follow-ups: “Show me the data flow,” “Where is the authorization enforced?” “What happens on retry?”

When a model is “good enough,” it becomes easier to do more turns. And when you can afford more turns, you get higher-quality final results. In the end, “best” becomes: best at solving your real problems with the resources you actually have.

Sonnet landed there—strong enough to do serious coding work, fast enough to iterate without friction, and priced in a way that encourages developer usage rather than experimental dabbling.

Complex refactoring: the difference between code and a change⌗

A lot of models can generate code snippets. Fewer models can perform refactoring in a way that feels like a developer touching a live codebase.

Claude 3.5 Sonnet’s standout behavior in refactoring is its tendency to reason about the change as a system:

  • It identifies what needs to be updated (call sites, types, interfaces, error handling).
  • It preserves invariants (data formats, side effects, contract semantics).
  • It accounts for knock-on effects (tests, mocks, configuration).

A typical refactoring request might be:

“Extract this validation logic into a dedicated module. Keep the public API unchanged. Update any tests that depend on old error messages.”

In many models, this turns into a partial rewrite: a new module appears, but error messages drift, tests still expect the old behavior, or subtle semantics change. Sonnet more reliably produces refactors that “close the loop”—a change that includes the scaffolding and verification needed to merge safely.

The practical takeaway: when you refactor, ask for the full transformation, not just the new function. Include requirements like “preserve behavior,” “update tests,” and “keep interfaces stable.” The best models will follow through.

Tests that don’t feel like an afterthought⌗

Generating tests is where model competence becomes visible. A weak model writes tests that are either too shallow (“assert true”) or overly brittle (hard-coding irrelevant details). A strong model produces tests that map to behavior and edge cases.

Sonnet tends to do something valuable: it treats tests as part of the design.

For example, if you ask it to implement a feature—say, adding idempotency keys to an API—Sonnet doesn’t just write the endpoint handler. It typically proposes a test plan that covers:

  • Happy path behavior (first request succeeds, subsequent duplicates are handled correctly)
  • Edge cases (missing or malformed keys, TTL expiration behavior)
  • Failure modes (database constraints, retries, concurrency considerations at the application level)
  • Integration boundaries (what should be mocked vs. exercised end-to-end)

Even when you don’t explicitly request a testing strategy, the model often generates tests that correspond to the meaning of the feature, not just its syntax. That’s exactly what developers need when they’re trying to land changes quickly without turning QA into a guessing game.

Practical advice: prompt for tests in the same style you write them. If your team uses Jest, pytest, or Go’s testing package, specify the framework and conventions. Then add one sentence: “Write tests that would catch regressions in behavior, not implementation details.” It forces the model to aim at correctness rather than imitation.

Explaining codebases with coherent reasoning⌗

Another underrated coding use case is analysis: understanding code you didn’t write. This is where many AI outputs become “helpful-sounding” but shallow—summaries that don’t actually answer the questions you care about.

Sonnet’s strength shows up when you use it like an engineering partner, not a search engine:

  • “What is the data flow from request to response?”
  • “Where is permission checked, and how is it enforced?”
  • “Which functions mutate state, and under what conditions?”
  • “If I add this feature flag, what are the minimal changes?”

When it works well, you get a narrative you can follow—one that maps responsibilities to locations in the codebase. You can sanity-check it against what you see in files, then ask targeted follow-ups.

If you’ve ever used a model that “explains” by listing functions, you know how frustrating that is. A coherent explanation should help you predict behavior. Sonnet’s outputs often feel like they’re aiming at that prediction, not just summarization.

A practical workflow that works well: ask for a brief explanation first, then request a diagram-like breakdown in text (components → inputs → transformations → outputs). Finally, ask where the critical invariants live. You’ll get fewer meandering answers and more actionable guidance.

The real lesson: “best” is the time-cost tradeoff that wins⌗

The industry’s loudest instinct is to chase the largest model. But developers don’t optimize for theoretical capability—they optimize for throughput, iteration speed, and merge safety.

A flagship model can be excellent, but it may come with constraints that matter in daily work:

  • slower response times that break your momentum
  • higher per-request costs that limit experimentation
  • output styles that require more editing to integrate cleanly

Sonnet’s success suggests a clearer rule of thumb: the “best” coding model is the one that reliably completes the loop—generate, review, modify, test—within the constraints of real engineering time.

In other words, the winning model is often not the most impressive. It’s the one that makes the engineer feel faster without sacrificing correctness.

Conclusion: pick the model that matches your workflow⌗

Claude 3.5 Sonnet became the best coding model for many developers not because it was destined to be the headliner, but because it fit the real demands of coding work: speed for iteration, capability for non-trivial changes, and enough coherence to reduce back-and-forth.

If you’re evaluating models for development use, don’t start with “which is smartest?” Start with “which will make me ship?” Run a few tasks that mirror your day—refactor with tests, implement a feature with edge cases, and explain an unfamiliar module. The model that wins will almost certainly be the one that handles your constraints, not just your ambitions.