Claude 5: What Actually Changed, and Why It Matters for Developers

Anthropic recently shipped the Claude 5 family — Opus 5, Sonnet 5, and Haiku 4.5 — and it's the first model update in a while that's actually changed how I work day to day, not just how I benchmark.

The headline: agentic coding, not just chat

Most model releases over the past few years have been measured in chatbot terms — better answers, fewer hallucinations, longer context. Claude 5 is clearly optimized for something different: staying coherent across long, multi-step engineering tasks where the model is reading code, writing code, running tools, and reacting to real feedback loops.

In practice that means:

• Fewer dropped threads. Earlier models would lose track of a refactor's intent halfway through a large diff. Claude 5 holds onto the original goal much more reliably across dozens of tool calls.
• Better judgment about when to ask vs. act. It's noticeably more willing to just fix an obvious bug instead of narrating what it's about to do, but still pauses on genuinely ambiguous or risky decisions.
• Less scaffolding required. I used to write fairly detailed prompts specifying file structure and conventions. With Sonnet 5, a rough description of the desired outcome is usually enough — it infers the right patterns from the existing codebase.

Where I've actually used it

I've been running Sonnet 5 inside my own editor workflow for a few weeks now:

1. Large refactors. Renaming a core abstraction across a mid-sized codebase used to mean an hour of careful, manual find-and-replace. Now it's a five-minute review of a generated diff.
2. Debugging flaky tests. Instead of me reproducing a failure locally, describing symptoms is often enough for it to find the race condition itself by reading the test and the code under test.
3. Reviewing PRs before I send them out. Not glamorous, but catching an off-by-one or a missed null check before a human reviewer sees it saves everyone time.

The part that matters for your career

If you're job hunting or trying to grow as an engineer right now, the practical takeaway isn't "learn to prompt better." It's that the bar for what counts as a well-scoped, well-tested change just moved up, because the tooling to get there moved up. Interviewers and hiring managers increasingly expect candidates to be fluent with these tools — not as a crutch, but as a multiplier.

The engineers who are struggling right now are the ones treating AI tools as a novelty. The ones getting the most out of this moment are treating it the way senior engineers treat any other force multiplier: understand its failure modes, verify its output, and use the time it saves to go deeper on the parts that actually require judgment.

That's the theme I keep coming back to on this blog, and it's exactly why I'm building KGG around it.