# Clean Code in the Age of Coding Agents

A short yanist.com post making one point: clean code isn't less important when you're working with coding agents, it's more important. The argument is that LLM context windows are the machine equivalent of human cognitive load, so the same organizational principles that help a human navigate a codebase also help an agent. Messy code forces the agent to read more files than it needs, burning context space on irrelevant code and wasting tokens on orientation instead of output.

The framing draws on Robert Martin's *Clean Architecture* split between code's value (does it do the right thing) and its structure (is it organized so you can change it later). Value is easy to see — the feature works or it doesn't. Structure is harder to notice and its costs compound: each poorly organized module makes the next feature slightly harder to add, and each patch on top of a messy abstraction makes bugs slightly more likely. Martin made this argument for human teams; the post extends it to agent-assisted development by noting that agents suffer from the same structural costs, just expressed as context pollution rather than developer confusion.

The practical advice is thin but concrete: tell the agent how you want code organized, not just what you want it to do. Maintain consistent style across the repo so the agent picks up conventions from context rather than needing them spelled out every time. Review agent output for structure, not just correctness — agents default to generating code that works, not code that's organized.

This is the constructive complement to several other pieces in the wiki. [[cult-of-vibe-coding]] argues you should read the code yourself (Cohen's audit-discuss-execute loop). [[no-silver-bullet-llms]] argues the bottleneck is design and specification, not code generation speed. [[building-syntaqlite-ai]] documents what happens when you delegate design to the agent and lose your mental model. This post is gentler — it doesn't argue against using agents, just that the humans using them still own the structural decisions. The agent generates the code; you maintain the architecture. That division of labor only works if the architecture is clean enough for the agent to navigate efficiently.

[[bryan-cantrill|Bryan Cantrill]]'s [[peril-of-laziness-lost|"The Peril of Laziness Lost"]] supplies the deeper reason why agents default to mess: work costs them nothing, so they have no drive to simplify. The "virtuous laziness" of human time constraints is what produces the clean code this post advocates maintaining.

The piece is lightweight — it states the argument without evidence or case studies. But the core observation (context windows are finite → structure determines how much useful work fits in a single context) is correct and connects the "clean code" tradition to the LLM-agent world in a way that the original Martin/Fowler writing obviously couldn't.

For one published architectural pattern that explicitly markets itself on this premise, see [[porto-sap]] — its current README leads with the claim that single-responsibility classes-per-file make codebases more Copilot-friendly, which is this post's argument turned into a folder convention.