A developer gets a task. They understand it, open the file that seems most obvious, and start writing. Two days later, the feature is done. It works. The pull request is green.
Three weeks later, someone notices that the same function already existed — in a different service, slightly differently named, written by someone else. Now the logic lives in two places. It gets maintained in two places. It drifts. Eventually both variants behave differently, and nobody knows which one is correct anymore.
This isn’t a rare accident. It’s the default outcome in every team that works without discovery discipline.
What Is Discovery-First?
Discovery-First is the discipline of answering five questions in writing before a single line is written: Does this already exist? Where would the right home for it be? Which pattern fits? What test covers something similar? What breaks when this grows? Only once those questions are settled does code get written.
That costs half an hour. Sometimes less. This half-hour feels like a delay — you could already be typing. That feeling is exactly the trap. It overvalues visible activity over invisible prevention.
The math, though, is unambiguous. A duplicated function doesn’t just cost the second implementation. It costs every future bugfix twice, every adjustment twice, and eventually a full day of detective work figuring out why two nominally identical code paths behave differently. Against all of that, thirty minutes of research is the cheapest price you’ll ever pay.
Why Discovery-First Is the First Half of DRY
DRY — Don’t Repeat Yourself — is usually understood as a consolidation rule: when you spot duplication, merge it. That’s the second half. The first half is not letting the duplicate come into existence at all.
This is where things get interesting once AI assistance enters the picture. A language model handed a task will write a new function with complete confidence. It has no instinct to search the repository first — unless you build that instinct in explicitly. Teams developing with LLM assistance that don’t anchor Discovery-First get duplicates not despite the higher speed, but because of it. The tool produces faster — including the mistakes.
How Do You Make Discovery-First Stick in a Team?
Discipline that only lives in a wiki isn’t discipline. Three things make Discovery-First real, and none of them are burdensome:
- A fixed pre-code check. Five questions, answered in writing, before the first file is created. On new engagements, I make this a mandatory step in the plan document — not a recommendation.
- A justification requirement for new files. Every new file — service, component, utility module — gets one sentence: why wasn’t this added to an existing file? If you can’t write that sentence, you haven’t done the discovery.
- A gate that makes duplicates visible. Some duplication is mechanically detectable. A simple pre-push check that flags suspicious similarities catches more than you’d expect.
All three together shift the culture from “start typing” to “look first.”
Does Discovery-First Actually Slow Things Down?
The most common objection is: Discovery-First slows things down, and a fast-moving team can’t afford that.
The opposite is true. A team isn’t fast because it produces a lot of code. It’s fast because it rarely has to touch the same code twice. Every hour spent understanding what already exists saves a multiple of hours that would otherwise go into untangling its consequences.
If you want to move fast, ask first. The most expensive line of code isn’t the difficult one. It’s the one that already existed.
Frequently asked
- What does Discovery-First mean in software development?
- Discovery-First means answering five questions in writing before touching the keyboard: Does this already exist? Where does it belong? Which pattern fits? What test covers something similar? What breaks when this grows? Only once those questions are answered does code get written.
- Does Discovery-First slow a development team down?
- No. A team isn't fast because it produces a lot of code — it's fast because it rarely has to touch the same code twice. The half-hour of research upfront saves a multiple of hours that would otherwise go into untangling duplicated logic.
- Why is Discovery-First especially important with AI-assisted development?
- A language model writes new functions reflexively, without searching the repository for existing solutions. Teams using LLM assistance without anchoring Discovery-First get duplicates because of the higher speed, not despite it.