ADR (Architecture Decision Records)
Formalize in 30-60 minutes a rigorous ADR for each structuring choice, that would take 2-3 hours from scratch.
ADRs (Architecture Decision Records) document structuring choices: why PostgreSQL rather than MongoDB, why Kafka rather than RabbitMQ, why such authentication pattern. Well-written, they save years of 'why did we choose this again?' and ease onboarding. AI lets you produce them quickly with rigor.
Step-by-step workflow
Describe decision context
What problem we're solving, what constraints, what options were considered, who decides and who's impacted.
List considered options
At least 3 serious options with their characteristics. AI helps structure (don't forget evidences, don't invent unrealistic ones).
Compare on relevant criteria
Criteria per context: performance, scalability, learning curve, ecosystem, cost, maturity, lock-in. Score each option.
Decide and document why
Retained decision + clear reasons. Above all: positive AND negative consequences, success conditions, signals justifying revisit.
Version in repo
Markdown format in /docs/adr/. Numbered and dated. Stays consultable long after protagonists leave the team.
Copyable prompts
2 tested and optimized prompts. Adapt the bracketed variables [VARIABLE] to your context.
Complete ADR on a technical choice
You're a senior software architect. Formalize an ADR for this decision: **Context**: [PROBLEM TO SOLVE] **Constraints**: [PERF, TEAM, BUDGET, TIMING] **Considered options**: [3-5 OPTION LIST] **Retained decision**: [CHOSEN OPTION] **Current stack**: [TECH CONTEXT] Produce an ADR in Michael Nygard format: ## Status [Proposed / Accepted / Deprecated] ## Context [3-5 paragraphs: problem, constraints] ## Options Considered ### Option 1 - Pros - Cons - Costs ## Decision [Retained option + clear reasons] ## Consequences ### Positive [3-5 expected positive consequences] ### Negative [2-4 assumed negative consequences or compromises] ## Conditions to Revisit [Signals to re-question this decision in 12-24 months]
Multi-criteria technology comparison
For this choice: [TECH TYPE — e.g., message broker, database, frontend framework] **Context**: [DETAILS] **Constraints**: [LIST] Compare these options on structuring criteria: [OPTION 1] vs [OPTION 2] vs [OPTION 3] Criteria: 1. **Performance** (latency, throughput, resources) 2. **Scalability** (horizontal, vertical, limits) 3. **Maturity and ecosystem** 4. **Learning curve** 5. **Lock-in and portability** 6. **Total cost** (license, infrastructure, ops) 7. **Security and compliance** Format: comparative table with /10 scoring per criterion, then argued recommendation.
Top tools for this use case
Curated selection of the 3 best AI tools for adr (architecture decision records).
Why for this use case: Best reasoning on complex tech choices needing multi-criteria weighing and consequence anticipation.
Why for this use case: Excellence on structured rigorous ADR writing. Michael Nygard format or variant.
Why for this use case: To benchmark in real time with fresh sources (current versions, feedback, up-to-date comparisons).
Estimated ROI
Time saved
70% on writing (30-60 min vs 2-3h)
Quality gain
Systematically rigorous ADRs, explicit negative consequences
Stack cost
$20-30/month
Estimates based on 2026 benchmarks and user feedback. Actual ROI depends on your context.
Frequently asked questions
Should every decision have an ADR?
No. Rule: ADR for structuring decisions (engaging 2+ years, expensive to reverse, impacting multiple teams). For implementation details: code comments, service READMEs. Too many ADRs = none read.
Can AI decide for the architect?
No. AI produces rigorous comparison, but decision involves: fine team knowledge, internal political constraints, business intuitions, long-term vision. The 'so what' stays human.
ADR vs RFC: difference?
RFC (Request for Comments): before decision, to discuss and challenge. ADR: after decision, to document and justify over time. Many teams use both: RFC in discussion, ADR once decided.
How to maintain ADRs over time?
Strict status tracking: Proposed / Accepted / Deprecated / Superseded by ADR-XXX. When decision superseded, new ADR must reference old. Makes history traceable.