Un Veterano de 30 Años Explica Por Qué la IA No Puede Reemplazar a los Arquitectos de Software

Por Qué la Arquitectura Práctica Sigue Ganando en la Era de la IA

Dennis Doma es un veterano de la ingeniería de software con 30 años de experiencia, Microsoft MVP y creador de Fluent Assertions, una de las bibliotecas de testing open source más populares del ecosistema .NET. Como arquitecto de software en Aviva Solutions, ha pasado décadas combatiendo la complejidad que destruye el software empresarial. En esta conversación con Beyond Coding, comparte cómo las herramientas de IA están transformando su flujo de trabajo — y dónde se quedan cortas.

Sobre los arquitectos que dejan de programar: “If you stop coding, if you actually stop building production systems, you lose that experience. If I had stopped coding for the last 3 years, I would have probably missed the whole AI scene.” (“Si dejas de programar, si dejas de construir sistemas en producción, pierdes esa experiencia. Si hubiera dejado de programar los últimos 3 años, probablemente me habría perdido todo el panorama de la IA.”) Doma argumenta que los arquitectos de software que se refugian en diagramas de alto nivel pierden la capacidad de juzgar si las soluciones realmente funcionan. El ciclo de retroalimentación práctico — construir, lanzar, corregir errores — es insustituible.

Sobre la autoría del código generado por IA: “I treat all AI-generated code as mine.” (“Trato todo el código generado por IA como mío.”) Cuando GitHub Copilot construyó la mayor parte de su nueva biblioteca de mocking open source a partir de un único issue, Doma quedó impresionado — pero asumió la responsabilidad de inmediato. Revisa línea por línea los tests generados por IA, refactoriza el código que no cumple sus estándares y actualiza iterativamente los archivos de instrucciones para que las generaciones futuras mejoren. El código no es “código de la IA” — es su responsabilidad.

Sobre la complejidad accidental: Los equipos que copian y pegan patrones arquitectónicos a ciegas — arquitectura de cebolla, arquitectura limpia — sin entender por qué existen. Los desarrolladores con 10 a 15 años de experiencia se vuelven “excesivamente” apegados a los principios SOLID, esgrimiéndolos como escudos contra el pragmatismo. “Yeah, but you don’t need this abstraction. Yeah, but it’s ready for the future. You don’t need this abstraction. That’s a smell.” (“Sí, pero no necesitas esta abstracción. Sí, pero está preparada para el futuro. No necesitas esta abstracción. Eso es una señal de alerta.”)

Sobre los desarrolladores junior y la IA: Emergen dos arquetipos — quienes evitan la IA para preservar sus habilidades de aprendizaje, y quienes la usan en todo sin comprender el resultado. Doma se encontró con un desarrollador cuyo pull request funcionaba (los tests pasaban) pero que no podía explicar qué hacía el código. Su respuesta: “I don’t care if you don’t practice TDD properly, but make sure the code is designed the way we want it and we can maintain it.” (“No me importa si no practicas TDD correctamente, pero asegúrate de que el código esté diseñado como queremos y de que podamos mantenerlo.”)

Sobre la sostenibilidad del open source: El equipo de Tailwind despidió al 75% de su plantilla porque la IA puede replicar sus componentes premium. La réplica de Doma: la gente subestima crónicamente la complejidad detrás de las bibliotecas maduras. “He pasado 15 años perfeccionando Fluent Assertions. Alguien dice ‘puedo construir esto en un par de días’. Claro.” El código open source puede convertirse en tu código a mantener — planifica en consecuencia.

5 Lecciones de un Arquitecto de Software sobre el Desarrollo Asistido por IA

• Los tests son tu red de seguridad — Ya sea código humano o generado por IA, los tests robustos son el validador definitivo. “Si tratas el software como una caja negra y tu red de seguridad son los tests, debes prestarles especial atención.”
• La documentación se multiplica con la IA — Los ADRs, los mensajes de commit y los registros de decisiones se vuelven mucho más valiosos cuando las herramientas de IA pueden recorrerlos. Las empresas que invierten en contexto rico estarán “a años luz por delante.”
• Deja que los equipos elijan sus propias herramientas de IA — No estandarices en una sola herramienta. “Deja que la gente use la herramienta de IA que quiera porque cambia constantemente.” Haz seguimiento del uso, amplía las licencias, pero no limites la experimentación.
• El contexto es como la leche — Doma aprendió por las malas sobre la compresión de contexto: su IA fusionó y subió código experimental a main. Las ramas de funcionalidades y los commits frecuentes son barreras de seguridad esenciales.
• El open source sigue valiendo la pena — “Das, pero recibes muchísimo a cambio. Conocimiento, experiencia, nuevas herramientas, nuevas perspectivas, visibilidad.” El retorno de la inversión no es solo el código — es el ciclo de retroalimentación de la comunidad.

Qué Significa Esto para los Equipos de Software Potenciados por IA

La perspectiva de Doma atraviesa el ruido: las herramientas de codificación con IA son genuinamente transformadoras en velocidad de ejecución, pero no reemplazan el juicio arquitectónico que proviene de décadas de experiencia práctica. Los desarrolladores que prosperarán serán quienes usen la IA como una herramienta poderosa mientras mantienen el pensamiento crítico — entendiendo por qué existen los patrones, no solo aplicándolos. Para las organizaciones, el mensaje es claro: inviertan en documentación, calidad de tests y mentoría arquitectónica. Estos son los activos que se multiplican cuando la IA se encarga de escribir el código.