Write Human Maintainable Code in the Age of AI Agents

To lay things out on the table, this isn’t an “AI Bad, Humans Good” blog post. No-code tools have made it easier for non-developers to prototype basic apps, and coding agents have made it quicker for developers to get the first pass of a feature written.

Agentic development hasn’t made writing human-maintainable code any easier. “Maintainable” means software projects that are easily understood, modified, and extended by future developers without concerns of introducing new bugs.

A naive thought is, “Why should we care if the flesh-bags can’t maintain the code?” The agents wrote it, so obviously they “know” how to update a feature from eight months ago that a stakeholder requested be changed dramatically.

The only problem is that there have been five other similar features added since then. They all need the same change, but each one was implemented in a slightly different way, with duplicated helpers scattered everywhere.

The agent can help clean that up. The problem is that the mess still exists.

Agents Write Code That Looks Like Code

AI coding tools are very good at generating an output that feels complete. At a glance all of the code will look elegant and the tests pass.

That is the dangerous part.

The anti-pattern I worry about most is when a change works today, while making updates tomorrow or three months from now far more difficult. This has always been a problem in software development. Agents just let us create more of it in less time.

There are guardrails that help. Spec-driven development can give the agent a clearer target. In-editor review flows can slow things down before changes are accepted. Smaller prompts can keep the agent from wandering through 50 files. These guardrails are useful, but they still depend on the developer implementing the code understanding the changes.

Review the Agent Like a Junior Dev

The best mental model I have found is treating working with an agent like pair programming with a hyper technical, but chronically short term thinking junior. The agent can drive, but the developer still needs to navigate.

Before opening a pull request, I should be able to explain what changed and why. That does not mean I need to explain every generated line of code, but justifying why every change is present is a must. A fail state for agentic development is when I hear someone say “the robot did it”.

AI-generated code can sound confident in the same way AI-generated writing can sound confident. It often follows the local pattern and naming style well enough to pass a quick review, that does not mean it picked the right abstraction. The developer has to make that call.

Keep the Changes Small

The easiest way to lose control of an agent is to give it a vague feature request and accept the full result without a second or third thought. Reviewing AI-written code is exhausting, particularly because of how good the outputs look. You’re looking for a needle in a haystack while reviewing a one-shot solution for a complex feature.

Small iterative changes make review possible. Small changes also make it easier to catch when the agent solved the wrong problem or introduced a bug. Keeping pull requests under 100 or 200 meaningful lines changed is a goal that feels like it has gone out of favor in the last couple of years, but small pull requests make it easier for a team to provide useful feedback.

The Token Cost Matters

It is worth acknowledging the rising cost of agentic tools when considering the importance of maintainable code.

Right now, software development is in a state where using AI is not free, but is relatively cheap for the amount of work that can get done using compared to the amount of work that can be produced. There is no promise that token costs will stay the same. The better agents get, the more tokens they can chew through in a very short amount of time.

That matters in consulting. When we deliver software to client, we are delivering more than the product. We are also delivering a codebase the client’s developers need to maintain after the engagement ends. Those client devs should not be expected to need to use AI agents to perform simple maintenance.

If the code can only be modified safely by the original developer with the original agent setup, then the delivery is weaker than it looked.

Final Word

AI agents are going to keep getting better at writing maintainable code. That is good. They reduce boilerplate, speed up exploration, and make the first draft of a feature much faster.

The responsibility stays with the developer accepting the diff.

Conversation

Join the conversation

Your email address will not be published. Required fields are marked *