Beck argues the original intent of YAGNI was never about avoiding the cost of typing speculative code — it was about avoiding the carrying cost of speculative abstractions that must be read, tested, debugged, migrated, and explained over years. He reframes YAGNI as a judgment about asymmetry: if carrying is cheap and adding later is expensive, build it now; if carrying is expensive and adding later is cheap, defer. The rule does not apply uniformly.
By submitting Beck's piece and driving it to 110 points, the submitter signals endorsement of the reframing — that YAGNI-as-code-volume has been the dominant misreading and Beck's carrying-cost framing is worth surfacing to the HN audience.
The editorial argues that senior engineers have long felt YAGNI losing predictive power without being able to articulate why. Aggressive YAGNI application produces flat, undifferentiated procedural code with no seams — codebases that didn't suffer from too much speculative abstraction but from too little structure to absorb change cheaply. Beck's reframing names a failure mode the industry has been living with.
Kent Beck's latest newsletter post, "The Cost YAGNI Was Never About", hit 110 on Hacker News and is doing the rounds in the usual Beck-adjacent circles — TDD diehards, XP veterans, and the growing camp of engineers who treat his Substack as the closest thing the industry has to a continuous design journal.
The argument is short and slightly cranky. Beck says the way most engineers cite YAGNI — *"You Aren't Gonna Need It"* — has drifted into a folk rule about not typing extra code. That, he writes, was never the point. The original cost YAGNI was trying to dodge wasn't the cost of *writing* speculative features. It was the carrying cost: every speculative abstraction has to be read, understood, tested, debugged, migrated, and explained to the next person who walks in. Multiply that by a few years and a few teams and the bill comes due whether the feature shipped or not.
Beck's reframing: YAGNI is a statement about the asymmetry between the cost of *adding* a feature later and the cost of *carrying* the option to add it now. If carrying is cheap and adding later is expensive, build it. If carrying is expensive and adding later is cheap, defer. The mistake is assuming the rule applies uniformly — it doesn't.
The HN thread is unusually civil for a methodology post, and the reason is that Beck is naming something senior engineers have felt for years without articulating: YAGNI as commonly practiced is a vibes-based heuristic that's been losing predictive power. Anyone who has inherited a codebase where someone aggressively applied YAGNI knows the failure mode — a flat, undifferentiated mass of procedural code with no seams, where every new feature requires surgery through six unrelated call sites. That codebase didn't have too much speculative abstraction. It had too little structure to absorb change cheaply.
Beck's deeper point, which he's been circling in his *Tidy First?* work, is that the cost of change is not a constant of the universe — it's a property of your codebase that you can invest in or neglect. Tests, small modules, clear naming, reversible decisions, decoupled deployments: these don't reduce the cost of the *current* feature. They reduce the cost of the *next ten* features. YAGNI assumes that cost curve is already favorable. When it isn't, deferring everything becomes a way of locking in the high cost of change permanently.
The compounding insight: "You aren't gonna need it" and "make change cheap" are not opposing principles — they're the same principle stated at two different time horizons. One says don't pay for an option you won't exercise. The other says invest in the substrate that determines option prices. Beck is essentially arguing that the XP community spent twenty years preaching the first half and underselling the second, and that the result is a generation of engineers who quote YAGNI as a reason not to refactor.
The HN commentary is split in a useful way. One camp — mostly working at organizations with mature CI, feature flags, and reversible deploys — says Beck is describing the world they already live in: change is cheap, so YAGNI is mostly correct. The other camp — enterprise Java, regulated industries, anything with a manual release process — says deferring decisions has bitten them repeatedly, because by the time they need the abstraction, the cost of retrofitting it has multiplied by an order of magnitude. Both camps are right, and Beck's framing finally explains why they keep talking past each other. They're operating on different cost-of-change curves.
There's also a quieter undercurrent in the comments worth surfacing: the rise of LLM-assisted coding has tilted the carrying-cost calculation. When an agent can read, summarize, and modify a 2,000-line file in seconds, some of the cognitive overhead Beck originally worried about is genuinely lower. But the *correctness* overhead — the surface area for subtle bugs, the test debt, the production blast radius — hasn't moved. If anything, agents make it easier to *generate* speculative abstraction faster than humans can carry it. The YAGNI conversation in a world of Claude Code and Cursor is going to need a refresh, and Beck is sketching the vocabulary for it.
Stop using YAGNI as an excuse to avoid structural investment. If your codebase has a high cost of change — long test suites, brittle integrations, manual deploys, fear-driven code review — the right response is not to defer every abstraction. It's to spend a quarter making change cheap, and *then* defer with confidence. Beck's *Tidy First?* sequence is one prescription; trunk-based development, contract tests, and aggressive module boundaries are others.
Concretely: when you're about to invoke YAGNI in a code review, ask the second-order question. *If we need this in three months, what will it cost to add?* If the answer is "an afternoon," YAGNI wins. If the answer is "a two-week migration with a feature flag and a backfill," you're not saving cost by deferring — you're deferring *and amplifying* it. The right move might be to build the seam now, even if you don't build the feature.
For teams shipping with AI agents, the calculus shifts again: speculative code is cheaper to write but no cheaper to own. A Claude- or Cursor-generated abstraction still has to be tested, monitored, and understood by humans during incidents at 3am. The carrying cost Beck describes is *exactly* the cost that agents don't reduce. Treat agent-generated speculation with the same skepticism — arguably more — than you would human-written speculation. The line count is no longer the bottleneck; the cognitive and operational surface area is.
The interesting follow-up question is whether the industry can develop a more honest vocabulary for cost-of-change as a first-class engineering metric — something teams measure, budget for, and report on, rather than a vague quality everyone nods at. Beck is laying the groundwork. Expect the next wave of his writing, and the *Tidy First?* community around it, to push harder on making the carrying-cost argument quantitative. In the meantime, the next time someone quotes YAGNI at you in a PR, ask them which cost they think they're avoiding. The answer will tell you a lot about how their codebase actually ages.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.