La conversación sobre IA y desarrollo de software está polarizada entre dos extremos igual de inútiles: los que dicen que la IA va a hacer irrelevantes a los programadores, y los que dicen que es solo una herramienta más sin mayor impacto. Ambos se equivocan. Y ambos se equivocan de la misma manera: pensando en código, cuando el cambio está ocurriendo en una capa mucho más profunda.

El problema con la pregunta equivocada

Cuando alguien pregunta “¿puede la IA escribir código?”, la respuesta es sí, claramente. Pero esa es la pregunta equivocada. La pregunta correcta es: ¿qué parte del trabajo de un ingeniero es escribir código?

Si llevas más de tres años en la industria, sabes la respuesta: una fracción pequeña. La mayor parte del tiempo la pasas entendiendo qué problema quieres resolver, diseñando sistemas que sean mantenibles, negociando trade-offs con stakeholders que tienen objetivos contradictorios, debugueando comportamientos emergentes que no estaban en ningún spec, y mentorizando a gente que está aprendiendo.

La IA puede generar código. No puede hacer nada de lo demás. No todavía. Y cuando lo haga, habremos cambiado la definición de “ingeniero” de la misma manera que lo hicieron los compiladores, los frameworks, y el cloud antes que ella.

El cambio real: el coste de la exploración

Lo que sí está cambiando, ya, hoy, es el coste de explorar un espacio de soluciones.

Antes, probar una arquitectura alternativa tenía un coste altísimo: días de implementación para demostrar que una idea era inviable. Ese coste hacía que mucha gente tomara decisiones basadas en intuición y experiencia, porque explorar era caro.

Con herramientas de IA generativa, puedo tener un prototipo funcional de una arquitectura alternativa en horas. Puedo explorar tres enfoques distintos antes de decidir cuál vale la pena desarrollar en profundidad. El coste de la duda disminuye, y eso cambia cómo se toman las decisiones de diseño.

Esto es un cambio genuinamente importante. No es “la IA escribe el código por ti”. Es “la IA reduce el coste de exploración hasta el punto en que puedes ser más riguroso en tu proceso de decisión”.

Lo que no cambia

Lo que no cambia es el criterio. La capacidad de hacer las preguntas correctas. El juicio para saber cuándo una solución simple es mejor que una sofisticada. La habilidad para anticipar cómo va a evolucionar un sistema y diseñarlo para que esa evolución sea manejable.

He visto a equipos usar herramientas de IA para generar código más rápido y crear deuda técnica a una velocidad que antes era imposible. La velocidad sin criterio no es un beneficio, es un riesgo.

La IA amplifica lo que ya traes. Si tienes criterio, lo amplifca. Si no lo tienes, amplifica también eso.

Qué significa esto para los ingenieros

Significa que invertir en comprensión profunda importa más, no menos. Las herramientas de IA son mejores generando código que entendiendo problemas. La brecha entre “alguien que entiende el problema” y “la herramienta que genera la solución” es donde vive el valor.

Significa que las habilidades de comunicación y razonamiento estructurado importan más. Si vas a usar IA de manera efectiva, necesitas ser capaz de describir el problema con precisión suficiente como para que la herramienta entienda el contexto. Eso es difícil. Más difícil de lo que parece.

Y significa que la curiosidad técnica sigue siendo la diferencia. Los ingenieros que entienden cómo funcionan los sistemas, no solo cómo usarlos, van a ser más capaces de detectar cuándo la IA está generando algo plausible pero incorrecto. Y va a generarlo. Regularmente.

No tengo una predicción definitiva sobre cómo va a cambiar la industria en diez años. Nadie la tiene. Pero sí sé que la gente que está usando estas herramientas para entender mejor los problemas, no solo para escribir código más rápido, está teniendo conversaciones mucho más interesantes que el resto.

Y esas conversaciones, en última instancia, son las que producen software que vale la pena.