The Problem We’ve Always Had
For years, I’ve watched AI coding assistants make the same predictable mistakes. They’d spit out working code fast, which looked great in a demo. But in production systems where edge cases matter, where concurrency needs to be thread-safe, where data migrations can’t fail mid-transaction, those quick answers often weren’t the right answers. The model would optimize for latency instead of correctness. It knew the syntax but missed the architecture.
This wasn’t stupidity. It was a structural problem. These systems were trained to minimize token generation. Speed was baked into the objective function. You want fast inference for margins and latency budgets, sure. But that means the model learns to confidently produce the first plausible answer, not to think through the hard parts before committing.
I mention this because what changed in February 2025 feels different enough to be worth documenting. Anthropic released Claude 3.7 Sonnet with something they call hybrid extended thinking mode. On the surface, it sounds like a feature. In practice, it’s a different way of teaching a model to work.
How Extended Thinking Actually Works
The mechanism is straightforward but the implications take time to sink in. Claude 3.7 Sonnet can now toggle between two modes within the same API call. For routine questions or simple completions, it responds normally. Fast. Minimal overhead. But when you ask it something that requires actual reasoning, you can enable extended thinking. The model then gets space to do chain-of-thought work before it outputs anything you see.
The constraint is generous. Up to 128,000 reasoning tokens. That’s the model essentially talking to itself, working through the problem logic, stress-testing its own assumptions, catching its own mistakes. Only after that internal audit does it produce the final answer. You never see the reasoning tokens in production. You just get the output.
I tested this on a real code review that landed on my desk last month. A junior engineer had written a database connection pooling solution that looked correct at first read. Good error handling, reasonable pool size defaults. But there was a silent failure case during network partitions that the code didn’t handle. The model caught it immediately when I enabled extended thinking. Not because it’s smarter. Because it had permission to think.
According to Anthropic Claude 3.7 Sonnet announcement, the model scored 70.3% on SWE-bench Verified, a standard benchmark for evaluating how well models solve real software engineering problems. That’s a substantial jump from previous generations. On the SWE-bench Verified leaderboard, that puts it in territory that’s actually competitive with other state-of-the-art systems designed specifically for coding.
Where This Changes Development Workflow
The interesting part isn’t that the model is more accurate. It’s where in your workflow you can now use it. Pull request review is the obvious place. Code review is expensive. It requires a senior engineer to read every line, model every execution path, imagine what could break. Anthropic’s data suggests this is where the gain is most measurable. GitHub Copilot’s enterprise report from February 2026 showed that in teams using advanced AI review assistance, the time from pull request submission to merge dropped by 34%. That’s not trivial when you’re managing code velocity across a large organization.
But there’s a subtler shift happening. The model can now handle the kinds of requests that used to require back-and-forth iteration. Before, you’d ask it to write a parser, it would give you something that handled the happy path, and you’d spend three messages pointing out why that wouldn’t work for malformed input. Now you can say “write a parser that’s fault-tolerant,” enable extended thinking, and the odds of getting something production-ready increase significantly.
I’ve been using it for architecture decisions. I’ll describe a system constraint, enable extended thinking, and ask it to reason through the trade-offs between different approaches. The model catches circular dependencies in my own thinking. It surfaces assumptions I didn’t know I was making. This isn’t the model being clever. It’s the model having time to be thorough.
Stack Overflow’s 2025 Developer Survey showed that 76% of professional developers now use AI coding tools daily, up from 44% in 2023. The trajectory is steep. But I suspect we’re at an inflection point where the nature of that usage is starting to shift, moving from “write me a function” toward “help me think through this architecture.” Extended thinking mode is built for that second use case.
The Tradeoffs Are Real
This isn’t magic. You need to understand the cost-benefit. Extended thinking mode is slower. You’re paying for 128,000 additional tokens of compute. Latency gets worse. For every query, there’s a question: do I actually need deep thinking here, or am I just being cautious? Get this wrong at scale and your bill balloons fast.
The other tradeoff is opacity. When the model thinks, you don’t see the reasoning. Sometimes that’s fine. Sometimes you need to understand why it made a choice. With extended thinking, that chain of logic stays internal. You can’t audit it. You have to trust the output or run it through your own verification process anyway. Which is fine. You should verify production code regardless. But it means the mode is a supplement to your judgment, not a replacement for it.
I’m also cautious about the benchmark number itself. SWE-bench Verified is useful, but it measures specific kinds of problems. Real code has organizational context, legacy constraints, and business logic that benchmarks don’t capture. The 70.3% score means the model gets 70.3% of verified test suites to pass. It doesn’t mean you can hand it your entire codebase and walk away.
What I’m Actually Changing
I’m not replacing my thinking with the model’s thinking. I’m using extended thinking as a peer review layer. When I’m about to commit something I’m not fully confident in, or when I’m reviewing code from someone less experienced, I run it through the model with extended thinking enabled. The output isn’t gospel. It’s another perspective that’s been through some actual reasoning.
On refactoring work, it’s been useful. Complex functions that should probably be split up, database queries that should probably have an index, error handling that’s incomplete. The model catches these things not because it’s perfect, but because it had time to check itself.
For new junior engineers on the team, it’s like having another senior engineer in the room who has time to think through every decision. That’s valuable scaffolding while they develop their own judgment. And it means the human senior engineers on the team spend less time on the routine catches and more time on the strategic decisions.
The deeper pattern I notice is that extended thinking mode is changing what I ask the model to do. I’m asking it harder questions. I’m using it for things that actually require reasoning. And when it delivers, it’s delivering something genuinely useful instead of something that requires correction. That’s the real change. Not the benchmark score. The shift in how I interact with the tool.
If you’ve been following AI-assisted coding, I’d be interested in your own experience with this mode. What tradeoffs have you encountered? Where is it actually making your workflow better, and where is it just adding latency to something that didn’t need to think?
