What is YAGNI (You Aren't Gonna Need It)?
Length:
4 min
Published:
June 9, 2026
What is YAGNI?
YAGNI stands for "You Aren't Gonna Need It." It is a software design principle that says you should add a feature, abstraction, or configuration option only when there is a real, present need for it, not because you expect to need it someday. The principle comes from Extreme Programming, where Kent Beck and Ron Jeffries used it to push teams toward the simplest thing that works right now.
In plain words
YAGNI is the engineering version of "don't pack for a trip you haven't booked." You can imagine a hundred things you might want one day, but most of them never happen. Every speculative feature still has to be written, tested, and maintained, so building for an imaginary future usually costs you more than it saves. Solve the problem in front of you. If the future arrives, you can build for it then, when you actually know what it needs.
Why YAGNI exists
Developers are trained to think ahead, and that instinct is useful. The trouble starts when "thinking ahead" turns into writing code for requirements nobody has confirmed. That speculative code does not come for free:
- Someone has to write and test it, which delays the work that actually ships.
- It stays in the codebase as extra surface to read, debug, and keep working through every later change.
- It is often wrong, because guesses about future requirements rarely match what the future actually asks for.
YAGNI is the counterweight. It keeps a system small enough that the parts that earn their place are easy to find and change.
When it matters
- You catch yourself saying "we might need this later." That sentence is the clearest YAGNI trigger there is. If the need is real, name it and build it. If it is a guess, leave it out.
- You are adding a config flag, a plugin layer, or a generic abstraction for one use case. One caller does not justify a framework. Wait for the second and third real cases before you generalize.
- You are reviewing a pull request that does more than the ticket asked. Extra scope is harder to review, test, and roll back. Ask whether each addition answers a need that exists today.
- You are working with an AI coding assistant. Tools like Cursor and Claude Code happily generate elaborate, "future-proof" scaffolding. YAGNI is how you tell which of that output to keep and which to delete.
Common pitfalls and misuse
- Treating YAGNI as an excuse to skip real design. YAGNI is about avoiding speculative features, not about ignoring requirements you already know. Known needs are not YAGNI.
- Confusing it with cutting quality. Tests, error handling, and clear names are not optional extras. YAGNI trims unneeded scope, not the rigor that keeps shipped code reliable.
- Using it to win arguments instead of making decisions. "YAGNI" shouted at every suggestion stops being a principle and becomes a reflex. The honest question is always the same: do we have a real need for this right now?
- Forgetting that some decisions are expensive to reverse. A data model or a public API is costly to change later. For those, a little forethought is cheaper than a rewrite. YAGNI fits best where reversing course is cheap.
Related articles:
- What is Vibe coding? - Building software by prompting an AI instead of writing code by hand, and why scope discipline matters even more there.
- Context engineering: the new developer skill - Giving an AI the right context, and only the right context, to get useful output.
- What is Developer Experience and why you should care? - Why a smaller, clearer codebase makes every developer faster.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.