The Calculator Feeling Is Back
I had to laugh when Boris Cherny opened the Code with Claude London keynote with the TI-83 story. I was a Casio kid myself, but the rest of it was the same. Little programs you typed in by hand. The trick where you store math formulas in a program and pull them up during the test, technically allowed because nobody on the proctoring side understood what was on the screen. The first time a program you wrote actually ran. That giddy feeling.
I want to walk through what he was actually saying with that opener, because the rest of the talk hangs on it, and because the rest of the talk is the most direct articulation of where Anthropic thinks coding is going that I have seen this year.
If you have ten minutes, this is worth your time. Reply to this email and tell me whether the calculator feeling lands for you too. I am curious whether it is a generational thing or whether the new wave of developers feels it the same way.
The Line
The line in the keynote that does all the work is this one:
"You describe a problem and the program shows up. It's the calculator feeling except the calculator can write a distributed system."
Stop and read that twice.
The story Boris tells is that programming used to be tinkering. Type something in, see it run, feel a small thrill. Then it got complicated. Compilers, type checkers, build systems, package managers, twelve config files before you wrote a single line of code. The distance between "I have an idea" and "it runs" kept getting longer. For a generation of people who came in through tinkering, that distance felt wrong. It was supposed to be closer.
What is happening now, his argument goes, is that the distance is collapsing again, and the thing on the other side of the gap is much bigger than a calculator program.
I think this is the right frame. I have been writing about AI in production for two years and the moments that have actually shifted my thinking are not benchmark scores. They are the small moments where I described a thing and the thing showed up. Last week I described a billing rule to Claude Code and it wrote, tested, and shipped the rule in 15 minutes. Twenty years ago that would have been a two-week project with a meeting, an architecture doc, and three rounds of QA. The thing that has changed is not the rule. It is the distance.
The Three Customer Stories Worth Remembering
The keynote pivots from the calculator story to three customer wins. These are worth keeping in your head because they each sit at a different point on the curve.
Spotify. A team at Spotify built a background agent on Claude Code. It reads a migration described in plain English, then runs that migration across a fleet of agents. PRs land. More than a thousand a month, into production. Migration time cut by over 90%. Boris's framing: "That's real engineering hours back."
Anyone who has worked at a large engineering org knows what migrations feel like. They are the unglamorous, never-finished tail. Every framework version bump, every internal library rename, every API deprecation. The work that fills sprint planning meetings and never gets celebrated. Spotify points a fleet at it overnight. Humans review. The hours that used to go into mechanical refactors go somewhere else.
Binty. This one stayed with me. Felicia Coruru runs Binty. Her software is the system case workers use to place kids in foster care. Paperwork, home visits, licensing. Her team used the Claude API to give case workers back the hours they used to spend on paperwork, and they took 20 days off the licensing process for a foster family.
Twenty days. As Boris said, "That's a kid connecting with a family."
I want you to sit with that one. We talk a lot about productivity. We talk a lot about engineering hours and developer experience. We almost never talk about what the productivity is for. Twenty days off the licensing process is twenty days less that a kid sits in a system that nobody wants them sitting in. That is the actual point.
Mythos. Last month, Mythos read the entire OpenBSD source tree and found a 27-year-old vulnerability that survived every human reviewer, every fuzzer, every static analyzer ever pointed at it. Three decades of careful security review missed it. A model found it.
The keynote gives this one a sentence and a half. The sentence and a half is enough. Mythos is the case where the model does something humans literally could not.
These three stories are not picked at random. Spotify is volume and speed at scale. Binty is mission impact in a domain that does not usually get frontier AI attention. Mythos is the discovery case. Three different shapes of the same underlying capability.
The Gap That Actually Matters
The argument that runs through the rest of the keynote is direct. Model capabilities are improving on an exponential curve. Most organizations are adopting AI on a linear path. There is a growing gap, and the gap is the interesting thing.
The numbers Anthropic put on the screen:
- API volume on the Claude platform up nearly 17x year over year.
- The average Claude Code developer is now running Claude more than 20 hours a week.
The 20-hours-a-week number is the one I keep coming back to. That is more than half of a developer's coding time. That is not an experiment. That is the workflow. If your team is still treating Claude Code as a sometimes tool, the rest of the industry has already moved on.
The keynote frames this as the developers' job to close. Translating model capability into something people can actually use is the work. The model is doing its part on Anthropic's side. The platform team is doing its part. The Claude Code team is doing its part. The work that does not get done by any of those teams is the work of taking what is shipping at the model layer and turning it into something your users feel. That is the developer's job, and it is the job that is growing in value as the gap widens.
Build for the Next Version
Lisa from the research PM team took the stage after Boris and made the argument that lands the hardest, at least for me.
"Build for emerging capabilities, not just what works today. That means designing for the next version of Cloud, not the current one. We've seen countless times that the developers who win are the ones whose architecture is ready to absorb the next big jump."
This is the part of the talk I would print and stick on a wall.
The reasoning is this. If your scaffolding is tuned for what works today, you are building for the floor. The scaffolding that helped a less capable model often holds a more capable one back. Generalized primitives, a file system, a sandbox, the right tool surface, those outlast model upgrades. Hand-tuned, brittle, prompt-heavy scaffolding does not.
The metric Lisa used is task horizon. How long can a model work before losing the thread. Last year, models reliably worked for minutes. Today, agents run for hours. The expectation she set is that future Claude generations run continuously. Proactive, always on, responsible for high-level goals.
The example she gave is the one to internalize. Instead of asking Claude to write a project update, you ask Claude to keep the project on track this week. Instead of asking Claude to produce a financial forecast, Claude owns and updates the forecast over time.
If you read your current Claude Code usage against that frame, you will probably find that you are still using it like a smarter autocomplete. The talk is asking you to use it like a colleague who works for you while you sleep.
Routines, Or, The Higher-Order Prompt
Boris closed the demo with a line I keep thinking about.
"The default isn't 'I'm going to prompt Claude Code'. The default is now 'I'm going to have Claude prompt Claude Code'."
Routines, in the new Claude Code, are configured prompts that run on a schedule, in response to a webhook, or via an API call. The example in the demo: a teammate filed a GitHub issue overnight. A routine watching the repo picked it up. The work clock started. A PR appeared. The engineer did not type a prompt to make any of that happen.
If you have ever been responsible for the on-call rotation of an engineering team, you know what this is worth. The mechanical, predictable, kicks-off-when-something-happens work is most of the work. Auto-fixing flaky CI. Auto-rebasing on merge conflicts. Auto-addressing the comments that show up in code review. Auto-checking the customer bug reports that come in overnight.
Boris framed it as a higher-order function. Routines are higher-order prompts. You write the prompt that writes the prompts. The work shifts up a level.
The Mercado Libre Detail
The customer story that I want to leave you with is not Spotify and not Binty. It is Mercado Libre.
Latin America's largest e-commerce platform. 23,000 engineers. The whole org runs on Claude Code. Over 500,000 PRs reviewed with human oversight. Over 9,000 apps modernized. Targeting 90% autonomous coding in a fully agent-driven PR loop by Q3 of this year.
The detail Boris highlighted:
"The detail I love the most isn't just the number. It's that managers and VPs who haven't committed code in years are now shipping again. Cloud Code is putting coding back in the hands of people who've spent the last decade in reviews and roadmap sessions instead of in their codebase."
This is the calculator feeling again, but for the people who lost access to it through promotion. Engineering managers and VPs who got promoted out of the codebase and into meetings about the codebase. The pull request as a hobby. The Saturday side project as the only place where the feeling still lived.
Claude Code is giving those people a way back. The feeling is contagious because it works the same way for the indie dev and the VP. It is the same trick the calculator pulled in the math classroom, just dressed up in a TUI.
The Platform Layer, Briefly
The middle of the keynote belonged to Angela and Caitlyn from the platform team. I will not walk through every feature, but two are worth flagging because they change what an enterprise Claude rollout looks like.
The first is the advisor strategy. A small model executes, a large model advises when the small one gets stuck. The numbers Anthropic put up: Sonnet plus Opus advisor outperformed Sonnet alone, and did it more cheaply, because Opus advised it to get the work done better. Eve Legal reports frontier model quality at five times lower cost. This is the cleanest pattern I have seen for the perpetual question of how to use Opus without burning a budget. Use it as the consultant your executor calls, not the worker who does every line.
The second is the combination of MCP tunnels and self-hosted sandboxes. Claude Managed Agents can now reach your internal MCP servers without those servers being on the public internet, and they can execute code in your own infrastructure on Daytona, Cloudflare, Vercel, or Modal. The compliance objections that used to gate every enterprise pilot just got a much smaller surface. If your CISO has been asking you why agents need to call out to public infrastructure to execute code on your data, you can stop having that conversation.
What I Am Taking Away
A few things that I am turning into actual changes in how I work this month.
First, audit how much of my coding time is synchronous. If I am still sitting and watching Claude Code work, I am using it like a 2024 tool. Routines and async PRs are the 2026 shape.
Second, build harder evals. Lisa's line about evals as the seismograph of the exponential is the right one. If all my evals pass on every model, they are too easy. I want at least a quarter of my evals to fail today.
Third, audit my scaffolding for the brittle bits. The places where I have specific tools, specific prompts, specific guardrails to compensate for what the model could not do six months ago. Those are the places that will hold me back in three months. Strip them out, see what the model does with generalized primitives.
Fourth, write one routine this week that I would have run by hand. Anything that I do on a schedule that involves prompting Claude Code is a routine. The on-call rotation, the weekly dependency update, the customer support triage, the dashboard refresh, the morning summary of overnight PRs. Each of those is a routine waiting to be written.
Fifth, find one piece of work this quarter that the model can do but humans cannot, in the spirit of Mythos finding the OpenBSD vulnerability. That is the work that justifies the entire investment. If you cannot point at one impossible thing you did this quarter, you are still leaving the calculator on the desk.
The capability is already here. The remaining gap, as Boris said in the close, is how fast we put it to work. That is the assignment.
What is the calculator feeling for you this week? Reply and let me know. I read every reply.
Source talk: Code with Claude London 2026: Opening Keynote. https://youtu.be/6amLO7I9xdg