The Best Code Is the Code You Never Wrote
There is a habit I keep catching in code review. The change needs one thing, and the author adds four: a module to hold the idea, a wrapper around a wrapper, a config flag for a usage nobody has yet. The work is fine. The shape is not. Every line you write is a cost the team pays for the life of the project, and every line you do not write costs nothing and cannot break.
The lazy senior developer does the opposite on purpose. No new dependency until the standard library is checked. No new function until the codebase is grepped. No abstraction until the second caller exists. The best code is the code you never wrote.
This is not a personality style. It is a decision procedure, and someone finally shipped it as a rule set for coding agents. The ponytail project on GitHub makes an AI coding agent think like the laziest senior dev in the room: smallest working diff, reuse before write, no unrequested abstraction. The tagline reads like a joke. It is a working definition of maintainability.
Why Extra Code Is a Liability
Consider a wrapper function. It adds a layer of indirection, and indirection has a price: the reader must open the wrapper, find the wrapped call, and hold both in mind at once. Most features do not need that cost. When the two-layer version and the one-layer version close the same ticket, the one-layer version wins by having no second place to be wrong.
The same math applies to security. A line of code that exists today is a window for tomorrow’s vulnerability. Fewer lines means fewer windows. So the lazy evaluation stops being about effort at all: skipping an edge case because you never wrote the code for it beats writing the code and getting it wrong.
Concrete example. More than one project has hand-rolled URL parsing when the standard library already shipped it. The stdlib version is one line, and it was debugged years ago by people who do it full time.
# The custom URL parser you were about to write already exists
python3 -c "from urllib.parse import urlparse; print(urlparse('https://example.com/path?a=1').hostname)"Five Questions Before You Write a Line
Run this ladder before you touch the editor, on your own drafts and on other people’s:
- Does this need to exist at all? Most features survive being dropped without anyone noticing.
- Does this codebase already do it under a different name? Grep before you write.
- Does the standard library do it? The answer is yes more often than people admit.
- Does the platform or an installed dependency cover it? Then you are finished.
- Can it be one line? Then it should be one line.
The ladder is an order of operations, not a ban on writing code. You are allowed to need something new. You are supposed to be sure it does not already exist before you write it. And the last rung gives you the exit condition that beats most code review: when a fix is one line, you do not earn points by adding lines around it.
YAGNI is not an excuse to skip requirements. It is an order of operations: prove the code does not already exist before you write new code.
Practical tip: before you open the pull request, run the deletion test. Take the new file out of the branch and run the task again. If the ticket still gets done, the file does not go in. Apply it to your own drafts, not just the junior dev’s, because the author of the bloat is usually you last month.