Andrej Karpathy has a useful framing for what shifted. We moved from handwritten code fed to a compiler to context fed to a much more general interpreter. The context window is the program and the AI is the interpreter.

The interpreter is new. The cost of producing plausible programs collapsed because the new interpreter is vastly more general than a compiler.

But if the program is now a prompt and a probabilistic runtime, what artifacts do we keep around?

Agents don’t feel pain. Humans do. This insight, pointed out by Mario Zechner, turns out to be quite profound.

Pain in a codebase is a signal. It’s a feeling that senior developers have spent decades calibrating and say “no, we don’t need that”. It’s the thing that triggers a large refactor even though it will not add any new features to the next release. Pain is what kept the size and shape of systems honest.

The all-or-nothing stance that dominates AI debates is not helpful. Neither of the extreme positions “we don’t use AI here” and “we let Claude YOLO all our code” is productive. Both avoid having to think about the actual problem: how to use this powerful new tool without breaking the codebase with hundreds of invested man-years?

Turns out the answer is obvious: start with the work that is boring, low-risk and easy to review.

Simon Willison’s collection of Agentic Engineering Patterns includes an excellent post called “Hoard things you know how to do”. The short version is that you should collect examples of how to solve problems, in code preferably, so you can show your AI agent later. One line in particular is worth pulling out:

“The key idea here is that coding agents mean we only ever need to figure out a useful trick once.”

Read more...

Code is not scarce anymore. We are already living in the world of too much plausible code. That does change our job as developers. However, the job was never just typing anyway. Good developers always brought other things to the table and those things matter more than ever.

Judgment matters. Debugging matters. Taste matters. Systems thinking matters. Tradeoff analysis matters. Being able to explain what the system is doing and why it matters. Saying no matters. Deciding what gets reused and what gets thrown away matters. A lot of what you’re actually paying for in a strong senior engineer is fast, correct judgment over and over again.

In practical terms the big thing that changed is this: plausible code is now basically free. Getting from a vague thought to something that looks like software is dramatically easier than it was. That does not mean building good software is suddenly easy. But it does change what actually matters.

A weird consequence is that the explanation of what you actually want starts to matter more. If code can be regenerated quickly, then more of the value shifts into direction. What problem is actually worth solving? Which tradeoff matters? What kind of change should even exist in the first place, really?

In many software companies the percentage of AI generated code is steadily increasing. This accelerating code churn is driven by human-in-the-loop AI agents but also fully automated AI cleanups and codemods. Many developers feel more productive and their number of landed changes has gone up. The shipped code seems to work ok, and if not, the AI agent can often root cause and fix bugs quickly.

However, the increased velocity made possible by AI is often inversely proportional to the team’s understanding of the codebase. What’s happening right now in many large codebases is that teams keep shipping while quietly losing the plot.

AI tooling is not impacting the software industry in a uniform way. The YC startup bubble gets most of the attention and that distorts the picture. Move fast and break things is simply not viable in big parts of the industry.

Take heavily regulated industries like finance. It’s easy to mischaracterize these companies as slow-moving or even lazy, when in reality they’re solving a harder problem. Generating plausible code faster is clearly useful. But a bank is not being asked to ship plausible products. It’s being asked to produce changes that can be explained, reviewed, approved, operated and defended later.

If you have spent some time with the recent slate of AI agents (post Opus 4.5) you probably went through roughly the same mental journey as the rest of us:

This thing is incredibly powerful, I can’t believe it managed to fix that bug / implement that feature / create this tool that I’ve been meaning to write for years

Quickly followed by:

We (software developers) are all cooked

If you keep going down that path, the next couple of insights are more interesting. Yes, everyone (including non devs) has a code-gun now and can produce large amounts of plausible-looking code. But while it looks like really good code, with large amounts of tests, it probably doesn’t work, at least not in the way that you would expect if it was written by hand. If you start using it, you will quickly find many problems with it.

Take yourself back to when you got your first computer and started writing code. That sense of wonder when “Hello World” appeared on your screen. That dizzying feeling that you could make this strange machine do whatever you told it to. Turns out that tapping into that old feeling is really helpful again. Experiencing that sense of wonder while messing with all these new AI tools and getting your hands dirty building stuff is a much better use of your time than having preconceived opinions about them.