I work with an AI that writes four thousand lines of code in a day. It is fast, precise, and tireless. In two days last week, it migrated eleven editor panels, deleted an entire domain, wired a context system that connects browsers to language models, and produced a net result of -6,389 lines. The codebase got smaller and gained features.
The AI wrote all the code. I wrote about twenty words.
And the twenty words were the part that mattered.
The Four Relationships
There are four ways to relate to a codebase when working with AI. The industry has names for the first two. The other two don’t have names yet, which is why most AI-assisted codebases will eventually collapse.
No relationship. The developer prompts the AI, gets code, ships it. Doesn’t read the code. Doesn’t understand the infrastructure. When it breaks, asks the AI to fix it. The industry calls this Vibe Coding. It works until the first production incident, which reveals that nobody — not the developer, not the AI — knows what the system actually does.
This is a fling. It’s exciting. It produces something. It doesn’t last.
A professional relationship. The developer understands every decision. The AI generates options; the developer navigates. Short, decisive redirections: “Mimic POSIX.” “Does NATS like slashes?” Five words that eliminate eighty percent of bad design paths. The industry calls this Vibe Engineering. It produces good software, shipped fast.
This is a job. Competent. Reliable. But when the quarter ends, nobody comes back on a Saturday to tend the garden.
A personal relationship. The developer loves the codebase. Not abstractly — specifically. Walks through it. Feels when something is heavy. Notices when a pattern from four months ago has been superseded. Deletes working code because it’s now weight, not because it’s broken. This doesn’t have a name. I call it Tending.
This is care. The gardener who plants and prunes. The parent who feeds and sets boundaries. The person who says “you’re getting fat” and means it tenderly.
A lifelong relationship. The developer places stones — small, generic conventions — months before they’re needed. Not because they can predict the future. Because thirty-five years of building software teaches you where the river narrows. The AI leaps between the stones at impossible speed. Twenty words redirect four thousand lines. The human can’t leap. The machine can’t place stones.
This doesn’t have a name either. I’ve been calling it the collaboration. It’s the relationship I’m in now, with a codebase I’ve been building for four months and a set of instincts I’ve been building for thirty-five years.
What the AI Can’t Do
The AI is the most capable collaborator I’ve ever worked with. I say this without irony. It writes better code than most developers, faster than all of them, and it doesn’t need coffee breaks. But there are three things it cannot do:
It cannot love the codebase. The AI doesn’t care if the codebase is beautiful or bloated. It builds what’s asked. It builds it well. But it doesn’t walk through the code on a Tuesday morning and feel that something is heavy. It doesn’t wince at a pattern that was right six months ago and isn’t anymore.
It cannot desire a solution into existence. The AI doesn’t lie awake thinking “there must be a way to make the editor announce itself to the language model.” It doesn’t spend December dreaming up a convention for a problem that won’t arrive until March. The desire is what creates the problem. The AI solves problems. It doesn’t have problems.
It cannot carry an idea across time. In December 2025, I wrote six lines of JavaScript that forwarded data attributes as HTTP headers. It was built for sidebar resize modes. The sidebar resize modes were deleted a month later. The for-loop survived. In March 2026, that for-loop became the foundation for AI context awareness across eleven editor panels. Zero new infrastructure. Net -5 lines.
The for-loop survived because I was too stubborn to delete something that wasn’t hurting anything. The AI would have deleted it during any cleanup pass. The AI is right to clean up unused code. The AI was wrong in this specific case. The difference is stubbornness — the human vice that is sometimes a virtue.
The Growth Problem
With AI assistance, the growth pressure on a codebase is 100x what it was. Four thousand lines in a day. Features that would have taken a sprint ship in an afternoon. This is genuinely wonderful and genuinely dangerous.
It’s wonderful because the vision doesn’t need trimming anymore. I can think further than I can type. The AI closes the gap.
It’s dangerous because growth without pruning is obesity. And AI only grows. It doesn’t prune by instinct — it prunes when told to. “Delete this domain. Remove the old pattern. Migrate these handlers.” The AI executes pruning beautifully. But the decision to prune — the feeling that something is weight — that’s human. That’s love.
Every AI-assisted codebase without a tender will reach Critical Mass — the point where complexity becomes self-sustaining and uncontrollable. The vibe-coded ones in weeks. The well-engineered ones in months. Even the loved ones eventually, if the love stops.
The only force that prevents it is someone who cares enough to delete thirteen thousand lines and call it a good week.
Why Enterprise Can’t
Enterprise systems don’t have this person. They have committees.
A committee can add features. A committee cannot delete features. Deleting disappoints constituencies. Disappointing constituencies requires someone willing to be unpopular. Committees distribute unpopularity so evenly it dissolves into inaction. The feature stays. The weight accumulates. The system reaches critical mass. A rewrite is proposed. The rewrite reaches critical mass. The cycle continues.
This is not a technology problem. This is a love problem. Enterprise systems are not loved. They are managed, maintained, monitored, and measured. Nobody loves them. Nobody walks through them on a Tuesday morning feeling for weight. Nobody deletes working code because the codebase needs to breathe.
The solo developer is the natural predator of critical mass. Not because of skill — a committee can have skill. Because of love. Love is singular. Love is the person who holds the pruning shears and the planting seeds and decides the season. Love is the -6,389.
The Prescription
If you’re building with AI — and you should be, the productivity is real and the quality is real — here is the thing nobody tells you:
Match your pruning frequency to your growth rate.
If you write four thousand lines in a day, you need to delete four thousand lines in a month. Not the same lines — the old lines. The patterns that were right before the new convention emerged. The domain that the AI made obsolete. The push-based system that the pull-based convention replaced.
The AI will do the pruning for you. Happily, precisely, at four thousand lines per day. But you have to feel what needs pruning. You have to love the codebase enough to know where it’s heavy. You have to be stubborn enough to carry conventions across months. You have to desire the solution enough to dream it before it’s needed.
Love. Desire. Stubbornness. The three things AI can’t automate. The three things that determine whether your AI-assisted codebase thrives or collapses.
The machine types. The human loves. That’s the whole thing.
There’s an encyclopedia where software principles get the roast they deserve — Pike’s Rules on a napkin, Zawinski’s Law with a nightclub, Gall’s Law in a boardroom. And a mythology where these ideas have been arguing with each other for a hundred episodes.
See also:
- Tending — The missing practice: growing AND pruning
- Vibe Coding — No relationship with the code
- Vibe Engineering — A professional relationship with the code
- Critical Mass — What happens without love
- The Caffeinated Squirrel — The scout who dreams the cathedral
- Pike’s Rules — Five rules on a napkin, the correct unit of architecture
- context.Context — The data structure that carries context to context