Your folder structure has two jobs, but only does one

It argues that folder trees do two distinct jobs - navigation (finding files) and classification (deciding where to place new files) - and that common structures usually optimize one at the expense of the other. Role-based taxonomies (forms/, modals/, layout/) make finding fast for cross-functional teams because names match mental categories, but they force subjective placement decisions and produce catch-all folders like shared/ that grow over time. Layer-based classification (core, elements, patterns - the CE Pattern) uses a mechanical rule: core holds untouched vendor code, elements wrap and enrich single sources into reusable vocabulary, and patterns compose multiple parts into purpose-specific exports. That rule enforces dependency direction and removes ambiguity about where a file belongs, though it makes immediate discovery less obvious.

Placement errors compound while navigation mistakes are one-off, so projects expecting growth or a shared component library benefit from a deterministic, rule-driven layout; small, early-stage, cross-functional projects may prefer role-based trees for quicker findability. Usability methods - tree testing and card sorting - measure the two jobs and can validate a structure. AI can speed setup once use cases are defined but does not replace judgment. A practical takeaway: default to simple, testable rules (like CE) that scripts or checklists can enforce, then evolve as real needs emerge.