We're at an odd moment in software development. AI can write code faster than any human. But speed without quality is just technical debt at scale.
This is a story about constraints.
The component started at 477 lines. It handled loading states, error states, empty states, hover effects, multiple callbacks, and a dozen boolean props. It was "flexible." It was also unmaintainable.
Every new feature required understanding the entire component. Edge cases multiplied. Tests became integration tests by default. "Just add a prop" was the response to every request, and the prop count grew from 8 to 12 to 19.
The team was stuck in a cycle: ship fast, accumulate debt, slow down, refactor, repeat. The component that was supposed to save time was now the biggest time sink in the codebase.
"The component that does everything is the component that does nothing well."
The Intervention
We introduced hard stops. Not guidelines. Not recommendations. Absolute limits that couldn't be negotiated away. If code violated a rule, it was rejected. No exceptions, no "just this once," no emergency bypasses.
The rules were simple:
Props had limits too: 8 maximum, only 1 callback, no more than 2 booleans. No nested object props. No loading states inside components—that's the parent's job.
The Resistance
The team pushed back. Hard. "What about complex forms?" "What about data tables?" "What about the dashboard?" Every edge case was raised as proof that limits couldn't work.
The answer was always the same: decompose. If a component is too big, it's doing too much. Split it. If it still doesn't fit, split it again. The limit isn't the problem—the architecture is.
The Results
The 477-line component became 96 lines. Not by removing functionality—by distributing it properly. The parent component handled loading. A separate component handled empty states. Error boundaries caught errors. Each piece was testable in isolation.
New team members could understand a component in minutes instead of hours. Code reviews became meaningful instead of rubber stamps. The "just add a prop" reflex was replaced by "should this be a new component?"
Constraints don't limit creativity. They focus it.
— The unexpected lesson
The Lesson
Hard stops work because they remove decisions. When you hit the limit, you don't debate whether to refactor—you refactor. When a component has too many props, you don't discuss whether that's okay—it's not. The rule is the rule.
This frees mental energy for the decisions that actually matter: What should this component do? How should it compose with others? What's the right abstraction? These are the creative questions. The constraints handle the rest — and the learnings accumulate.
Every decision you don't have to make is time and energy you can spend on decisions that matter. Hard stops aren't limitations—they're liberation.