IBS explica cómo las redes neuronales cambian el diseño de software y por qué no sustituirán al arquitecto

Las redes neuronales han entrado en un terreno que durante mucho tiempo se consideró exclusivamente humano: el diseño de sistemas de software. Hoy, los grandes modelos de lenguaje pueden montar un borrador de arquitectura, proponer un conjunto de servicios, señalar puntos débiles y desglosar rápidamente una solución según sus compromisos. Pero entre la respuesta rápida de un modelo y una arquitectura real, capaz de soportar el aumento de carga, los requisitos de seguridad y la presión del negocio, sigue habiendo una gran distancia.

El interés por el tema es comprensible. El arquitecto de software trabaja no solo con código, sino con restricciones: plazos, presupuesto, sistemas heredados, integraciones, requisitos de fiabilidad y la estructura organizativa del equipo. Aquí es donde la IA generativa resulta especialmente tentadora.

En lugar de dedicar horas a preparar opciones, se pueden obtener en minutos varios enfoques: monolito frente a microservicios, integraciones síncronas frente a un bus de eventos, PostgreSQL frente a almacenes especializados. El modelo puede reunir rápidamente una lista de pros y contras, sugerir patrones como CQRS, event-driven o arquitectura hexagonal e incluso esbozar la base de un diagrama C4. Esto se nota sobre todo en proyectos donde hay que calcular deprisa varios escenarios de evolución del sistema y ver de antemano qué supondrá cada elección para el equipo y la infraestructura.

El valor práctico de la IA en este papel no está en que entregue de inmediato la solución perfecta, sino en que acelera las primeras iteraciones. Los LLM manejan bien los escenarios típicos: descomponer un sistema en módulos, identificar requisitos no funcionales, preparar preguntas para el cliente, detectar riesgos arquitectónicos y comparar patrones conocidos. Para el arquitecto es una forma cómoda de redactar rápido un borrador de ADR, comprobar que no se han pasado por alto restricciones básicas y obtener una segunda opinión antes de debatir con el equipo. Donde una persona tendría que reunir material de distintos documentos y notas, el modelo reduce drásticamente el tiempo de arranque.

Pero los puntos débiles aparecen precisamente en el paso de lo general a lo concreto. Los modelos de lenguaje suenan seguros incluso cuando se equivocan. Pueden proponer una complejidad excesiva, ignorar dependencias reales entre sistemas, subestimar el coste de mantenimiento o confundir las prioridades del negocio con la pureza técnica.

La arquitectura casi nunca se construye en el vacío: hay que tener en cuenta la madurez del equipo, las competencias disponibles, los requisitos de los reguladores, las restricciones contractuales, el coste de un fallo e incluso la política interna de la empresa. El modelo no asume la responsabilidad plena de las consecuencias de una elección, así que no puede sustituir a una persona allí donde hace falta una decisión final y defenderla ante el negocio, el desarrollo y la operación.

Otra cuestión es hasta qué punto la IA entiende realmente la arquitectura, en lugar de reproducir plantillas conocidas. En tareas típicas esto no siempre importa: si hay que comparar rápido Kafka y RabbitMQ o reunir pros y contras de un enfoque de microservicios, la utilidad del modelo es evidente. Pero cuanto menos estándar es el contexto, más caro resulta una respuesta superficial.

Un buen arquitecto evalúa no solo el stack tecnológico, sino también el camino de implantación: cómo migrar sin detener el servicio, dónde surgirán cuellos de botella, qué equipos pasarán a depender unos de otros y qué ocurrirá dentro de un año si el tráfico se multiplica por diez. Esas decisiones exigen no generar texto, sino criterio de ingeniería basado en la experiencia y en la comprobación de hipótesis.

De ahí se desprende una conclusión bastante sobria. La IA ya es útil para el arquitecto como acelerador del pensamiento: para preparar opciones, estructurar el debate, encontrar riesgos olvidados y redactar documentación preliminar. Pero por ahora no elimina el papel del arquitecto. Más bien al contrario: cuanto más accesibles son los modelos, más importa la persona capaz de distinguir una respuesta verosímil de una solución viable. A corto plazo no ganarán los equipos que intenten «sustituir al arquitecto por GPT», sino los que integren la IA en el proceso de arquitectura como herramienta de análisis rápido, revisión crítica y decisiones más meditadas.