Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

YAGNI

Pattern

A reusable solution you can apply to your work.

“Always implement things when you actually need them, never when you just foresee that you need them.” — Ron Jeffries

Also known as: You Aren’t Gonna Need It

Understand This First

  • Requirement – YAGNI works when requirements are clear enough to distinguish need from speculation.

Context

At the heuristic level, YAGNI is a discipline that guards against speculative generality: building features, abstractions, or infrastructure for needs that haven’t materialized. It sits alongside KISS but addresses a different temptation: where KISS warns against unnecessary complexity in what you are building, YAGNI warns against building things you don’t need to build at all.

In agentic coding, YAGNI is under constant threat. An AI agent asked to build a user registration system might add password reset, email verification, two-factor authentication, and account deletion before you asked for any of it. The agent isn’t wrong that these features are common; it’s wrong that you need them right now.

Problem

How do you resist the pull of building for hypothetical future needs when the cost of building feels low?

Every feature you build today must be maintained tomorrow. Speculative features carry the same maintenance burden as real ones (they need tests, documentation, bug fixes, and compatibility updates) but they deliver no current value. Worse, they shape the codebase in ways that constrain future decisions. The feature you imagined you’d need rarely matches the feature you actually need when the time comes.

Forces

  • Low cost of generation, especially with AI agents, makes it feel cheap to add “just one more thing.”
  • Fear of rework makes people want to build it right the first time, even when “right” is unknowable.
  • Pattern matching leads experienced developers and AI agents to include standard features that may not apply.
  • Stakeholder requests often conflate “nice to have someday” with “must have now.”

Solution

Build only what you need to satisfy today’s requirements. When you feel the urge to add something for a future scenario, write it down as a note and move on. If the need materializes later, you’ll build it then, with the benefit of concrete requirements rather than guesses.

This doesn’t mean ignoring the future entirely. Good architecture makes future changes possible without making them present. There’s a difference between designing a database schema that could accommodate new fields (good foresight) and building an admin interface for managing those fields before anyone has asked for it (speculative generality).

When working with an agent, review its output for unsolicited additions. Agents are trained on codebases that include mature, fully-featured systems, so they tend to reproduce that maturity even when you’re building a prototype. Ask explicitly: “Only implement what I’ve described. Don’t add features I haven’t requested.”

Warning

Speculative code isn’t free even when an agent writes it instantly. You still have to read it, understand it, test it, and maintain it. The time the agent saved writing it, you spend reviewing and carrying it forward.

How It Plays Out

A developer asks an agent to build a command-line tool that converts Markdown to HTML. The agent produces the converter plus a plugin system, a configuration file format, and a watch mode for live reloading. The developer wanted a single function: Markdown in, HTML out. She deletes three-quarters of the code.

A team building an internal tool debates whether to support multiple authentication providers. They currently have one: the company SSO. They decide to hardcode that integration rather than build a provider abstraction. Two years later, they still have one provider. The abstraction would have been carried, tested, and debugged for two years without ever being used.

Example Prompt

“Build a Markdown-to-HTML converter. Just the converter — a function that takes Markdown in and returns HTML out. Don’t add a plugin system, config file, or watch mode. We can add those later if we need them.”

Consequences

Applying YAGNI keeps codebases small, focused, and understandable. Less code means fewer bugs, faster builds, and easier onboarding. You preserve the freedom to make different architectural choices later because you haven’t prematurely committed to a particular generalization.

The risk is genuine under-investment. Some capabilities (security hardening, data migration paths, accessibility) are expensive to retrofit and easy to defer. YAGNI isn’t an excuse to ignore real non-functional requirements. The distinction is between “we know we need this” (build it) and “we might need this someday” (don’t build it yet).

  • Contrasts with: KISS — KISS addresses complexity in what you build; YAGNI addresses whether to build it at all.
  • Uses: Smell (Code Smell) — speculative generality is a recognized code smell.
  • Depends on: Requirement — YAGNI works when requirements are clear enough to distinguish need from speculation.
  • Enables: Local Reasoning — less code means less to load into your head.
  • Related: Premature Optimization – optimizing for load you don’t have is building what you don’t need.
  • Related: Technical Debt – speculative features become debt when requirements shift.