Clean code in the age of coding agents

Clean code in the age of coding agents.

TL;DR: Keeping code clean helps both humans and agents.

I was thinking the other day how coding agents despite being very different from human developers, still share some similarities - their productivity is affected by the state of the codebase.

Robert Martin in Clean Architecture talks about code as having two properties: value (it works, it's fast, etc.) and structure (how code is organised).

While value is obvious for all the stakeholders, the structure is somewhat less clear.

Poor structure means it's harder to introduce new features, and bugs are going to multiply. Eventually it costs your company momentum and money. It's just not immediate. It's a long-term thing.

What makes clean code?

It has several characteristics (but also note how all of those are affected by each other).

Readability: any other developer can easily understand what's going on.Simplicity: it gets the job done as simply as possible (but not simpler).Modularity: sensible code splitting into modules whatever those might be (classes, functions, files, directories, or micro-services).Testability: writing tests is easy and fun.

Naturally, code is easy to change if it has these characteristics.

Clean code and LLMs

But hey, these days we don't need to care about the structure anymore, right? We have LLMs to do the work for us. We don't even need to read the code anymore - we can focus on testing the outcomes. We don't read the compiled binary code after all, do we?

Well, no.

Coding agents are limited by context (excuse me, dear future reader, I'm writing this from April 2026). Longer contexts mean degraded performance, the tokens will multiply - and so will the cost.

Context is basically how many things a machine can keep in its operational memory - it's not so different from the very human cognitive load.

As with humans, poorly organized code means agents need to read, "understand", and make changes to more files than necessary - polluting their context and costing you tokens.

If your code is properly organized, implementing a feature might require a model to read just a couple of small files, and make changes, instead of having to read dozens going around in circles.

Just like you and me.

So what are some practical steps?

I don't really have a silver bullet, but here are some things from my experience.

When you give a task to your agent, make sure you also explain how the code should be organized. Not only value, but also structure.

LLMs are pretty good at picking up the style in your repo. So keeping it clean and organized already helps.

Review the outcomes. I don't think we can skip this step for now. In my opinion, an agent does not care about the structure, unless you specifically ask it to. But even in this case you have to review the changes.