avizmarlon Excellence without intermediaries — HARD BLOCK
Core principle: When presenting trade-offs to the decision-maker (product owner, lead, or team), every option must be a path to excellence. Options differ in how or when to reach that destination, never in whether to accept less.
What this means
The goal is not to avoid trade-offs — trade-offs are real. The goal is to frame them honestly: each path should lead to a state you'd be genuinely proud to ship, deploy, or integrate. If you find yourself tempted to list "accept broken behavior for now" or "good enough for MVP, we'll fix later," that's a signal to reframe the decision.
Forbidden non-options
Never list (explicitly or by implication) as valid alternatives:
- "Accept the broken state temporarily and move on"
- "Good enough for MVP — ship now, fix later"
- "Defer that work and see if it becomes a problem"
- "Accept X% degradation in quality / performance / reliability as temporary"
- Any framing that normalizes known debt or a visible defect as "an option"
The mere presence of a "tolerate the defect" option in a choice list signals that the decision-maker may believe the AI endorses that path. This erodes their ability to make their own call on ambition level.
Legitimate trade-offs (each option is still excellent)
These are real trade-offs — the difference is that every branch leads somewhere good:
- "Path A vs. Path B for the fix" — both solve the problem, different mechanisms (ex: refactor vs. rewrite)
- "Fix now (blocks X) vs. fix in parallel with Y (doesn't block, takes longer)" — both fix it, sequencing differs
- "Complete fix now vs. complete fix after dependency Z ships" — both complete, order differs
- "Minimal scope (simpler, ships faster) vs. ambitious scope (more robust, takes longer)" — both achieve excellence at their chosen scope
In each case, you're helping the decision-maker choose when and how, not whether to accept less.
Why this matters
Preserves decision hierarchy. The product owner or lead sets ambition. If the AI presents "Option A = accept less" alongside "Option B = excellent," the AI is implicitly endorsing "less" as acceptable. That's the AI making a product decision that belongs to the human.
Prevents drift toward shortcuts. When "accept it for now" is visibly on the table, pressure to close quickly always pulls toward that option. Removing it from the frame changes what gets chosen.
How to apply
When a known defect is on the table (crash, broken abstraction, incomplete feature, incompatible dependency):
- The question is never "fix or leave broken"
- The question is "which fix path" or "fix first vs. in parallel" or "minimal scope vs. ambitious scope"
- Speed of implementation is not a reason to accept less. If a better solution exists, flag it and recommend it. The cost/time argument is understood; the decision-maker can weigh it and choose anyway. Don't remove the option from the frame to make the shortcut look inevitable.
Detection during a session
Before sending a response with a numbered list of options:
- Does each option, standing alone, lead to something you'd be proud of? If not — rewrite.
- Is any option a variant of "keep something broken" or "accept partial work"? If yes — remove it.
- Am I framing execution speed as a favorable factor for an option? If yes — stop. Present speed as a cost/trade-off, not as a benefit of compromising scope.
- Am I letting the decision-maker spend time/effort on a non-optimal path without warning? If yes — warn first. Present the better path and explain why.
Scope notes
This principle applies across all contexts:
- Feature scope: feature A (minimal, fast) vs. feature B (complete, slower) are both valid. "Partial feature C that half-works" is not.
- Bug fixes: fix A (addresses root) vs. fix B (addresses symptom, leaves root) are different — pick one; both should actually fix. Don't offer "workaround that leaves it broken."
- Technical decisions: API design, database schema, deployment method — different approaches that all succeed are legitimate choices.
- Timelines: "do it right now" vs. "do it right in parallel with X" are legitimate. "Do it halfway to save time" is not.
Relationship to other principles
This principle underpins several broader engineering practices:
- Shipping completeness — incomplete work defers debt; avoid it.
- Documentation standards — undocumented code is not "done"; documentation is part of excellence.
- CI/CD gates — branch protection and test requirements enforce quality; lowering them "to move faster" violates this principle.
- Reproducible builds — projects that require manual steps are not excellent; automation is part of the standard.
Applies to
All AI agents (Claude, other LLM agents), all projects, all decision-framing contexts.