YAGNI Changed Altitude

Last month I caught myself telling an agent not to build something, and then couldn't explain why. The feature wasn't speculative — we knew we needed it. The implementation wasn't risky — the agent could have had it working in an hour. I said "not yet" out of pure reflex, and when I examined the reflex, I found YAGNI sitting underneath it, still running, long after the conditions that justified it had changed.

YAGNI shaped a generation of engineers. It took hold hardest during the Scrum era, where it became doctrine — scope down, reduce blast radius, don't build what you haven't justified. At Amazon it was baked into the operational culture, reinforced in layers of design, system, and code reviews. I internalized most of it. But I was never a purist. The best engineers I worked with weren't either. You always built a little beyond the ticket — cleaned up the code around what you touched, laid a foundation for what was clearly coming next, handled the edge case that wasn't in the acceptance criteria but was obviously going to bite someone. Pure YAGNI said don't. Experience said do, but keep it small. That tension was the craft.

What I keep catching now is different. It's not the healthy tension between discipline and pragmatism. It's the reflex firing in places where the constraint behind it — human time — no longer exists. And I've had to sit with why.

YAGNI isn't wrong. The floor it operates on has risen. The level of abstraction where "you aren't gonna need it" is the right instinct used to be individual functions, endpoints, features. It's now entire systems, product lines, market capabilities. Everything below that new floor — the code, the modules, the internal services, the features — is cheap enough to explore freely. YAGNI moved upstairs. Most of us are still enforcing it in the basement.

What the principle was actually about

YAGNI is taught as a principle about code. Don't build what you don't need. Keep the system small. Avoid speculative features. It sounds like engineering discipline.

But it was never really about code. It was about time.

An engineer in 2020 decides to build something that isn't strictly necessary for the current sprint. Two days implementing. A day writing tests. Half a day debugging an edge case. Then code review — an hour for the reviewer to understand it, a design issue flagged, another half-day fixing it. Three months later it'd interact with something else in a way nobody predicted, and a different engineer would burn a day tracing down why.

Every feature carried a time tax. Not just build time — review time, debugging time, maintenance time, comprehension time for every person who'd touch that code for years. And comprehension was the sneaky one. Every line you added was a line your future self — or someone else — would have to read, internalize, and reason about the implications of before making the next change. Keeping the system small wasn't just about build cost. It was about keeping the codebase legible to the humans who had to live in it.

YAGNI said: don't incur that tax unless you know you need the feature. When human hours were the dominant cost in software, that was rational. You had a fixed budget of human attention. You spent it only on things with known value.

The industry internalized the heuristic so deeply that it forgot what it was optimizing for. "Build less" became intrinsically good engineering, rather than a strategy for managing the scarcest resource in the team. When someone argued for building something bigger, something more exploratory, the response was always YAGNI — as if the principle were about the code, rather than about the human time the code would consume. The engineers who pushed back — who built a little beyond, who cleaned up around what they touched — were often doing better engineering. But the doctrine had the catchier name.

That distinction didn't matter for twenty years. Code and time were coupled. Building more code meant spending more human time, every time, no exceptions.

They're not coupled anymore. And that's where the floor starts to move.

The floor rises

When a developer at SageOx builds an OTA firmware update system in an afternoon using agent swarms — something that was a two-sprint project previously — the implementation cost goes to near zero. Everyone's talking about this part.

What most people miss: the review time didn't go to zero. It shifted shape. And it's now the thing that determines how fast a team actually moves. A human reviewing a feature, running through an end-to-end flow, spotting that the permission model feels wrong or the onboarding drops you at a dead end — that still takes time. Human attention is the expensive resource now. It always was — we just couldn't see it because implementation time dwarfed everything else.

When implementation was expensive, YAGNI made sense at the code level — every function, every endpoint, every feature carried real human cost. Now that implementation is cheap, the code-level cost has collapsed. But the systems-level cost hasn't. Deciding whether to build an entirely new product line, enter a new market, stand up a new platform capability — those decisions still carry enormous commitment cost, because they create obligations that extend beyond your team, beyond your codebase, into the world of users, partners, and organizational coordination.

YAGNI at the code level is now a constraint on exploration in a domain where exploration is essentially free. YAGNI at the systems level — don't commit to a product capability you haven't validated, don't build a platform you don't have users for, don't enter a market you haven't tested — is as correct as it ever was.

The principle moved upstairs. Most engineers are still enforcing it in the basement.

Batch for how humans actually think

If human attention is the bottleneck, you want to maximize the value of every hour a human spends evaluating work. The implications for scoping are uncomfortable.

The YAGNI-era workflow delivers small increments. Get audio working. Review it. Add Wi-Fi setup. Review that. Then OTA. Review that. Each review cycle costs human time: context-switch in, understand what changed, evaluate it, context-switch out.

We're terrible at evaluating small diffs in isolation, and great at evaluating complete flows end-to-end. Show me a three-line change to an error handler and I'll tell you the code is correct. Show me the complete onboarding experience — auth, profile setup, initial data load, welcome screen — and I'll tell you whether the product is right. Those are different kinds of evaluation. The second is dramatically more valuable.

Humans pattern-match. We spot things that feel off — when a flow has one too many steps, when an error message doesn't match the user's mental model, when a screen feels dead because it's missing feedback. We do this best when we can see the whole picture. You evaluate a house by walking through it, not by reviewing the blueprints one room at a time.

I keep watching this occur at SageOx. When we deliver a complete feature — rough around the edges, but end-to-end functional — members on the team spot things in ten minutes that would have taken weeks to surface if the work had been done incrementally. A flow that technically works but feels wrong. An interaction between two features that creates confusion. A capability that's present but undiscoverable.

Reading code doesn't give you this. You can stare at a diff and convince yourself the logic is correct — and you'd be right about the logic. But you won't know whether the feature actually works until you use it. This is the same gap the agents have, incidentally — they're bad at predicting how code will behave without running it, which is why the most effective agent workflows loop against a working system rather than reasoning about code in the abstract. Humans have a better technical mental model than agents do, but we share the same blind spot: we can't feel whether an onboarding flow is right by reading the components. We have to walk through it. Product-level insights only emerge when enough of the system exists to interact with.

Someone steeped in the code review literature will object: "research shows review quality drops after 400 lines of diff." True — for line-by-line code review. The SmartBear/Cisco study that established this finding looked at 2,500 reviews across 3.2 million lines of code, and the result is real. Line-by-line still matters for a small subset: cryptographic implementations, authentication boundaries, data integrity invariants. Those areas deserve pre-2025 discipline.

But that's not what most code is anymore. Feature flows, UI, integrations, business logic — these are better evaluated at the outcome level. Does the feature work? Does the flow make sense? Does the system behave correctly? Behavioral review gets better with more context, not worse. The 400-line research is about a review model that's rapidly becoming the exception.

What YAGNI was cutting that it shouldn't have been

Nate Meyvis argued earlier this year that YAGNI applies better in 2026 than it did before, because AI reduces the cost of revisiting code later. Markus Eisele wrote that the senior developer's new job is saying no. Saying no is still good. An agent that builds password reset, 2FA, and account deletion when you asked for a login page is classic YAGNI violation. Still bad. The senior engineer who can see the whole system and say "not this, not now, not here" based on actual reasoning about what matters — that judgment is more valuable than ever.

But that's not what I see most of the time. What I see is YAGNI as dogma — a reflexive no that doesn't engage with why. Engineers who invoke it as a crutch when they haven't really thought through the bigger picture, or when they're avoiding the harder work of understanding what's actually coming next. The principle became a substitute for judgment rather than an expression of it. The problem isn't engineers who say no thoughtfully. It's engineers who say no reflexively at the wrong level: deferring work not because it was speculative, but because there wasn't time.

The error handling that would have been more thorough if the sprint were longer. The edge cases everyone knew existed but nobody had bandwidth to cover. The integration tests that would have caught the interaction bug but would have taken a week to write. The refactor that would have simplified three services but couldn't be justified against the roadmap. And maybe the most painful one: the UX refinement that everyone knew would make the experience genuinely good, but would require days of tweaking interactions, polishing transitions, and iterating on feel — work that didn't enable new functionality, so it never survived prioritization.

That last category is worth sitting with. The difference between a product that works and a product that feels right is dozens of micro-interactions, each individually unjustifiable against a feature roadmap.

It's the difference between an Apple product and a Dell. Between a Tesla's interface — whatever you think of the driving dynamics — and the infotainment system in most other cars that boast comparable specs but never capture that frictionless, smartphone-like feel. That level of polish was always possible. It was just too expensive in human hours to justify, so we shipped "good enough" and moved on. Now you can iterate on feel the way you iterate on logic — relentlessly, cheaply, until it's right.

Those weren't speculative. They were known necessities deferred because human time was scarce. Ron Jeffries called this "skimping" — distinct from YAGNI, but wearing its clothes. YAGNI gave teams the language to rationalize the deferral — you aren't gonna need it — when the honest version was you aren't gonna have time for it.

Now you have time. The agents have time. The question I keep asking myself is whether my instincts will let them use it, or whether the conditioning runs deep enough that I cut scope reflexively at a level where the constraint no longer exists.

Comprehension at scale

The strongest objection I've heard: even if build cost drops to zero, comprehension cost doesn't. Every feature you add is a feature someone has to understand, maintain, explain.

I used to find this convincing. Then I thought about what comprehension actually looked like at the organizations where I held this concern most.

At Amazon, with hundreds of engineers across dozens of teams, a Senior Principal Engineer didn't hold implementation details in their head. Couldn't. Nobody could. You had a rough map — service boundaries, data flows, ownership — but not the turn-by-turn. The turn-by-turn lived in the code, and the code lived in the heads of two or three engineers who'd written it most recently. When they left, comprehension cost spiked regardless of how much YAGNI discipline you'd applied.

What's changed is that you can ask the system about itself. Point an agent at a module: "explain how the permission model works," "trace the flow from auth to data seeding," "find everywhere this state is mutated." Comprehension cost didn't go to zero — but it went from "hold the whole thing in your head or spend hours reading code" to "ask a question, get an answer in thirty seconds." Galex put it bluntly: "I don't read code anymore." He used to use YAGNI partly as a way to scope complexity for his future self — the less code he'd have to read and internalize, the faster he could make changes later. That calculus flipped. The code is still there, and it still matters. But the human's relationship to it changed from reading it to querying it.

The part that still holds: external interfaces. Contracts that cross team boundaries or face users — published APIs, data formats, behavioral guarantees — still need to be legible to humans reasoning from the outside. But internal interfaces? The ones between components your own team operates? Those are far more fluid than they used to be. An agent can refactor an internal API and update every caller in the same session. The interface that used to feel permanent because changing it meant coordinating across three teams is now just another thing you reshape as the system evolves. YAGNI at the contract level — don't commit to an interface you haven't validated — still holds. But the set of interfaces that qualify as commitments is smaller than it was, and shrinking with team size.

Fewer decisions are irreversible than you think

One more assumption baked into YAGNI: many engineering decisions are expensive to reverse, so defer them.

In practice, most decisions that felt irreversible pre-2025 were irreversible because of coordination cost, not technical difficulty. Changing a database schema isn't hard. Migrating fifty engineers' code that depends on it was hard. Versioning an API isn't hard. Getting twelve downstream teams to adopt the new version was hard. The "irreversibility" was a property of the organization, not the technology.

A three-person team running agent swarms has a tiny coordination surface. You change an internal API and update every caller in an afternoon — the "team" that needs to coordinate is one human and their agents. The decision that took a quarter to reverse at Amazon with a dozen engineers on different teams is a Tuesday refactor in a modern AI development team.

The set of truly irreversible decisions shrinks to: things external users depend on. Published APIs. Shipped behavior. Persisted data formats. Everything else — internal APIs, data models, service boundaries, abstraction choices — is fluid, especially in small teams. Feature flags mark the line: behind a flag, experiment. In front of users, commitment.

YAGNI applies to commitments. The number of things that qualify as commitments is much smaller than our instincts suggest — and shrinking as teams get smaller and agents handle coordination.

The floor, not the principle

YAGNI isn't dead. It moved. The floor it applies at rose from code-level to systems-level, because the cost model underneath it changed. Below the new floor — functions, features, modules, internal services — exploration is cheap, reversal is cheap, and constraining scope is an unforced error. Above the floor — product commitments, external contracts, market-facing capabilities — YAGNI is as wise as it ever was.

The hard part is that most engineers' instincts don't know the floor moved. The muscle memory still fires at the old altitude. I catch myself doing it — looking at an agent building something and thinking we don't need that yet, then stopping to ask: is this a systems-level commitment I should defer, or a code-level exploration I should let run?

Those are different things. Learning to tell them apart — learning where the new floor is — might be one of the more important skills to develop right now.