A type — class or interface — with too many fields and methods; multiple unrelated responsibilities under one name.
A type definition — class or interface — with so many fields and methods that the agent cannot load it as a coherent unit; multiple unrelated responsibilities sit under one name.
Each type has one cohesive purpose; methods cluster around fields they actually use.
Each type has one cohesive purpose; the agent loads a small focused file to reason about any single behavior.
Smellier version
class Order {// lineItems, totals, customer info, shipping address, audit log, ...}
Fresher version
class Order { /* lineItems, totals */ }class Customer { /* name, email */ }class Shipping { /* address, track */ }
Cognitive load: every reader pays for fields they don't care about; merge conflicts spike; testing is unfocused.
Cognitive context inflates with every irrelevant member; the agent reading any single method must skim past unrelated fields and helpers to find what it needs.
Splitting a large type creates collaborator relationships that the team must learn; some types are large because they encode a genuinely large domain concept that resists decomposition.
Splitting creates new collaborator relationships the agent must trace across files; what was one load now becomes N loads and the agent must understand how the pieces interact.
Smaller, more testable units; clearer ownership; faster reading.
Smaller, focused units; the agent's reasoning context per method is tight; tests target one concern at a time.
Splitting every large class on superficial groupings (methods that happen to share a prefix, fields that happen to be related) without honoring real cohesion boundaries — produces fragments that don't make sense apart.
Splitting on superficial groupings produces fragments that don't cohere on their own — the agent now navigates several files to understand what was previously one coherent (if large) concept.