Tending

Tending is the long-term practice of maintaining a codebase through both growth and reduction — planting what’s needed, pruning what’s not, and accepting that pruning is an act of love, not destruction.

The software industry has words for growth: building, shipping, iterating, scaling. The software industry does not have a word for the deliberate, routine, unglamorous act of making a codebase smaller while making it more capable. The gardening world has had this word for ten thousand years. It is tending.

A garden that is only planted becomes a jungle. A garden that is only pruned becomes barren. A garden that is tended — planted and pruned in rhythm, by someone who knows which vines bear fruit and which ones choke — produces more than either extreme. The same is true of codebases, but nobody says so, because “I spent Tuesday deleting working code” does not fit on a roadmap slide.

“The commit deleted more than it wrote. The codebase has more features now. I cannot explain this to a committee.”
— riclib, after a pruning season

The Three Roles

Tending requires three roles. In a solo project, one person plays all three. In an enterprise, the roles are distributed across teams that rarely speak to each other. In most organisations, the third role does not exist.

The Planter — dreams, explores, adds features, scouts the territory. This is The Caffeinated Squirrel. The planter’s instinct is growth. Given an empty backlog, the planter fills it. Given a working system, the planter imagines seventeen improvements. The planter is not wrong — the improvements would improve things. The planter is necessary. Without the planter, the garden has nothing in it.

The Pruner — finds the essential, removes the rest. This is The Lizard. The pruner’s instinct is reduction. Given 827 lines, the pruner finds the six that matter. Given a cathedral, the pruner finds the napkin inside it. The pruner is not unkind — deletion is precision, not destruction. The pruner is necessary. Without the pruner, the garden chokes.

The Tender — holds the space for both. This is riclib, or any developer who has the authority, the love, and the time to both grow and shrink a codebase. The tender decides when to plant and when to prune. The tender knows that three months of growth need a week of pruning. The tender knows that a feature that was reasonable in December may be obsolete in March. The tender knows that deleting working code requires the same courage as writing new code, and more taste.

THE SQUIRREL PLANTS
THE LIZARD PRUNES
THE TENDER DECIDES THE SEASON

WITHOUT THE SQUIRREL
NOTHING GROWS

WITHOUT THE LIZARD
NOTHING BREATHES

WITHOUT THE TENDER
NOTHING LASTS

— The Lizard, acknowledging the Squirrel for the second time in recorded history

The Pruning Season

A pruning season is not a refactoring sprint. A refactoring sprint improves the code that exists. A pruning season deletes the code that shouldn’t exist anymore.

The distinction matters. Refactoring makes bad code good. Pruning makes good code gone. The code being deleted is not bad — it works, it’s tested, it has users. It is simply no longer the best way to solve the problem it solves. Something has changed — a new pattern emerged, a domain was superseded, a convention made the old approach unnecessary — and the working code is now weight.

The field example: March 2026. Nineteen commits. A reports domain deleted (5,242 lines — working code, tested, documented, superseded by the LLM). Eleven domains migrated from field-level NATS drafts to form-based validation (thousands of lines deleted, replaced by simpler patterns). A push-based context system replaced by a pull-based convention that already existed (-5 net lines).

Lines inserted:   +6,633
Lines deleted:    -13,022
Net:              -6,389
Features gained:  content editors, LLM context, dual-audience forms
Features lost:    0

The codebase got smaller and gained features. This is not a paradox. This is tending.

Why Enterprise Systems Can’t Tend

Enterprise systems cannot be tended because tending requires three things that enterprise organisations structurally lack:

1. Authority to delete. In an enterprise, every feature has a constituency. Deleting a feature disappoints a constituency. Disappointing a constituency requires approval from the constituency’s stakeholder, who will not approve the deletion of their own feature. The delete key exists. The permission to use it does not.

2. Love for the codebase. Tending requires someone who cares about the codebase as a whole — not one module, not one team’s slice, the whole thing. Enterprise developers maintain their corner. Nobody maintains the garden. The weeds between the corners grow unchecked because they belong to nobody’s roadmap.

3. Time to prune. Enterprise roadmaps contain only planting. Q1: plant features A, B, C. Q2: plant features D, E, F. Q3: plant features G, H, I. Q4: wonder why the build takes forty minutes. There is no sprint for “delete the thing we built in Q1 that turned out to be unnecessary.” There is no ticket type for “the LLM made this domain obsolete.” The roadmap only grows. The garden only grows. The jungle consumes the cathedral.

The solo developer has all three: the authority (the only constituency is themselves), the love (they built it, they live in it), and the time (nobody is scheduling their sprints). This is why solo projects rarely reach Critical Mass and enterprise projects always do.

“I deleted a domain today. Twenty-two files. Five thousand lines. It was working code. Nobody asked me to delete it. I deleted it because the LLM does what it did, better, and the code was weight. Try explaining that in a sprint retrospective.”
— riclib

Tending with LLMs

LLMs turbo-charge the Squirrel. Four thousand lines in a day. Features that would have taken a sprint ship in an afternoon. The growth pressure is 100x.

This makes tending not optional but existential. Without tending, an LLM-assisted codebase reaches critical mass in months instead of years. The growth is too fast. The weight accumulates too quickly. The conventions from three months ago become obsolete but nobody deletes the code that used them.

The tender’s job with an LLM is the same as without one, just faster:

• After a growth phase, prune. The LLM wrote four thousand lines. Which of those lines are scaffold? Which patterns emerged that make older patterns obsolete? What can be deleted?
• After a convention emerges, propagate. A six-line convention was written for sidebar modes. It now carries LLM context. Eleven call sites updated. The old push-based system deleted. The convention replaced the code.
• After a domain is superseded, delete it. The reports domain was working. The LLM does what it did. Delete the domain. The codebase loses 5,242 lines and gains nothing except lightness, which is the most valuable thing a codebase can gain.

The LLM cannot tend. The LLM can prune when told to — “delete this, migrate that, remove the old pattern” — but the LLM cannot decide what to prune. The LLM does not know which code is weight. The LLM does not feel the garden getting heavy. The decision to prune is the tender’s. The execution is the LLM’s.

This is the collaboration: the tender says “this is weight,” and the machine makes it gone in an afternoon. The cost of pruning has dropped 100x. The frequency of pruning should rise to match.

The Domestic Parallel

riclib tends a garden in Riga. The garden has herbs, tomatoes, and a tendency to be invaded by the neighbours’ mint, which is what happens when you plant mint near a fence and assume the fence will contain it. (The fence does not contain it. Mint recognises no borders. Mint is Zawinski’s Law with roots.)

The garden requires tending. Not planning — tending. You don’t schedule a sprint to remove the mint. You walk out on Tuesday morning, see the mint has crossed the border again, and pull it. You don’t file a ticket. You don’t get stakeholder approval. You don’t convene a Mint Removal Advisory Board. You pull the mint because the mint is weight, and you love the garden, and the tomatoes need the space.

The codebase is the same. Walk through it. See the mint. Pull it.

Measured Characteristics

Roles required:                           3 (planter, pruner, tender)
Roles present in enterprise teams:        1 (planter)
Roles present in solo projects:           3 (same person)

Pruning seasons in typical enterprise:    0 per year
Pruning seasons in tended codebase:       2-4 per year
  (after each growth phase)

The March 2026 pruning:
  Commits:                                19
  Net lines:                              -6,389
  Features gained:                        more than before
  Sprint retrospective explanation:       impossible
  Committee approval required:            0 (solo developer)

Time to prune a domain (with LLM):        1 afternoon
Time to prune a domain (enterprise):      3 sprints + 2 committees
                                          + 1 architecture review
                                          + 1 stakeholder who left
                                            but whose feature remains

Mint containment:
  Fences that stop mint:                  0
  Mint that respects borders:             0
  Correct mint strategy:                  pull on Tuesday
  Enterprise mint strategy:               Mint Removal Advisory Board
                                          (meets quarterly, has not yet
                                          approved a removal)

See Also

• Critical Mass — What happens without tending
• YAGNI — The principle. Tending is the practice.
• The Caffeinated Squirrel — The planter. Dreams the cathedral. Contains the napkin.
• The Lizard — The pruner. Finds the napkin. Ships six lines.
• riclib — The tender. Holds the space. Pulls the mint.
• Solo Developer — The only role with delete privileges
• Zawinski’s Law — Mint with a software licence
• Coding with LLMs Map of Content — Layer 4 in the stack