What is "Good" Code in the Age of Agents?

At a work offsite in mid-2023 I gave a talk to the engineering team about how AI was already changing coding. I advised that, like all change in the industry before it, there was no reason to be afraid, but you need to stay on the board and ride the wave or you are going to get left behind.

Last year was insane. Even without model improvements, just the growth in our understanding of agentic workflows pushed us faster than I could have believed. We are so beyond tab completions. Now, on Jan 1, 2026, I am more bullish than ever.

At heart I am a software craftsman. I care deeply about the flow and poetry of my code. I care about design patterns. I care about testing, and pair programming. This can sometimes present a level of cognitive dissonance when surrendering to the machine.

AI doesn't do it the way I would have done it (sometimes for the better, usually worse.) Fortunately I've had some experience letting go, as I've spent years in more senior leadership and technical positions, where you need to let go of certain levels of design decisions so that the people who will be maintaining the code are the ones who choose how to design it. You can offer guidance, and occasionally make demands – but aligning the incentive loops for people with the most skin in the game will lead to the best teams and software. Engineers start to care a lot more about code quality when they are on-call and feel ownership.

So, delegating to another intelligence doesn't feel so dramatic to me. I keep the same sort of checkpoints with it for now as I would any engineer on my team—I give it direction and then I review it at different intervals, dependent on the complexity of the task and my intuition about the agent's relative capabilities.

What can feel dramatic to me is an idea I see thrown around online quite a bit, that clean code doesn't matter anymore. I can't get behind this... but also I recognize something is shifting.

The basic argument goes like this: in a world where an AI agent can one-shot any prompt you have and make no mistakes, the old adage of "never rewrite your code" and need for thoughtful careful refactoring goes out the window. Because now you can truly just rewrite the whole thing from scratch. So, if you can just trivially rewrite the whole thing with no risk, you don't need design patterns or legible code in the same way we moved from assembly to compilers (almost never) need to read machine code anymore.

Talking about "clean code" has always been tricky, because no one really can agree on what it is. It's always been a vibe. If Kent Beck and Martin Fowler coined "code smells" today it probably would have been called "bad code vibes." Clean code is often an ethereal sense of taste.

My favorite and most useful definition of clean code comes from David Thomas in the 20th anniversary edition of The Pragmatic Programmer: good code is code that is easy to change. It doesn't completely remove the vibes, but it gets down to first principles about it in a way that my brain screams "YES" to. Good design patterns have always been about making code easier to change—because especially in software—the only constant is change.

Thinking about the future of code in terms of how easy code becomes to change helps me think about the future of design patterns. Now when I say "design patterns" – I don't mean just OOP, gang of five college text book patterns. I mean generally any good patterns you find naturally emerging and repeating. Breaking down files, classes, large functions into smaller chunks. Organizing and managing dependencies to all point inwards and avoid cycles (e.g. DDD, onion, and hexagonal architectures).

AI won't change the fundamental laws of physics. I feel there are similar principles at the heart of design that won't change, even if it comes up with new ways to apply them. Maybe AI can invent new ways of space travel one day, but it won't eliminate the first law of thermodynamics.

It's hard to know exactly what these principles of software design are that won't change. But I am pretty confident principles like Coupling and Cohesion will always be important in software systems. Maybe SOLID won't. I have a feeling decomposition, abstraction, will always be important. Just like they help humans manage context, agents will need to be able to manage context as they work in large systems and relying on higher levels of abstraction will be critical to make changes well. Maybe that means principles like Single-Level of Abstraction will remain important. Architectures like Model View Controller may stay useful, because they will help agents be able to define thin vertical slices where they can complete end to end tasks while managing context.

Anyway, just a quick start of the year post. I'm hoping to write a lot more this year. Not in a new years resolutions sort of way, just in a been meaning to for a while but never do it because I start planning and organizing my posts. Vs Twitter where I stream-of-consciousness vomit and never have a problem publishing my thoughts. So here it is, no editing, just hitting Publish. Happy New Year!