reducing-entropy

Evaluate each change by its net effect on total lines, files, and functions rather than effort spent. Ask what the minimal codebase solving the problem looks like, reject changes that increase total code, and treat every modification as an opportunity to delete obsolete code.

It is a manual-only refactoring skill that biases toward deletion and measures success by final codebase size. Use it when refactoring, evaluating feature requests, or paying down technical debt, and only when explicitly requested.

Avoid it when the codebase is already minimal for its requirements, when working within a framework with rigid conventions, or when regulatory requirements dictate a specific structure. Fighting the framework or compliance rules creates more problems than it solves.

YAGNI says do not build features you might never need, while PAGNI identifies exceptions where retrofitting is dramatically more expensive, such as timestamps, audit logs, API versioning, and pagination. PAGNI applies only when later addition is roughly ten times costlier.

Because more files and functions mean more code, and separation is not free. The skill treats flexibility, type safety, and organization as red flags when they increase total code volume, since fourteen entities are never easier to understand than two.