There's a popular take doing the rounds: code is free now. The model writes it in seconds, it costs pennies, so why be stingy? Generate, try it, throw it away, generate again. Who cares about a few extra files?
I've been writing code for two decades and I can tell you the one thing this argument gets wrong: it was never about the cost of writing code. The writing was never the expensive part. The expensive part has always been everything that comes after.
Code was always a liability
The asset isn't the code. The asset is what the code does - the working software, the solved problem, the running business. Code is how we pay for that asset. And like all debt, it comes with interest:
- every line has to be read before anyone can safely change anything around it
- every line has to be understood by the next person (or agent) that touches the file
- every line is a place where a bug can live
- every line is context someone must load into their head - or into a context window
- every line will eventually be wrong, and correcting it costs time
You can't delete the code and keep the software. So the code itself is pure liability: you carry it forever, and you only ever hope to keep the interest payments small.
This isn't a new insight. Fred Brooks was writing about software entropy in 1975. The "big ball of mud" pattern was named in the late 90s. Every generation of tools that made writing code cheaper - higher-level languages, frameworks, copy-paste from Stack Overflow, scaffolding CLIs - was greeted with the same cheerful claim ("now code is basically free!") and produced the same outcome: systems that fell over under their own weight a bit faster than the last generation's.
The tools changed. The physics didn't.
What gardening actually means
Code gardening is the unglamorous, never-in-the-sprint, absolutely-load-bearing work of keeping a codebase alive:
- Pruning - deleting dead code, unused flags, commented-out relics, "we might need this later" branches. Later came. It didn't need it.
- Weeding - fixing the duplication before it becomes an identity. Two copies of a function is a coincidence; three is architecture.
- Reshaping - renaming, extracting, inlining, moving files so the structure still reflects what the system does. Naming is the cheapest documentation you will ever write.
- Tending the soil - updating dependencies, tightening types, keeping the build fast, keeping tests meaningful. Nobody notices healthy soil. Everybody notices a dead garden.
- Planting deliberately - small modules, clear seams, fewer places where a change has to ripple through ten files.
None of this produces a demo. All of it decides whether the system is still changeable in two years.
Why AI changes the rate, not the rule
Here's the actual difference the AI era makes, and it's not what the vibe coders think.
AI didn't make code free. It made code generation faster. Which means:
- Debt accumulates faster. A team of humans used to generate maybe a few hundred lines of half-understood code per day. A team with agents generates thousands. Same maintenance cost per line, but the production rate just went up 10x. Your big ball of mud doesn't take five years to arrive anymore. It takes five months.
- Reading didn't get cheaper - it got more expensive. Every line of generated code still has to be understood by someone before it can be trusted. Now that someone is often you, reviewing a 40-file diff that took the agent 4 minutes to produce and takes you 2 hours to read. The bottleneck moved from writing to reading, and gardening is what keeps reading feasible.
- Agents drown in mud faster than humans do. A big ball of mud degrades AI performance directly. Agents work by searching, reading, and reasoning over the codebase. Every dead file is a wrong search hit. Every duplicated helper is a coin flip over which copy to edit. Every vague name is a wrong guess that compiles. Gardening used to be kindness to your future colleagues. It's now kindness to your agents, who are only as good as the terrain you let them walk on.
- The discardable prototype was always fine. "Generate, throw away, regenerate" was never a problem - a throwaway has no maintenance cost because it gets thrown away. The problem is that most of what AI generates is not thrown away. It gets merged, deployed, and forgotten until it breaks. A throwaway you keep is not a throwaway. It's a liability with no owner.
The economics, stated plainly
If generation gets 10x cheaper and every generated line still carries its full lifetime maintenance cost, then the total cost of a system is increasingly dominated by maintenance - reading, understanding, changing, deleting. Which is exactly the part gardening controls.
So the return on gardening went up, not down:
- a deleted dead line now saves both a human and every future agent that searches past it
- a clarified name now steers both reviewers and code generators
- a removed duplication now halves the blast radius of both human edits and agent edits
In the pre-AI era, ignoring gardening meant your codebase decayed at human speed. Now it decays at generation speed. That is the only difference. The direction of the argument is unchanged; the slope got steeper.
What I'd actually do
- Make deletion a first-class activity. Budget time for it. PRs that delete hundreds of lines should get the same praise as PRs that add them - more, actually.
- Treat generated code like junior-dev code. Fine to produce quickly, but it goes through the same review, the same naming standards, the same tests before it's part of the garden.
- Keep the prototype pipeline honest. Everything not meant for production lives somewhere clearly throwaway, and gets thrown away.
- Garden continuously, not quarterly. Small, constant pruning beats an annual "cleanup sprint" that never happens. The faster the growth, the more frequent the trimming.
- Optimize for the reader, not the writer. Every time you're choosing between "quick to generate" and "easy to understand later," remember which one you'll still be paying for in a year.
The point
"Code is free" is a claim about the price of typing. Software was never expensive because of typing. It was expensive because of everything the typing leaves behind: the reading, the understanding, the bugs, the coupling, the fear of touching the wrong file.
AI makes the typing cheaper. It does nothing about the leaving-behind. That part is still on us - and it always was.
So yes: code gardening is now more important than ever. Not because gardening changed, but because the weeds grow faster.
