Claude Opus 4.6 has a million token context and

I fed Claude Opus 4.6 my entire codebase. Every file. Every configuration. Every test. 800,000 tokens.

Then I asked it to find the bug I’d been hunting for three days.

It found it in forty seconds.

What happened

The bug was subtle. A race condition between two async functions that only manifested when a specific API call returned slower than usual. The error appeared in file A, but the root cause was an interaction between files B, C, and D. File B set a state variable. File C read that variable. File D, in a completely different directory, modified the timing of the read.

I’d been looking at files A and B for three days. I hadn’t connected file D to the problem. It was in a utility folder. Seemingly unrelated.

Claude Opus 4.6 read all four files (along with 400 other files), traced the data flow, identified the race condition, and explained it by referencing the specific lines in files B, C, and D where the interaction occurred.

The explanation was lucid. The fix was simple. The connection between files was something I would have found eventually, but “eventually” was at least another day of debugging.

What a million tokens means

Previous models had context windows of 8K, 32K, eventually 200K tokens. You could show them a function, a file, maybe a few related files. You had to choose which parts of your project to include. You were the curator.

A million tokens changes that. You don’t curate. You include everything. The model holds your entire project in working memory and reasons across it the way a senior engineer would who’s been on the project for months.

The difference between “I showed the model a few files” and “the model read my entire codebase” is the difference between asking someone to review a function and hiring someone who already knows the system. The latter is dramatically more useful.

What this changes

Code review becomes project-wide. Instead of reviewing a diff, the model reviews the diff in the context of the entire codebase. It catches architectural inconsistencies, not just syntax errors.

Bug hunting becomes project-wide. The model can trace data flows across hundreds of files. The kind of investigation that takes a human days takes the model seconds.

Onboarding becomes instant. A new developer can ask the model about any part of the system and get an answer that accounts for the full context. Not “here’s what this file does” but “here’s what this file does, why it exists, what depends on it, and what breaks if you change it.”

What I’m feeling

Grateful. The bug was killing me. Three days of frustration, ended in forty seconds.

Disoriented. The gap between my debugging speed and the model’s debugging speed is wide enough to be existential. Not “I’m going to lose my job” existential. “What is my role?” existential.

I think my role shifts from “person who finds bugs” to “person who decides what the system should do and evaluates whether the AI’s suggestions are right.” That’s a meaningful role. But it’s different from what I thought programming was.

Every few months, Anthropic releases something that makes me rethink what I do. This is one of those months.

I’m adapting. I always adapt. But the adaptation is getting faster because the changes are getting faster. And I’m starting to wonder how many adaptations a career can absorb before it becomes a different career entirely.

A million tokens. Forty seconds. A bug that took me three days.

The math doesn’t lie. And the math is changing.

Related thinking: