Over-engineering is a technical debt trap

Writing code for your peak mental state is a recipe for production failures. Most developers treat code like a personal logic puzzle, resulting in cryptic one-liners and single-character variables that look efficient during a flow state but become impossible to debug during an incident. Real engineering efficiency is measured by how quickly a tired engineer can resolve a production error at 3 AM, not by how "clever" the original implementation was.

This issue is compounding with the rise of LLM-assisted development. There is a misconception that Clean Code principles are obsolete because Claude or GPT-4 can generate logic. In reality, the quality of AI output is strictly bounded by the context you provide. If your architecture is built on "clever" but opaque logic, you are feeding the model garbage. An LLM cannot infer intent from undocumented, non-descriptive code; it will simply hallucinate or propagate your existing technical debt.

If you can't explain the logic to a machine via a prompt, you won't be able to explain it to a teammate—or yourself—six months from now. Stop optimizing for "wizardry" and start optimizing for maintainability.

The goal is predictable, readable logic that survives a pager alert.

# Aim for clarity over cleverness
grep -r "unclear_logic_pattern" ./src