Formalizar en 30-60 minutos un ADR riguroso para cada decisión estructurante, que tomaría 2-3 horas redactar desde cero.
Los ADR (Registros de Decisiones de Arquitectura) documentan las decisiones estructurantes: ¿por qué PostgreSQL en lugar de MongoDB, por qué Kafka en lugar de RabbitMQ, por qué tal patrón de autenticación. Bien redactados, ahorran años de "¿por qué elegimos esto de nuevo?" y facilitan la incorporación de nuevos miembros. La IA permite producirlos rápidamente con rigor. Esta guía presenta el workflow.
Flujo de trabajo paso a paso
1
Describir el contexto de la decisión
Qué problema se resuelve, qué restricciones (perf, equipo, presupuesto, time-to-market), qué opciones se consideraron, quién decide y quién se ve impactado.
2
Listar las opciones consideradas
Al menos 3 opciones serias con sus características. La IA ayuda a estructurar (no olvidar lo obvio ni inventar lo irreal).
3
Comparar en criterios relevantes
Criterios según el contexto: rendimiento, escalabilidad, curva de aprendizaje, ecosistema, costo, madurez, lock-in. Puntuación en cada opción.
4
Decidir y documentar el porqué
Decisión adoptada + razones claras. Especialmente: consecuencias positivas Y negativas, condiciones de éxito, señales que justificarían revisitar.
5
Versionar en el repo
Formato markdown en /docs/adr/. Numerado y fechado. Permanece consultable mucho tiempo después de que los protagonistas abandonen el equipo.
Prompts copiables
ADR completo sobre una decisión técnica
Eres arquitecto de software senior. Formaliza un ADR para esta decisión:nn**Contexto**: [PROBLEMA A RESOLVER]n**Restricciones**: [PERF, EQUIPO, PRESUPUESTO, TIMING]n**Opciones consideradas**: [LISTA 3-5 OPCIONES]n**Decisión adoptada**: [OPCIÓN ELEGIDA]n**Stack actual**: [CONTEXTO TECH]nnProducir un ADR en el formato Michael Nygard:nn## Statusn[Proposed / Accepted / Deprecated / Superseded by X]nn## Contextn[3-5 párrafos: problema, restricciones, qué desencadenó la reflexión]nn## Options Consideredn### Option 1: [NOMBRE]n- Prosn- Contrasn- Costos (aprendizaje, deuda, infraestructura)nn### Option 2: [NOMBRE]n[idem]nn## Decisionn[Opción adoptada + razones claras]nn## Consequencesn### Positiven[3-5 consecuencias positivas esperadas]nn### Negativen[2-4 consecuencias negativas o compromisos asumidos]nn## Conditions to Revisitn[Señales que justificarían reconsiderar esta decisión en 12-24 meses]nnMarca [A VERIFICAR] cualquier cifra incierta (perf, costos).
Comparativa tecnologías multi-criterios
Para esta decisión: [TIPO DE TECH — ej: message broker, base de datos, framework frontend]nn**Contexto**: [DETALLES]n**Restricciones**: [LISTA]nnCompara estas opciones en criterios estructurantes:nn[OPCIÓN 1] vs [OPCIÓN 2] vs [OPCIÓN 3]nnCriterios:n1. **Rendimiento** (latencia, throughput, recursos)n2. **Escalabilidad** (horizontal, vertical, límites)n3. **Madurez y ecosistema** (versiones estables, comunidad, documentación)n4. **Curva de aprendizaje** (equipo actual, contratación)n5. **Lock-in y portabilidad**n6. **Costo total** (licencia, infraestructura, operaciones)n7. **Seguridad y cumplimiento**nnFormato: tabla comparativa con scoring /10 por criterio, luego recomendación argumentada.
Auditoría de un ADR existente
Audita este ADR:nn[ADR]nnProducir:n1. **Fortalezas**: qué está bien hecho (rigor, claridad, exhaustividad)n2. **Debilidades**: qué falta (opciones faltantes, consecuencias negativas subestimadas, sin plan B)n3. **Actualizaciones necesarias**: dado cómo evolucionó desde la redacción, qué ha cambiado en el panorama técnicon4. **Recomendación**: ADR aún válido / a actualizar / a reconsiderarnnSé constructivo y factual.
Herramientas recomendadas
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.
Por qué : Le meilleur reasoning sur les choix techniques complexes nécessitant la pesée multi-critères et l'anticipation des conséquences.
