Inside How Anthropic Builds the Next Claude
Every workaround I wrote for Claude this quarter has a half-life. Most won't survive the next model.
If you've spent the past six months hardening your stack against Claude's quirks — elaborate retry logic for tool calls, prompts stuffed with negative examples, parsers that paper over malformed JSON — you've been investing in a depreciating asset, and I've been right there with you.
That's the uncomfortable read I came away with after Alex Albert's tour of how Anthropic builds the next Claude. The interview is full of useful detail about research process, capability scoping and character training, but the engineering implication is sharper than the conversation lets on: most of what we call "AI engineering" today is debt. The people who recognise that will move faster than the people who don't.
The roadmap was written nine months ago
Albert's team picks the big capability bets before pre-training even begins. Coding, knowledge work, agentic behaviour — these aren't emergent properties Anthropic discovers post-hoc. They're scoped by talking to enterprise customers and by Anthropic employees getting blocked in their own day-to-day work. The roadmap is decided months before a single line of training code runs.
Sit with that for a second. The model you're about to receive was scoped from feedback collected nine to twelve months ago. Whatever pain you're patching today — the brittle tool use, the inconsistent long-context reasoning, the half-working JSON mode — is probably already on someone's roadmap in San Francisco. By the time you've finished writing the elaborate scaffolding to work around it, the next model lands and your scaffolding is technical debt.
I've already lived this cycle once. Remember the JSON-mode hacks from a year ago: prompts ending in {"answer":, regex-driven post-processors, brittle few-shot examples. Most of that code went in the bin the day structured outputs landed. The teams I know that kept the simplest possible wrapper shipped the upgrade in an afternoon. The teams that built defensive moats around the old behaviour spent a sprint untangling them. I was in that second camp once. I won't be again.
The harness is the product
The second insight from the interview is subtler. Albert points out that the model and the harness are coupled — the same weights produce wildly different behaviour depending on the surface they're invoked through. Claude.ai, Claude Code, Claude in an IDE, your custom agent loop: all running the same model, all behaving differently because the surrounding prompt and tool setup differs.
If you're building on Claude, this should change how you think about your own stack. Your harness — the system prompt, the tool definitions, the retry logic, the context-stuffing strategy — is not infrastructure. It is the product. It shapes user-visible behaviour as much as the weights do.
That's load-bearing. If the harness is the product, it deserves the same care as the rest of your codebase: a written specification, evaluation suites, regression tests on real conversations. And it deserves the same scepticism. Most of what's in there can be deleted.
"If it's not a one-way door, it's essentially free"
The line I keep coming back to is Albert's framing on decision-making: most decisions are reversible, and reversible decisions should be made fast. He uses it to explain how Anthropic ships, but it lands harder when I point it at my own code.
Almost every line you write to wrap a model is reversible. Swap the prompt, swap the tool definition, switch the model — none of it is a one-way door. So why are we all treating it like one?
The reflex on most teams I've worked with is to harden every workaround into a permanent abstraction. A flaky tool call becomes a retry framework. A brittle prompt becomes a templating system. A one-off evaluation becomes a pytest suite with fixtures and parameterisation. Each abstraction feels responsible in the moment. Collectively they slow you down, and they bake in assumptions about the current model that won't hold for the next one.
Albert's "minimal scaffolding, test on the latest model" rule for new builders applies to all of us. Use the simplest wrapper that works. When something breaks, fix it inline before you abstract it. When the next model ships, throw away the workarounds you no longer need. That's not laziness — that's how you stay upgradeable.
Character is engineered, not discovered
The interview's section on character training is fascinating on its own terms, but I want to flag it for a different reason: it's a reminder that Claude's behaviour is the outcome of deliberate engineering choices, not vibes. When Claude refuses something it shouldn't, or hedges where you wanted directness, that's a training-time decision someone made on purpose.
This should change how you report problems. "Claude is annoying" is feedback that goes nowhere. "Claude added an apology before every tool call in our agent loop and it broke our parser at this exact regex" is feedback that gets prioritised. Anthropic's research team is making bets about what to fix next quarter; specific, reproducible, behavioural reports are the input.
If you're building something serious on Claude, file specific bugs. From the way Albert talks about the feedback loop, the roadmap genuinely incorporates them — but only when they're concrete enough to act on.
A prediction you can disagree with
Here's my take, and you're welcome to disagree: in eighteen months, somewhere between half and two-thirds of the "AI engineering" code sitting in production today will be obsolete or actively harmful. The teams that ship fastest will be the ones who built the thinnest possible harness around the current frontier model and accepted that they'd rebuild every six to nine months.
The teams that built elaborate orchestration layers, custom retry frameworks, defensive parsing libraries and bespoke prompt-management systems will spend the next eighteen months unwinding them. And the ones who can't unwind will be stuck on whichever model their stack was tuned for, watching competitors ship faster on the next one.
The counter is real and I want to acknowledge it: enterprise teams need determinism, latency budgets, cost controls and audit trails that the simplest wrapper doesn't give you. But look closely at that list. None of it requires hardening around current model quirks. It requires hardening around your own product's invariants. Those are different problems, and most teams I've seen have conflated them.
That distinction is the whole point. Anthropic is going to keep moving the model — you don't control that timeline. What you do control is whether your stack treats every model release as a free upgrade or a forced migration.
What I'm doing on Monday
Three things, in order of impact.
Delete one workaround. Pick something you wrote to work around model behaviour that's been improving release over release. Try removing it. If the latest Claude handles the case, you've just paid down debt for free.
Test on the frontier. If you're still pinned to a model from two releases ago because "the new one behaves differently," I'd bet the difference is your harness, not the model. Run the same prompts through Claude unmodified and compare. The gap is usually smaller than the lore suggests.
Treat your harness as product. Write down what behaviour it's supposed to produce. Evaluate it. Version it. Be willing to throw it away when the next model lands and makes half of it unnecessary.
The next Claude is already being scoped. The smartest thing you can do this quarter is build like you know that.
Sources I drew from: