YAGNI or nah

YAGNI is a pretty common principle in the engineering world today. And everyone already knows it has exceptions. You don't defer schema decisions, auth models, or audit trails because including them later gets to be much more expensive. That's everyday shit and hopefully doesn't come off as a surprise.

That said, a lot of folks don't put much thought into where the dividing line really stands. At what point is what you're trying to build out a speculative waste of resources versus something that's genuinely going to be useful in the near future? That kind of judgement is valuable but often gets shrugged off as something that's magically picked up with seniority or, even worse, vibes.

Why it's gotten more important to consider these days

The development lifecycle today is in flux. The layers of red tape and bureaucracy that used to govern the eng world are starting to be seen as a liability. Cross org alignment, endless layers of signoff, and testing for the sake of testing used to be the expectation. Now it only takes days to weeks for a competitor's release to kill your team's vision or your product before it even has a chance to fully materialize.

So the use of AI for development has stopped just being a cool tool you explore and float to a team that adds it to an approval icebox they'll never revisit. It's starting to become a requirement. Orgs have even started driving witchhunts for the luddites who don't adopt it.1

And this is not just a story that applies to deep tech anymore. I hear from friends everyday in other knowledge work domains like healthcare, banking, and law2 that pressures to increase output have been steadily ramping up in tandem with the introduction of new tools at work.3 Effective4 use of these tools has become a matter of survival in the professional world. It's no longer just about being tech savvy or ahead of the curve.

Now what does this have to do with YAGNI? When we use AI to generate code it shouldn't build the artifact completely from scratch. We should make sure to develop the spec and the skeleton ourselves. Then we can let the models color within the lines we draw.

Here is why that ordering matters more now. Hand an LLM an underspecified task and it's gonna fill the vacuum. It'll generate a pile of code to look productive. That tendency gets even worse when token spend becomes a performance metric leading to perverse incentives.5 People and agents both start optimizing for volume. The spec and the gates are the antidote. They are the lines the AI has to color within. That doesn't make every AI written PR slop. A PR is fine as long as it stays narrow enough for a human to actually review it without it eating into their day. Let it grow past that and you're just accumulating slop that looks like progress. And keeping PRs that small means fewer tokens on paper and fewer lines of code. Both are vanity metrics that reward volume over value. The orgs measuring one are usually counting the other whether it means anything or not. So you're probably losing the AI performance metrics game anyways.

This is not to say YAGNI is dead. This isn't meant to read as a license to overengineer everything from day one either. The point is meant to be more narrow than that. Build more of the controls and gates first. Do it before you turn an LLM loose to build the rest.

I used to spend a lot of my time in requirements conversations with product owners, program managers, and other functional folks. YAGNI was a beautiful concept in those discussions. It helped us ship faster, reduce technical debt, and often even made things simpler for end users.

The principle still holds but the economics underneath it changed. The cost of writing code dropped.6 The cost of underspecification and technical debt rose.7

That shift is the whole reason to revisit YAGNI now. The test itself does not loosen. What changes is what lands in each column. Consumers that used to be speculative now have names and rough dates because the agents are a new wave of them that take things even more literally than other humans would. If there was any gray area to consider logging and auditability a luxury before, it should completely vanish the moment a bot is introduced to make changes. Same test but more of your build ahead cases come back with a green light and YAGNI can begin to shift to YMANI.

The test has two questions

When something looks like it might be worth building before it's needed for sure, there are two main questions to consider.

Will it be a pain in the ass to retrofit? Is it cheap to do now but brutal to include later? Consider things like migrations on live tables, backfilling large volumes (or even worse, sparse, non-deterministic gaps) of missing data, identifiers that have to be threaded through every layer, and public interfaces other teams will later build on. If adding it later means a painful coordinated expensive change, it's retrofit hostile.

Can you name the consumer? Not "might someone want this someday." Can you point to the specific thing that will read it or use it and say roughly when it will arrive? A named consumer has an identity and a rough date. A speculative one is a shrug.

A 2x2 of retrofit hostility against nameable consumer. Only the retrofit-hostile and nameable-consumer quadrant earns building ahead; the other three defer.

The only thing that earns an early build is the case that is retrofit hostile AND has a nameable consumer. If it's not retrofit hostile, defer it. You can add it cheaply when the need is real. If you cannot name the consumer, defer it, because "I cannot name what will use this" is the definition of speculation. One case out of the set earns building ahead. The rest wait.

If the answer is yes, build the seam instead of the machinery

I recently had a subscription record that needed a field marking the point at which a subscription could be released. That point was driven by how long a published piece still needed its underlying data around. I shipped that field now. But the code that actually fills it in stays dormant. It's switched off until an upstream field it depends on exists.

Lets run it through the test:

  • Retrofit hostility: Yes. Adding a column like that later means a migration plus a backfill across live rows.
  • Named consumer: Yes. The retention behavior, a near horizon planned build, so it's not speculative.

Therefore it earns the early build.

Here's the refinement that makes this more than "YAGNI has exceptions." It's the actual craft. I did not build the feature ahead of time. I split it. I built only the retrofit hostile slice, i.e. the column. I left the cheap slice, the writer, dormant. Seam now, machinery later. The expensive to add part goes in early. The easy to add part waits until its consumer is real.

This one had a human roadmap behind it. In an agent heavy system the same logic fires more often because more of your future readers are bots you are already planning for.

Here's a second one from the same project, a bigger version of the same move. My agents analyze certain kinds of entities, so I built the canonical id layer early. A table of the canonical entities and their aliases, and the rule that every agent writes the canonical id from day one.

  • Retrofit hostility: Yes. Without it, each agent records entities under whatever name it grabs, and a few months later you have a pile of data keyed on identifiers that don't line up and can't be joined.
  • Named consumer: Yes. The first agent that writes an entity.

What I didn't build at the time was the harder part: the engine that decides whether two differently spelled names are equivalent. That part is more expensive, it needs real data to tune against, and it fails the test on timing. So I let it wait.

If the answer is no, feel free to leave a note but build nothing

This is the case that keeps YMANI honest. More yeses does not mean build everything.

Around the same time I sketched a layer that would collapse duplicate lookups. The scenario is many workers asking for the same rate-limited resource at once. I did not build it. I did not even leave a schema seam for it. I left a comment and moved on.

Same test.

  • Retrofit hostility? No. A deduplication layer drops in cleanly later when it's actually needed.
  • Named consumer? No. The thing it solves for is contention among many workers. At one worker that contention cannot physically happen yet. So I can't say for sure when it will arrive.

It fails both questions. So the right amount to build is nothing. The note exists so future me and agents traversing the codebase know considerations were already made and don't have to work it out again from scratch.

The two cases came from the same instinct that "this will matter once things scale." The test prescribed a different route to approach each though. That's the point. The instinct isn't the answer, the test is.

What the test does not cover

The catch is that the test only works on consumers you can foresee. It sorts the futures you've already imagined. It does nothing for the one you haven't.

The retrofit hostile thing that actually bites is the seam you never left. You never left it because it never occurred to you that a consumer would show up there. The discipline shrinks the surface of expensive surprises. It doesn't completely close it.

The more autonomous the system is, the faster unforeseen consumers arrive. Work runs without you watching. New things start reading your data and depending on your shapes at a pace no roadmap predicted. So the foresight the whole test depends on gets harder at the exact moment the cost of missing gets higher. You're building the rails for a train that's already in motion.

References

  1. ↩
  2. ↩
  3. ↩

  4. Almost every Fortune 500 now tracks employee AI usage — tokens, prompts, seat utilization (CNBC): https://www.cnbc.com/2026/05/05/ai-use-work-employee-monitoring-tech-surveillance.html ↩

  5. ↩

  6. Thomas Dohmke (GitHub), Marco Iansiti (Harvard Business School), and Greg Richards (Keystone.AI), "Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle": https://arxiv.org/abs/2306.15033 ↩

  7. The engineers now paid to clean up vibe-coded messes (404 Media): https://www.404media.co/the-software-engineers-paid-to-fix-vibe-coded-messes/ ↩