Formalizzare in 30-60 minuti un ADR rigoroso per ogni scelta strutturale che richiederebbe 2-3 ore per essere redatto da zero.
Gli ADR (Architecture Decision Records) documentano le scelte strutturali: perché PostgreSQL invece di MongoDB, perché Kafka invece di RabbitMQ, perché questo pattern di autenticazione. Quando ben redatti, salvano anni di "perché abbiamo scelto questo?" e facilitano l'onboarding. L'IA permette di produrli rapidamente con rigore. Questa guida presenta il workflow.
Workflow passo dopo passo
1
Descrivere il contesto della decisione
Quale problema si risolve, quali vincoli (performance, team, budget, time-to-market), quali opzioni sono state considerate, chi decide e chi è coinvolto.
2
Elencare le opzioni considerate
Almeno 3 opzioni serie con le loro caratteristiche. L'IA aiuta a strutturare (senza dimenticare l'ovvio né inventare l'irrealistico).
3
Confrontare su criteri rilevanti
Criteri secondo il contesto: performance, scalabilità, curva di apprendimento, ecosistema, costo, maturità, lock-in. Assegna un punteggio a ogni opzione.
4
Decidere e documentare il perché
Decisione scelta + ragioni chiare. Soprattutto: conseguenze positive E negative, condizioni di successo, segnali che giustificherebbero di riconsiderare.
5
Versionare nel repo
Formato markdown in /docs/adr/. Numerato e datato. Rimane consultabile molto tempo dopo che i protagonisti hanno lasciato il team.
Prompt copiabili
ADR completo su una scelta tecnica
Sei un architetto software senior. Formalizza un ADR per questa decisione:nn**Contesto**: [PROBLEMA DA RISOLVERE]n**Vincoli**: [PERFORMANCE, TEAM, BUDGET, TIMING]n**Opzioni considerate**: [LISTA 3-5 OPZIONI]n**Decisione scelta**: [OPZIONE SELEZIONATA]n**Stack attuale**: [CONTESTO TECNICO]nnProduca un ADR nel formato Michael Nygard:nn## Statusn[Proposed / Accepted / Deprecated / Superseded by X]nn## Conteston[3-5 paragrafi: problema, vincoli, cosa ha innescato la riflessione]nn## Opzioni consideraten### Opzione 1: [NOME]n- Pron- Contron- Costi (apprendimento, debito, infrastruttura)nn### Opzione 2: [NOME]n[idem]nn## Decisionen[Opzione scelta + ragioni chiare]nn## Conseguenzen### Positivan[3-5 conseguenze positive attese]nn### Negativan[2-4 conseguenze negative o compromessi assunti]nn## Condizioni per riconsideraren[Segnali che giustificherebbero di mettere in discussione questa decisione tra 12-24 mesi]nnMarchia [DA VERIFICARE] ogni cifra incerta (performance, costi).
Comparativo tecnologie multi-criteri
Per questa scelta: [TIPO DI TECH — es: message broker, database, framework frontend]nn**Contesto**: [DETTAGLI]n**Vincoli**: [LISTA]nnConfronta queste opzioni su criteri strutturanti:nn[OPZIONE 1] vs [OPZIONE 2] vs [OPZIONE 3]nnCriteri:n1. **Performance** (latenza, throughput, risorse)n2. **Scalabilità** (orizzontale, verticale, limiti)n3. **Maturità ed ecosistema** (versioni stabili, comunità, documentazione)n4. **Curva di apprendimento** (team attuale, reclutamento)n5. **Lock-in e portabilità**n6. **Costo totale** (licenza, infrastruttura, operazioni)n7. **Sicurezza e conformità**nnFormato: tabella comparativa con punteggio /10 per criterio, poi raccomandazione argomentata.
Audit di un ADR esistente
Audit questo ADR:nn[ADR]nnProduca:n1. **Punti forti**: cosa è ben fatto (rigore, chiarezza, completezza)n2. **Debolezze**: cosa manca (opzioni mancanti, conseguenze negative sottostimate, nessun piano B)n3. **Aggiornamenti necessari**: considerato l'evoluzione dal momento della redazione, cosa è cambiato nel panorama tecnicon4. **Raccomandazione**: ADR ancora valido / da aggiornare / da riconsiderarennRimani costruttivo e fattuale.
Strumenti consigliati
Claude Opus 4.5
★ 4.9 (92) · 20 USD/mois
Claude Opus 4.5 : modèle premium d’Anthropic pour code, agents et tâches complexes en entreprise.
Perché : Le meilleur reasoning sur les choix techniques complexes nécessitant la pesée multi-critères et l'anticipation des conséquences.
