yagni

Apply the YAGNI evaluation checklist to each change: check whether any class, interface, or helper serves a hypothetical future requirement, whether all parameters are consumed by existing code, and whether deleting the abstraction breaks any current test. If no test fails, delete it.

Speculative abstractions include interfaces with only one concrete implementation, generic factory or builder patterns for objects constructed in one place, and plugin or hook systems created before a second consumer exists. These add indirection without serving a current requirement.

Hardcode constants until there is a proven operational requirement to change them without a code deployment. Adding configuration knobs or environment variable overrides just in case creates dead flexibility that must be maintained and tested without delivering value.

YAGNI should not override correctness or edge-case handling required by the current problem. The checklist explicitly asks whether simplification hurts correctness, so genuinely needed validation, error handling, and domain-driven structure should remain.

YAGNI prefers native platform and standard library solutions first, avoiding external packages for problems solvable in five to ten lines of standard library code. It does not ban dependencies outright; it favors flat, boring functions over layered dependency trees.