I'm Breaking Up With My Code

Remember when servers had a name, usually something mystical like "Zeus" or friendly, familiar names like "Bob".

Bob was a physical server and lived in a rack somewhere, crunching away quietly year after year, collecting a nice layer of dust. We patched him, upgraded him, and occasionally held our breath when he took a little too long to restart. Someone knew which manual changes had been made and which services needed a little more prodding.

Then virtualization, cloud infrastructure, and containers changed our relationship with the beloved machine. Alongside infrastructure as code, they made it practical to build a replacement from a known definition and retire (or, to continue the personification, "kill off") the old instance, a little like the ending of Old Yeller. Our trustworthy friend had become another disposable resource we could spin up or down at our every whim and fancy.

So with all the latest headlines around AI development, especially the slightly unsettling prospect of developers no longer understanding the code they ship, I keep wondering whether our code could be headed for a similar fate.

When I mention this to my fellow engineers, the reaction is usually some variation of "wwwhat? You can't just throw away the entire codebase and start over every time you need to do something," while longingly looking at the code they spent six months nurturing (yes, I can attest the emotional attachment is very real).

And yes, well... potentially, we could. If we can describe what a system needs to do and reliably check that it does it, could starting over actually become cheaper than maintaining the version we already have?

That leaves us with the more interesting question of what we would need to preserve for this to work. Could we take a page out of Docker's book and find a way to "image" the layers of requirements, context, and decisions that went into the code?

What made "Bob" replaceable?

As we kept pushing to deliver changes faster, we needed more than virtualization. Repeatable builds, configuration management, health checks, and somewhere for the data to live all helped us replace Bob without losing what he was doing.

With immutable infrastructure, we change the definition, build a new image, and replace the running instance. HashiCorp describes the approach here. We could finally retire Bob because the knowledge needed to recreate his environment no longer lived exclusively inside him (or inside the head of the one person who knew how to fix him).

For code, we'd need to do something similar. The requirements, business rules, interfaces, architectural decisions, and checks that tell us it all works would have to survive whatever we were about to throw away.

We already replace application binaries and container images all the time. The bigger leap would be treating the source code itself as something we generate from the things we actually want to preserve.

Are we already moving up the abstraction ladder?

This is already showing up in how engineering teams describe their work.

In July 2026, Coinbase wrote about its engineers spending most of their time writing specifications, directing AI, reviewing its work, and making architectural and operational decisions. Humans still review the code, but much less of their day goes into writing it from scratch.

What happens, though, if reviewing gradually becomes a substitute for understanding how everything fits together? Would someone still be able to get in there and make a hotfix without AI support (say, if the provider goes down for a few hours on a Friday, shortly after that critical deployment)?

There is some evidence behind this concern. In a randomized study involving 52 mostly junior engineers, Anthropic found that those using AI assistance learned less about an unfamiliar Python library, including how to read the code and debug it. Those who asked questions and used AI to build their understanding retained more knowledge, so there is some hope.

This was a specific learning exercise, so I wouldn't take it as proof that we're all forgetting how to do our jobs. But it does show that writing working code and learning enough to maintain it can drift apart over time.

If teams can generate software faster than they build a shared understanding of it, what happens when that software needs to change?

The maintenance problem doesn't disappear

Nobody fully understands every line of a large codebase today either. We get by because someone owns the service, the patterns look familiar, there are hopefully some good tests, and we know where to start looking when something breaks.

AI can help us investigate unfamiliar code and suggest a change, but someone still needs to check whether the explanation makes sense for the business. Otherwise, we can end up very confidently changing something we don't actually understand.

And then there's all the knowledge that never made it into a specification. That odd-looking condition might be there because a payment provider retries requests in a peculiar way. The field nobody seems to use might be keeping a customer's legacy integration alive. A rounding rule might be leftover from a production incident three years ago.

Start over without any of that context and we might get a nice clean codebase that produces the wrong results.

The risk is that we keep generating more code, while remembering less about why it works the way it does, then spend more time piecing that history back together every time we need to change something.

Would starting over actually be cheaper?

Rewrites have traditionally been expensive because people spend months rebuilding functionality they already have (usually while keeping the old version running too). If AI takes enough of that work off our hands, the calculation could look rather different.

Take a small service with a clear API, well-understood business rules, good acceptance tests, and data stored somewhere we can leave alone. We update the requirements, generate a replacement, check that it behaves as expected, and roll it out. Does it really matter if the code takes a different route to get there?

Now try the same thing with an accounting system carrying years of historical corrections, regulatory decisions, and customer expectations that nobody thought to write down. Generating the code is now the easy part, but figuring out whether we've accidentally lost something important could eat up every hour we thought we'd saved.

I'd expect this to become practical first with smaller pieces we can get our heads around: an internal tool, an integration adapter, or a service with a clear contract. The entire codebase could follow, provided we had that same confidence about its behavior at a much larger scale.

And, of course, AI keeps getting better at looking after the code we already have too. Spotify describes its work with automated maintenance and coding agents here, including more than 2.5 million automated maintenance pull requests. We need to compare the cost of starting over with what maintaining the existing version actually costs us with AI in the picture.

And who's paying the token bill?

Generating code isn't free, however effortless it looks while we watch the terminal scroll by. There's human time, AI usage, test infrastructure, and the cost of finding out we got something wrong after we've shipped it.

Let's put some deliberately simple numbers around it, using an engineering cost of €100 an hour:

• We make an incremental change, spending six engineering hours on the work, review, and rollout, plus €20 on AI: €620.

• We generate a replacement, spending two engineering hours on verification and rollout, plus €120 on AI: €320.

• We then discover the replacement needs another four hours to check equivalent behavior or migrate the data: €720.

These are made-up figures, but they show why a bigger token bill might be reasonable if it saves enough human time. They also show how quickly the saving disappears when checking the result or moving the data takes longer than we expected.

Someone also has to capture the requirements and build tests we can trust. That effort could pay for itself over many future replacements, but we still have to find the time and money to do it.

A growing AI bill doesn't necessarily mean the price per token is going up either. In September 2026, Anthropic reported that context per request had grown 2.6 times over six months, while announcing lower token prices. We can get a better price and still spend more because our agents are reading more, making more calls, and working for longer.

With either approach, we're paying for the agent to read the context, write or edit the code, run tools, check the result, and have another go when it gets stuck. The model, caching, number of agents, and how often we start the exercise again will all show up on the bill.

So what would we be maintaining instead?

The specifications would need considerably more attention than the document we wrote at kickoff and haven't opened since. API contracts, business rules, security boundaries, performance expectations, and lessons from production would all need to stay current as we replace the code underneath them.

There are already tools exploring pieces of this. GitHub's Spec Kit gives teams a process for taking specifications through planning and implementation with a coding agent (SDD = Spec Driven Development.) It doesn't mean we can hand over a vague description of a production system and expect a faithful replacement, but it gives us somewhere to start experimenting.

The tests deserve some healthy suspicion too. An agent can write the code and then helpfully write tests that confirm the same misunderstanding. We still need business knowledge, independently checked examples, integration contracts, and evidence from real use to tell us whether it got the right answer.

We'd also need to check what happens when something fails, who can access what, how fast it runs, and whether existing integrations still work. A green unit test suite is reassuring, but I wouldn't bet an accounting system on that alone.

And we can't quite treat generation like a compiler because it isn't deterministic; the same specification can produce different implementations, so we'd still need to keep the exact source, dependencies, build artifacts, and validation results for whatever we ship. When something breaks, we need to know what's running and have a version we can go back to.

Where does that leave engineers?

In Would I Hire Me Today?, I argued that understanding and evaluating code deserves more attention as AI writes more of it. I still think that holds, especially in higher risk products.

At the same time, I can imagine us becoming a little less attached to a particular implementation once we're better at preserving what it needs to do. That's part of what I was getting at with the context repository in The Full-Context Technologist: making business meaning and operational knowledge available beyond the people who happen to remember it.

My bet is that some code will become disposable before we're entirely comfortable calling it that. We'll start with the systems whose behavior we can describe and check with confidence, and see whether the economics justify going further.

We stopped worrying quite so much about losing our dear friend Bob once we knew how to recreate what he did. I wonder how much of our attachment to a codebase will survive when we can say the same about it.