YAGNI
in the Agentic Era.

It was good advice when it was coined. It is more urgently true now, and almost nobody is following it.

01The scaffolding trap

Here is something that happens when you build with agents at speed.

You start with a feature. You describe it roughly — maybe a mental model, maybe a few sentences of context — and the agent begins. It scaffolds the structure. It adds a placeholder for the thing you’ll configure later. It creates a list item that reads “Option A” and “Option B” because the real names aren’t decided yet. It adds a color field with a default. A settings section with three empty rows. A migration for a table that doesn’t have data yet but probably will.

The agent is not doing anything wrong. It is filling in the shape of what you described, making reasonable assumptions about what a complete implementation looks like.

The problem comes later.

02Orphaned intent

When you return to that code — or when another agent session picks it up — the scaffolding has acquired a kind of false authority. It exists. It is part of the system. The placeholders look like decisions that were made. The empty settings rows imply that settings exist. The migration implies there is data to migrate. The color field implies someone wanted colors.

A human developer, coming to this code fresh, might pause and ask whether any of this is real. An agent almost certainly won’t. The agent’s job is to work with what’s there, extend it, build on top of it. And so it does. “Option A” becomes a conditional branch. The color field gets wired into three components. The migration gets referenced in a query. The scaffolding becomes load-bearing.

This is the new shape of technical debt, and it accrues faster than any previous version of it.

03The deletion problem

The classic YAGNI problem was a developer gold-plating a system based on imagined future requirements. The new problem is different in character. It’s not overengineering — it’s orphaned intent. Code that was never meant to be permanent, treated as permanent because it was never explicitly removed. Design artifacts that became product decisions by default.

I’ve watched a settings panel become a product feature because the list tile existed and it was easier to wire it up than to delete it. I’ve seen a UI button with placeholder text accumulate three months of surrounding logic because nobody stopped to ask whether the button was supposed to be there. I’ve seen database migrations for tables that were never populated, and query logic built to handle data that will never arrive.

Each of these is small. Together they are the texture of a codebase that becomes progressively harder to reason about — not because it’s badly written, but because significant portions of it represent nobody’s actual intent.

04Intent management

The deletion problem is underappreciated in the current conversation about AI-assisted development. Agents are exceptionally good at adding. They add code, add tests, add comments, add structure. They are genuinely bad at knowing what to remove — because removal requires understanding intent, and intent is exactly what gets lost between sessions.

A developer who has been inside a codebase for months knows what the orphaned migration was for. They remember the conversation where the feature got cut. They know the button was a placeholder. That institutional memory does not survive a context window reset.

The result is that codebases built with agents at speed accumulate a particular kind of mass — not complexity in the traditional sense, but volume. More code than the system needs. More structure than the requirements justify. More options than anyone is actually choosing between. And the agents that work in this codebase will dutifully maintain all of it, because they have no way to know what matters and what doesn’t.

05Still your job

The solution isn’t slower development or less agent involvement. It’s better intent management. Knowing what you actually decided versus what an agent assumed. Making explicit the things that are real versus the things that are scaffolding. Building systems that can distinguish between code that reflects a decision and code that reflects a placeholder.

The principle hasn’t changed. You still aren’t gonna need most of what gets generated speculatively. The difference is that now there’s an entity in your development loop that is extraordinarily good at generating it, and it doesn’t know any better than to keep it.

That part is still your job.