The ADI Cycle
A structured approach to architectural decisions. Understand it in 10 minutes.
The Problem
AI coding assistants are remarkably capable. They understand your codebase, generate solutions, and explain complex patterns. But when it comes to architectural decisions, there's a problem.
Context Loss
The reasoning behind a decision disappears when the chat session ends. Three months later, no one remembers why you chose Saga over Choreography.
Anchoring Bias
The first solution that comes up often becomes THE solution. Alternatives aren't systematically explored or compared.
No Audit Trail
When assumptions change, there's no way to revisit decisions. You end up re-debating the same questions.
The Solution: ADI Cycle
The ADI cycle is based on three modes of reasoning from Pragmatic philosophy:
Abduction — Generate plausible hypotheses from observations
Deduction — Derive logical consequences from hypotheses
Induction — Test hypotheses against empirical evidence
quint-code implements this cycle with 5 phases, plus utility commands:
Hypothesize
/q1-hypothesize What: Generate 3-5 competing hypotheses that could solve the problem. Each should be distinct, not variations of the same idea.
Why: Avoid anchoring on the first solution. Force exploration of the solution space before evaluation.
Output: Hypotheses are saved to
.quint/knowledge/L0/ as unverified observations.
Verify
/q2-verify What: Check each hypothesis for logical consistency. Does it contradict itself? Does it violate known constraints?
Why: Eliminate impossible or contradictory approaches before spending time gathering evidence.
Output: Hypotheses that pass move
to .quint/knowledge/L1/ (Reasoned level).
Test / Research
/q3-validate What: Gather empirical evidence. Run internal tests (benchmarks, simulations) or external research (docs, case studies).
Why: Ground decisions in reality. Theory is good, but evidence is better.
Output: Evidence is attached to
hypotheses. Verified ones move to .quint/knowledge/L2/.
Audit
/q4-audit What: Apply the Weakest Link (WLNK) principle. Check for cognitive biases. Look for blind spots.
Why: The system is only as strong as its weakest component. Find it before production does.
WLNK: Assurance level = min(all evidence), never average. One L0 claim drops the whole hypothesis.
Decide
/q5-decide What: Create a Design Rationale Record (DRR) documenting the decision, alternatives considered, evidence, and conditions under which to revisit.
Why: Preserve context for future you (and your team). When assumptions change, you'll know where to look.
Output: A searchable, dated DRR
with full rationale in .quint/decisions/.
Key Concepts
Assurance Levels
- L0 — Observation (unverified)
- L1 — Reasoned (logically consistent)
- L2 — Verified (empirically tested)
WLNK
Weakest Link principle: A chain is only as strong as its weakest link. Overall assurance = min(all evidence levels), never average.
Transformer Mandate
"AI generates options. You decide." A system cannot transform itself. The AI proposes, the human disposes.
When to Use
Use quint-code for:
- Architectural decisions with long-term impact
- Team decisions that need documentation
- Unfamiliar territory (new tech, new patterns)
- Decisions you'll need to justify later
- Complex problems with multiple valid approaches
Skip quint-code for:
- Quick fixes and bug patches
- Obvious solutions with no alternatives
- Easily reversible decisions
- Time-critical emergencies
- Personal preference choices (tabs vs spaces)
Ready to try it?
Install quint-code and run your first hypothesis cycle.