Which code still needs human eyes?

Two recent commentaries argue that humans still have to look at code: Valentina Servile’s Should we still design code for humans? on the Thoughtworks blog, and the AI Engineer talk Why Software Factories Fail.

The claim “we do have to look at code” is reductive to the point of being harmful because it also communicates “you can’t change, you have to wait for more power from these tools in the future, and vibe coding—well, vibing is in a totally different category.” My take is different:

We need to explore and push on which new abstraction layers we can successfully and durably put in place. And for that, it is important to be more nuanced: Not all codebases are created equal (and personal projects vs. work projects is not the only distinction).

It’s a spectrum, not an either-or#

At work, I see many different kinds of codebases. In some of them, the share of the code any human actually knows is almost 0%. That is totally fine. But those codebases are different from the others.

I think three things decide where a codebase sits:

1. Its size.
2. The complexity of its domain.
3. How observable that complexity is.

If all three are large—a big system, a complex domain, and complexity you can’t observe from the outside—you are most likely still going to need to look at the code. If all three are low, you don’t. The specification is a full representation of the system’s behavior, or as close to one as you need.

Miikka Holkeri makes a similar case for code review at Swarmia: not every change deserves the same scrutiny. His axis is risk; mine is how much of the system a human needs to understand at all.

Modularity creates more chances#

This is where the question connects to service-oriented architecture, microservices, and modularity.

The more places in an application where you can apply the same analysis, the more chances you have of finding a system or subsystem whose internals nobody needs to know anymore. That’s how I have always viewed modularizing Rails applications and moving them from monoliths toward well-modularized services.

Today, that matters even more—and not only for that reason. Much of the conversation is about how to make code reviews work well. There is an even bigger speedup: not doing them.

Design for it#

Treat “do humans need to know this code?” as a spectrum, and as an outcome of system design—which, to my mind and for the moment, is very much still a human activity—and we put ourselves back in control.

At the very least, we build the optionality. And we create persistent feedback loops that let us explore how well this actually works for a specific app, in a specific context.