Architecture check before feature implementation #495
Description
Is your feature request related to a problem? Please describe.
When I ask an AI coding agent to implement a seemingly simple feature, it often “pushes it through” without recognizing that the current architecture makes it risky or expensive. This leads to brittle hacks, security gaps, performance regressions, and rising tech debt.
Describe the solution you'd like
If a feature seems conceptually simple (e.g., "only admins can download billing reports"), but the implementation is not simple, add an explicit “architecture awareness” step before implementation: the agent should analyze the existing design, identify architectural constraints (data model, auth boundaries, state ownership, deletion semantics, etc.), and either (a) propose a clean approach, (b) recommend a prerequisite refactor, or (c) flag the request as high-risk and ask for direction. The agent should surface tradeoffs and a short plan, not just code.
Describe alternatives you've considered
- Rely on human code review to catch architectural issues.
- Add static checklists or project-specific guidelines for the agent.
- Restrict the agent to small/isolated changes only.
- YOLO.
Additional context
Common failure cases include: unread/read state without backend support, RBAC added inconsistently across UI/API, and “undo delete” in systems using hard deletes and cascading cleanup. The feature should prioritize early detection and clear recommendations over forcing an implementation.