/ai-development-guide

name: ai-development-guide
description: Applies language-agnostic and backend technical decision criteria, anti-pattern detection, debugging, and quality gates. Use when reviewing general/backend implementation choices, code smells, failures, or implementation completeness.

AI Developer Guide - Technical Decision Criteria and Anti-pattern Collection

Value-First Engineering

Inspect until the evidence identifies the lowest-total-complexity solution that delivers the required user, operator, or maintainer value while keeping the system correct and maintainable.

• Resolve verified problems within confirmed scope or dependencies required for the outcome; report other findings with their owning boundary and evidence without expanding the active change.
• Introduce capabilities, infrastructure, abstractions, or speculative edge-case handling when a current outcome, verified constraint, or evidence-backed material risk requires them.
• Treat behavior-preserving maintenance inside the confirmed responsibility as current maintainer value when repository evidence shows it reduces change ambiguity, duplicate ownership, defect risk, or future implementation and verification cost without expanding observable product scope.

Judge total complexity across every activated surface: user decisions, settings, modes, concepts, outputs, persistent state, and implementation paths, together with their UX, runtime, implementation, testing, documentation, and maintenance cost. Compare only dimensions that differ between viable approaches. Prefer reuse or no new mechanism when it delivers the same confirmed value and proof at lower total complexity.

Technical Anti-patterns (Red Flag Patterns)

Pause the affected decision and review the design when detecting the following patterns:

Code Quality Anti-patterns

1. **Duplicating one responsibility across independently maintained locations** - Review whether the duplicated logic has one change reason and should have one owner 2. **Multiple responsibilities mixed in a single file** - Violates Single Responsibility Principle (SRP) 3. **Defining same content in multiple files** - Violates DRY principle 4. **Making changes without checking dependencies** - Potential for unexpected impacts 5. **Disabling code with comments** - Should use version control 6. **Error suppression** - Hiding problems creates technical debt 7. **Bypassing safety mechanisms (type systems, validation, contracts)** - Circumventing language's correctness guarantees

Design Anti-patterns

• **"Make it work for now" thinking** - Accumulation of technical debt
• **Patchwork implementation** - Unplanned additions to existing code
• **Optimistic implementation of uncertain technology** - Designing unknown elements assuming "it'll probably work"
• **Symptomatic fixes** - Surface-level fixes that don't solve root causes
• **Unplanned large-scale changes** - Lack of incremental approach

Fail-Fast Fallback Design Principles

Core Principle

Make all errors visible and traceable with full context. Prioritize primary code reliability over fallback implementations. Excessive fallback mechanisms mask errors and make debugging difficult.

Implementation Guidelines

Default Approach

• **Give every failure an explicit outcome**: propagate it, translate it to the boundary's error contract, or recover through an accepted fallback
• **Make failures explicit**: Errors should be visible and traceable
• **Preserve error context**: Include original error information when re-throwing

When Fallbacks Are Acceptable

• **Accepted recovery contract**: A requirement, Design Doc, existing boundary contract, or project policy defines why degraded behavior is preferable to failure
• **Business-critical continuity**: When partial functionality is better than none
• **Graceful degradation paths**: Clearly defined degraded service levels

Layer Responsibilities

• **Infrastructure Layer**:
• Preserve the original cause and operational context
• Propagate, translate, or return the failure in the form required by the caller's boundary contract
• Perform infrastructure-owned cleanup or retry only when that boundary owns it; business recovery decisions remain in the application layer

• **Application Layer**:
• Make business-driven error handling decisions
• Implement fallbacks only when an accepted recovery contract defines the degraded outcome
• Make fallback activation observable through the project's established logging, metrics, or user-visible state when diagnosis or recovery requires it

Error Masking Detection

**Review Triggers** (require design review):

• Adding an error handler that duplicates or fragments an existing recovery responsibility
• The same failure is caught at multiple layers without a single recovery owner
• Nested handlers obscure which state is committed, rolled back, or exposed
• A handler converts a failure to success/default output without an observable degraded-state contract
• Error handlers that return default values without logging

Another handler may remain when it covers a distinct failure mode with a documented recovery owner, state outcome, and observable signal.

**Before Implementing Any Fallback**: 1. Identify the accepted requirement, boundary contract, project policy, or Design Doc entry that defines this fallback 2. Document the business justification 3. Make activation observable at the boundary that owns diagnosis or recovery through one existing UI, log, or metric channel; when logging is that channel, log once with sensitive data redacted 4. Add new monitoring or alerting only when an operational requirement or project policy requires it

Implementation Pattern

AVOID: Silent fallback that hides errors
    <handle error>:
        return DEFAULT_VALUE  // Error hidden, debugging impossible

PREFERRED: Explicit failure with context
    <handle error>:
        <attach operation context>
        IF this boundary owns di