Skip to content
Published on

When an AI Maintains Your Code, Write for Humans Anyway

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Share
Authors

Introduction — An Old Maxim, Rewritten for the Agent Era

"Write code like a human will maintain it" is one of the oldest pieces of advice in software. The reasoning was always simple: you write a line once, but it gets read dozens of times, so you optimize for the reader rather than the writer.

Clever one-liners, saved keystrokes, and machine-friendly tricks all lose to plain, boring, obvious code that the next person can understand at a glance. For decades that "next person" was unambiguously a person.

On July 10, 2026, Scott Robinson published a short essay under exactly that title, and it climbed the front pages because it takes the old line somewhere new. His argument is not the usual nostalgia for craftsmanship.

It is about what happens to that advice when the "next maintainer" is a large language model. And it resonates precisely because so many of us now let an agent write and edit most of the code we ship, which makes the question feel urgent rather than sentimental.

What the Essay Actually Argues

Robinson opens with the tempting rationalization, stated ironically: "One of the best things about LLMs is that they'll write code for you, all day long. Who cares about DRY?"

If the AI will happily update the same long conditional in four files for you, why bother extracting a shared helper? As he puts it: "When I need to change something later, the LLM deals with it, not me."

His concrete example is an access check that had to live in a route handler, a background job, an API endpoint, and a webhook. Instead of writing one shared helper, he let the model paste a near-identical copy into each place:

if (user.isActive && user.hasPermission('read') &&
    !user.isSuspended && account.status === 'open') {
    // do a thing
}

Then comes the turn that makes the essay worth reading. The LLM does not work in isolation; it reads your existing code and treats it as the style guide. In Robinson's words: "Every shortcut you merge into your codebase is a signal about how things are done here."

So the duplicated conditional is not merely tech debt you will pay down later. It is training data you are feeding the model right now. It sees four copies, concludes that duplication is the local convention, and dutifully produces a fifth and a sixth.

The smell compounds, and once the pattern is entrenched it is harder to undo, because the model keeps regenerating it from the examples around it. Robinson's closing line lands the point: "LLMs are sponges that soak up everything you do and repeat it back to you. So make sure it's good."

Does the Rule Still Hold When a Machine Maintains the Code?

This is the honest question, and I think the answer is yes — but for a sharper reason than "clean code is virtuous."

Start with the fact that the maintainer is never only the machine. Someone still has to review the diff, and review is now the real bottleneck: an agent produces code far faster than any human can vet it.

Readable code is reviewable code. Clear names and small functions are what let a reviewer confirm intent in seconds, instead of reverse-engineering a wall of cleverness at 2 a.m. during an incident. Optimizing for the human reader was never about the writer's comfort; it was about the reviewer's, and that reviewer has not gone anywhere.

Robinson's own point then cuts one layer deeper than DRY. Because the AI mirrors what it reads, your repository has quietly become a prompt you are writing continuously. A consistent, well-factored codebase steers the next generation of output toward good; a messy one launders its own mess back at you, at machine scale.

Practitioners in the discussion around the essay noticed a related decay: across many iterations, the model's grasp of the code and the code's own conciseness both erode, and output quality drops with them. The failure mode is not one bad function; it is the model amplifying your worst habits across hundreds of files.

Where I would push back on a lazy reading of "write for humans": it is not a license to hand-polish everything to taste. The same discussion was blunt that negative instructions and long style checklists can actually degrade an agent's performance.

Deterministic guardrails — linters, formatters, type checkers, static analysis — enforce consistency far more reliably than prose in a prompt ever will. "Write for humans" and "let tools enforce it" are the same project, not rivals.

The Practices That Still Earn Their Keep

None of the classics have been repealed. If anything, the agent era raises their return, because every pattern you keep is a pattern that gets copied forward.

  • Clear naming is the highest-leverage habit of all. A name is the compressed intent of a block of code, and it is the first thing both a human reviewer and a model use to guess what something does.
  • Small, single-purpose functions stay easy to read, easy to test, and easy for an agent to reuse instead of re-inventing a slightly different variant next door.
  • Comments that explain why, not what. The code already states what it does; a good comment captures why the obvious approach was rejected — context no reader, human or machine, can recover from syntax alone.
  • DRY, but only where it removes a real source of divergence. Robinson's example is the canonical good case: one access rule, changed in one place, correct everywhere.
  • Let deterministic tools carry the boring consistency. They never tire, never argue, and hand the agent an unambiguous target to conform to.

The honest caveat is that DRY is not free, and "write for humans" does not mean abstract at every opportunity. Premature abstraction is its own maintenance burden, and forcing two unrelated pieces of code to share a helper is worse than a little honest duplication.

The judgment call — is this genuinely the same rule, or two rules that merely look alike today — is exactly the kind of intent work that remains ours, not the model's. That judgment is the part of writing for humans that no sponge can soak up.

Closing

The advice to write code like a human will maintain it survives the arrival of AI agents, but its center of gravity shifts. It used to be about some future human squinting at your code months from now.

Now it is also about the model reading your repository this afternoon and deciding what "normal" looks like around here. Both audiences reward the same things: clarity, consistent structure, and intent you can recover without a debugger.

The machine did not retire the maxim. It just gave us a faster, and far less forgiving, way to find out whether we ever meant it.

References

Discuss on Twitter • View on GitHub