Utilidades IACómo explorar la arquitectura de un software con ayuda de la IA
| Para quién | Para quien diseña un sistema nuevo o replantea uno existente, ya sea en solitario o en equipo, y quiere contrastar ideas antes de comprometerse con una solución. |
|---|---|
| Tiempo estimado | Entre 1 y 2 horas para una exploración inicial, más el tiempo de validación con el equipo. |
| Categoría | Programación y datos |
Paso a paso
- Escribe requisitos y restricciones antes de pedir soluciones
Redacta qué debe hacer el sistema, cuántas personas lo usarán de forma realista, qué datos maneja, qué disponibilidad se espera y cuáles son los límites de presupuesto, plazo y conocimientos del equipo. Distingue lo imprescindible de lo deseable. Sin esos datos, el asistente propondrá arquitecturas de moda, probablemente sobredimensionadas. Indica también lo que ya está decidido y por qué. Cuanto más concreta sea la descripción de las restricciones, más útiles serán las alternativas, y más fácil descubrir que alguna opción popular no encaja contigo. - Pide varias alternativas, no una respuesta
Solicita al menos tres enfoques distintos, desde el más simple hasta el más sofisticado, y que cada uno incluya ventajas, inconvenientes, coste de mantenimiento y condiciones en las que dejaría de ser adecuado. Pide expresamente que incluya la opción de no cambiar nada o de mantener un diseño sencillo. Evita preguntas del tipo cuál es la mejor arquitectura, porque inducen una respuesta única y segura. Plantear alternativas te obliga a pensar en los compromisos, que es el verdadero contenido de una decisión de diseño. - Examina los compromisos con preguntas incómodas
Para cada alternativa pregunta qué ocurre si el volumen se multiplica, si cae un componente, si cambia un requisito o si se marcha la persona que mejor conoce la pieza. Pide los puntos únicos de fallo, los costes ocultos y qué tendrías que aprender. Cuestiona las afirmaciones del asistente sobre rendimiento o escalabilidad: no son datos medidos, son razonamientos generales. Toda cifra o límite que te dé debe tratarse como una suposición pendiente de medir en tu propio contexto y con tus propios datos. - Representa y revisa el diseño de forma sencilla
Pide una descripción en texto o un esquema simple de componentes, flujos de datos y fronteras, y comprueba que lo entiende todo el equipo. Revisa que cada pieza tenga una responsabilidad clara y que los datos sensibles tengan un tratamiento definido. Pide al asistente que busque inconsistencias entre el esquema y los requisitos, y verifica tú sus hallazgos. Un diseño que no se puede explicar en una pizarra en pocos minutos suele ser demasiado complejo para el problema que pretende resolver. - Valida con una prueba pequeña y con personas
Antes de adoptar una opción, construye un prototipo mínimo o una prueba de concepto que ponga a prueba el riesgo mayor: una integración, un volumen, una latencia. Mide con datos propios en lugar de confiar en estimaciones generales. Comenta las alternativas con compañeros con experiencia, con quien operará el sistema y con quien lo pagará. Un asistente no conoce tu organización, tus contratos ni tus sistemas actuales, y esas realidades suelen decantar la decisión mucho más que la elegancia técnica del diseño. - Registra la decisión y su fecha de revisión
Anota la decisión tomada, las alternativas descartadas, los motivos y las suposiciones en las que se apoya, como un volumen esperado o una capacidad del equipo. Define qué señales indicarían que hay que revisarla. Pide al asistente un borrador del registro y corrígelo con precisión. Una arquitectura no es definitiva: el contexto cambia, y poder reconstruir por qué se decidió algo evita repetir debates y permite cambiar de rumbo con criterio cuando las suposiciones dejen de cumplirse.
Prompt de ejemplo
Rellena los corchetes con tu caso antes de pegarlo en un asistente:
Actúa como arquitecto de software que prioriza la sencillez y expone sus dudas. Sistema: [DESCRIPCIÓN]. Requisitos imprescindibles: [LISTA]. Deseables: [LISTA]. Usuarios previstos: [ESTIMACIÓN REALISTA]. Datos que maneja: [TIPO Y SENSIBILIDAD]. Restricciones: equipo de [NÚMERO] personas con conocimientos de [TECNOLOGÍAS], presupuesto [RANGO], plazo [PLAZO]. Propón tres alternativas de arquitectura, desde la más simple, incluyendo mantener lo actual si existe. Para cada una: ventajas, inconvenientes, costes de mantenimiento, riesgos y condiciones en las que dejaría de ser adecuada. No elijas una como definitiva: indica qué debería medir o validar. Marca todo lo que sea suposición.
Qué esperar
Obtendrás un conjunto de alternativas razonadas y preguntas útiles. También es probable que algunas propuestas sean más complejas de lo necesario, que las afirmaciones de rendimiento sean genéricas y que se ignoren restricciones que no mencionaste. Es un punto de partida para la discusión, no un plano para construir.
Cómo verificar el resultado
- Comprueba que cada alternativa respeta tus requisitos imprescindibles y tus restricciones reales.
- Mide con un prototipo y con tus datos cualquier afirmación sobre rendimiento o capacidad.
- Contrasta las opciones con alguien que opere sistemas similares y con el equipo que lo mantendrá.
- Revisa si el diseño es explicable en pocos minutos y si hay puntos únicos de fallo no mencionados.
Errores comunes
- Preguntar cuál es la mejor arquitectura y aceptar la respuesta como definitiva.
- No indicar el tamaño real del equipo ni el volumen esperado, y acabar con un diseño sobredimensionado.
- Tratar las cifras de rendimiento del asistente como mediciones.
- No registrar el motivo de la decisión, de modo que nadie sabe cuándo revisarla.
Riesgos y límites
El asistente razona sobre patrones generales y puede recomendar soluciones de moda, ignorar tu contexto o presentar con seguridad afirmaciones sin fundamento sobre rendimiento, costes o compatibilidad. No conoce tu organización, tus contratos ni tu infraestructura. Una mala decisión de arquitectura es cara de revertir. Cuando el sistema afecte a datos personales, pagos, seguridad física o continuidad de un servicio importante, la decisión debe contar con profesionales cualificados y con validación independiente. No pegues información confidencial sin autorización y considera siempre las propuestas como hipótesis.
Preguntas frecuentes
¿Puede la IA decidir la arquitectura por mí?
No debería. Puede ayudarte a ver alternativas y compromisos, pero la decisión depende de tus requisitos, tu equipo y tu contexto, que ella no conoce del todo. Úsala como interlocutor crítico y valida cada propuesta con pruebas y con personas.
¿Por qué insistir en alternativas y no en una recomendación?
Porque una recomendación única oculta los compromisos. Al comparar varias opciones ves qué se gana y qué se pierde con cada una, y detectas antes las suposiciones débiles. Además, reduces el riesgo de adoptar sin cuestionar una solución de moda.
¿Cómo evito una arquitectura demasiado compleja?
Pide siempre incluir la opción más simple y las condiciones en que dejaría de bastar. Añade complejidad solo cuando una necesidad real y medida lo justifique, y no por anticipar volúmenes o requisitos que quizá nunca lleguen.