How Developers Think
$definedry--plain-english
TLDRWrite it once. Reuse it everywhere.
DRY means Don't Repeat Yourself.
Write a fact or a rule once. Point everything else at that one place. When the rule changes, you change it once and the product stays honest.
The bad version of the opposite is copy-paste that drifts. The same coupon check in the checkout page, the email, and a forgotten admin route. You update two. The third still promises free shipping at $50. A judge will find the third.
One source, not one blob
The good version in this stack is a shared schema, a helper, an env name, a constant the CLI already generated. Validation that lives in three files will disagree. Validation that lives in Zod once will not.
The bad version of DRY is a helper so abstract nobody can change it. If two blocks look alike but will grow apart, leave them. The test is not "do these look the same." The test is "would you always change both together." If no, YAGNI is the seatbelt.
Agents paste. You stop them.
Vibe coding is a copy machine. Ask an agent for a feature and it will happily duplicate the rule. Say it out loud: "This logic is in three places. Pull it into one module and import it." That is refactoring with a purpose, not tidying for sport.
At a hackathon, DRY the path that will change tonight — prices, flags, the demo email. Do not DRY the rest of the universe before the first deploy.
What this unlocks
A change you can do in one file is a change you will actually finish. A change that lives in five files is a bug you have not met yet. Write it once. Point at it. Sleep.