Overengineering en la era de la IA

Hay una palabra mágica que, si te apasiona el diseño de sistemas, los patrones y la calidad del software en general, seguro que te habrán echado en cara alguna vez: Overengineering. Abstracciones prematuras, arquitecturas con más carga cognitiva y boilerplate, microservicios, infra preparada para escalar desde el día uno… Desde siempre, uno de los mayores retos en la toma de decisiones técnicas ha sido tener el criterio suficiente para evaluar el momento, las necesidades y el tipo de proyecto antes de elegir una solución u otra. No es lo mismo una startup en pre-seed, validando si existe product-market fit y necesitando iterar o pivotar rápido, que un producto de software para una empresa consolidada que ya sabe que necesita esa solución para seguir operando. Esto era muy evidente cuando el coste de implementar soluciones robustas, mantenibles y escalables era muy alto. Se necesitaban equipos más grandes y mucho más tiempo para construirlas. Hablábamos de meses de diferencia. Pero ¿qué pasa ahora, cuando la diferencia en el código generado depende en gran parte de las decisiones que se toman en la fase de planificación y en los prompts iniciales del ciclo de desarrollo asistido por IA? Lo que estamos viendo ya es que la IA reduce drásticamente el coste de implementación. Añadir pruebas unitarias, observabilidad, seguridad o una arquitectura más sólida sigue teniendo un coste importante de criterio, decisiones y estructura. Pero la diferencia ya no siempre se mide en meses si no en horas o días. ¿Justifica esto hacer overengineering desde el día uno? ¿O el problema sigue siendo el mismo, porque el coste de implementar la complejidad ha bajado, pero el de entenderla, operarla y mantenerla no? En mi opinión, en productos grandes y consolidados, cada vez hay menos excusas para no sentar buenas bases y aplicar los criterios y patrones de ingeniería adecuados desde el día uno (ya lo pensaba antes). Sin embargo, en fases early sigue teniendo sentido iterar rápido y aprovechar esa velocidad. Porque la IA reduce el coste de construir sistemas complejos, pero no elimina el coste de entenderlos, operarlos ni mantenerlos. Y tú, ¿qué opinas?