Even as AI models become more commonplace, it needs to be internalized that they differ from traditional computing in some significant ways.
That is the core of what Boris Cherny, the creator of Claude Code at Anthropic, laid out in a recent interview, where he described the experience of building on top of large language models as something closer to biology than software engineering.
Cherny has spent his career writing conventional systems, the kind where architecture gets planned out in advance, test suites are built to catch regressions, and a re-architecture is treated as a multi-month or multi-year undertaking. Models, he said, don’t behave that way at all. “The model is not like that,” he explained. “The way to think about it is almost like a living creature, like a something more organic. It’s a thing where every model generation, it behaves differently. It has a slightly different personality, and you have to take the time to get to know it and then adjust the harness based on that.”
That framing is a departure from how most engineers are trained to think about the systems they build. A database doesn’t wake up one morning with a different personality. A compiler doesn’t need to be “gotten to know.” But a model, in Cherny’s telling, does, and the practical consequence is that engineering around it stops being a design exercise and becomes something closer to an experimental one. “I think it’s just very much like an empirical and kinda scientific thing,” he said. “You have to take a very scientific mindset to it, where you try something, you see the result, and then you iterate based on that.”
What survives a new model, and what doesn’t
The interviewer pushed Cherny on an obvious follow-up: if the model itself is a moving target, what parts of the system around it are actually built to last? His answer split the stack into two categories with very different lifespans.
Code and system prompts, in his view, are disposable by design. “If you wanna build at the bleeding edge and have the most capability for models, you gotta delete those,” he said. Anthropic’s own postmortem on a Claude Code performance regression earlier this year is a fairly literal illustration of the point — a system prompt instruction that made sense for one model generation quietly cost a coding-quality regression once a new model came in, and had to be stripped back out.
Evals are the opposite case. Cherny described them as the one artifact that persists across model generations, with the caveat that even they have a shelf life. “Evals, they outlive the harness a little bit, but not by that much,” he said. “Like, an eval might live for maybe one, two, three model generations.” Beyond that, the pace of improvement simply outruns the test. “We’re on the exponential,” he said. “The model is improving so quickly. Very often, we just saturate the eval, and then we have to throw it away, and we have to come up with a new eval.”
That idea of saturation is not abstract for Anthropic. Benchmark providers have been retiring and rebuilding entire evaluation suites at a similar clip — Artificial Analysis, for instance, recently rebuilt its intelligence index around agentic workloads and dropped a widely used instruction-following benchmark entirely because it had saturated to the point of no longer separating frontier models from each other. Cherny’s account of an eval getting maxed out and discarded within a couple of model cycles maps almost exactly onto what’s happening industry-wide.
Building the eval by using the product
Where Cherny got specific was on how a team actually decides what belongs in an eval set in the first place. His answer circled back to the same empirical instinct. “You have to use the product. You have to use the model. You have to see where it struggles. And then based on that, that’s the eval set that you should build,” he said.
That’s consistent with how Cherny has described his own workflow shifting over the past year. He has talked about running multiple Claude sessions in parallel across git worktrees, and more recently about writing loops to prompt Claude Code rather than writing code directly himself. Each of those shifts came from noticing, firsthand, where the model was strong enough to be trusted and where it still needed a human to step in — which is essentially the same eval-building process he’s describing here, just applied to his personal habits rather than a formal test suite.
The bigger point Cherny is making is one that a lot of engineering teams adopting AI coding tools haven’t fully absorbed yet: harnesses built around a specific model’s quirks have a short half-life, and treating a system prompt or a scaffold as permanent infrastructure is a mistake once a new generation ships. The only thing worth investing in long-term is the discipline of continuously testing where the model breaks, because the model that breaks there today won’t be the same one in six months.