Why a Methodology
AI can accelerate analysis and implementation, but faster artifact production is not the same as a better product. The difficult work includes agreeing on meaning, keeping components coherent, checking behavior and deciding who may approve consequential changes.
This method makes those responsibilities explicit. Its value must be evaluated through actual project evidence, including failures and costs; the existence of this documentation is not proof that the method works.
The core tension
Generated code and documentation can look plausible while missing a business rule, integration constraint or failure case. Human and AI reviewers can also share the same mistaken assumptions. Short feedback loops help only when the team knows what is being validated and by whom.
A methodology earns its overhead when it helps the team detect and resolve material failures.
Three failure modes
1. Locally correct, globally incoherent
A component can satisfy its immediate request while violating a shared rule or another service's contract. Supply bounded, identifiable project context and approved architectural constraints. Reconcile changes that affect those boundaries instead of assuming each agent has a complete picture.
2. Plausible but wrong at runtime
An implementation may pass visual review yet fail under the actual runtime identity, data shape or provider response. Combine appropriate unit, contract, integration and journey evidence. Use independently grounded expectations, known passing and adverse cases, and explicit treatment of unavailable boundaries.
3. Progress mistaken for authority
A generated specification is not approved business intent. A successful test is not release permission. A meeting transcript is not automatically shared evidence. Keep proposed, reviewed, approved and executed states distinct, tied to the exact artifacts and authorized actors.
The response
- Design before code. Agree on the relevant intent, scope, risks and approach before implementation. Reuse a valid baseline for ordinary changes; revisit affected assumptions when they change.
- Evidence over claims. Record actual scope, execution, outcomes and gaps. A green exit or an absent alert is not enough when required work was never assessed.
- Quality as architecture. Put suitable checks into the delivery path and test that they run and affect the intended action. Instructions, advisory hooks and review remain distinct from server-side enforcement.
- Accountable collaboration. Let AI prepare and explain artifacts while business and engineering owners retain the decisions assigned to them.
Text equivalent: business input is reviewed by the BA, exact intent is approved by its owner, and engineering returns evidence for validation. This collaboration loop does not replace separate release authority or guarantee a particular delivery speed.
Where to next
- Verifiable Benefits — mechanisms, evaluation steps and limits.
- Governed factory — authority and execution across the lifecycle.
- Philosophy — the principles and their rationale.