Code Readability

I appreciate and value those moments when I realize that I need to change my mind about something.

For the longest time, I believed — and promoted — the idea that code needs to be readable.

Why? Because as PEP 8 puts it, “Code is read much more often than it is written.” And there’s also the old programming joke, often credited to John Woods, about whoever ends up reading and maintaining your code: “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”

I don’t think this is true any more. At least not in the same way I used to mean it.

With the rise of AI coding agents, software doesn’t need to be optimized for humans to read cold. Human-readability is quickly becoming optional.

Here’s my updated belief:

Software doesn’t need to be readable by humans any more. It needs to be understandable and interrogable by humans on demand, and verifiable by machines.

An obvious pushback against this would be: “Wait, are you suggesting that it’s okay to have black boxes in production?”

No.

I am definitely not arguing that it’s okay for production code to be indecipherable or opaque to humans.

We still want the system to be observable, testable, auditable, and explainable on demand. What is changing is how we achieve a level of understanding that makes a system trustworthy. Historically, one of the main ways to understand software was to read the source code line by line. Now, we can ask an agent to trace a behavior, explain a dependency, identify where a value came from, generate tests, inspect a failure path, or tell us what would break if we changed something.

The important shift is:

Before: readability as a prerequisite for understanding.

Now: interrogability as the interface for understanding.

Then: read code. Now: interrogate code.

Readability is still useful. It’s just no longer sacred.

Related Posts