The Moment It Clicked
February 2025 doesn’t feel that long ago, but it does feel like a different era for how we write code. When Anthropic rolled out Claude 3.7 Sonnet with extended thinking mode, I was skeptical. Another incremental release. Another promise of better reasoning that would probably just mean slightly better outputs at slightly higher latency.
I was wrong. Not catastrophically so, but wrong enough that I’ve spent the last six months quietly rewriting how my team approaches code review, architecture decisions, and debugging workflows. The difference isn’t marginal. It’s architectural.
The core innovation is deceptively simple: the model can now spend variable compute time reasoning before responding, up to 128,000 thinking tokens. That’s roughly the equivalent of letting an engineer think through an entire codebase before committing to an answer. You can’t see the thinking in your API response. It happens in the background. But you feel it.
The Numbers Don’t Lie, But They Don’t Tell the Whole Story Either
On SWE-bench Verified leaderboard, Claude 3.7 Sonnet scored 70.3% on real-world software engineering tasks. GPT-4o sits at 38.8% on the same benchmark. That’s not a small gap. That’s the difference between a tool that occasionally helps and one that consistently solves problems.
But benchmarks measure one thing: how well a model performs on predetermined tests. They don’t measure what happens when you’re at 2 AM staring at a race condition in a distributed system, or when you’re trying to refactor a legacy codebase where the original authors left three years ago and the documentation is a fairy tale.
What I’ve seen in production is different. Extended thinking mode means the model spends real time considering edge cases, potential failure modes, and architectural implications. It asks itself questions. It second-guesses its own answers. Then it commits to a response that’s usually thoughtful enough to save you an hour of painful debugging.
Adoption Is Real, But Trust Remains the Actual Bottleneck
GitHub Copilot crossed 1.8 million paid subscribers in early 2025, and when Microsoft integrated Claude 3.7 as a selectable model in agent mode, adoption accelerated. AWS’s Amazon Q Developer reported that enterprise customers using agent mode completed code transformation tasks 80% faster than manual refactoring. Speed is becoming the commodity.
The Stack Overflow survey from 2025 is the more interesting story. Seventy-six percent of developers are now using or planning to use AI coding tools. That’s a 14-point jump from 62% the year before. The shift is real. But here’s the detail nobody dwells on long enough: 58% still list trust in AI-generated code for production as their top concern.
That’s the friction point nobody talks about enough. It’s not capability anymore. It’s confidence. Teams have moved past “Can the AI write code?” to “Can I trust the AI’s code in my production system?” Those are fundamentally different questions. The first is technical. The second is organizational and cultural.
How Extended Thinking Actually Changes Your Workflow
Here’s what six months has shown me about real usage patterns. When you enable extended thinking mode for specific tasks, you’re not paying a massive latency penalty for earth-shattering improvements. You’re paying a moderate latency cost for consistently better reasoning about complexity.
Our team started using it for three categories of work. First: architectural reviews. Instead of writing a PR comment and waiting for debate, we throw Claude 3.7 at the proposed architecture with extended thinking enabled. It explores trade-offs, questions assumptions, and flags issues that miss the initial conversation. Sometimes it catches something real. Often it just validates what we were already thinking, which has its own value.
Second: refactoring large modules. Extended thinking mode lets the model hold the entire context of a system in focus while considering implications. It’s not perfect. It still misses things. But it reduces the cognitive load of refactoring from exhausting to manageable.
Third: debugging unfamiliar codebases. When someone on the team needs to understand a system they didn’t write, extended thinking mode combined with codebase context yields something surprisingly close to having the original author explain the design decisions.
What doesn’t work? Real-time code completion. Extended thinking adds latency. For quick inline suggestions, you still want a faster model. The interesting architectural problem is figuring out when to invoke extended thinking and when to reach for speed.
The Trust Question Hasn’t Changed, But the Conversation Has
I’ve watched teams move from “We won’t use AI code” to “We’ll use AI code but verify everything” to “We’ll use AI code and spot-check the risky parts.” That’s progress, but it’s not solved. It’s managed.
The honest take after six months: extended thinking mode creates better code suggestions. That’s measurable. Whether those suggestions are trustworthy in your specific production context is something only you can determine by reading the code, understanding your system’s failure modes, and making a judgment call.
Some teams have built integration testing frameworks around AI-generated code. Others treat it as a draft that requires architectural review before merge. A few have established policies about which services can include AI-assisted code and which cannot. None of these approaches is universally correct.
What matters is that extended thinking mode makes the conversation more sophisticated. You’re not debating capability anymore. You’re debating trust and risk tolerance and organizational policy. That’s the conversation we should be having.
What’s Actually Changed
Six months in, the biggest shift is this: AI code assistance moved from “neat tool” to “architectural consideration.” When you’re designing systems now, you have to think about how your code will appear to an AI model. Will it be clear enough for extended thinking to parse? Will the context window contain enough information? These are legitimate design questions.
The benchmark numbers matter. The subscription adoption matters. But what matters most is whether your team has figured out how to fold this capability into your actual workflow without either blindly trusting it or refusing to use it at all.
If you’re still evaluating whether extended thinking mode is worth the latency trade-off, run it against one of your current pain points. Don’t compare it to your favorite model. Compare it to your current process. That’s the relevant baseline.
What’s your experience been? Have you integrated extended thinking into your workflow, or does it still feel like an experiment? Drop a note if you’re willing to share what’s worked and what hasn’t.