La IA no hizo fácil la ingeniería de software. Hizo más valioso el criterio.

La primera vez que vi a una IA escribir una función que realizaba operaciones a partir de una descripción de una sola línea, mi reacción no fue: “¡Esto me va a reemplazar!”. Fue algo más silencioso y, quizá, más interesante: “Entonces, teclear nunca fue lo difícil.”

Durante años hablamos del software como si producir código fuera el trabajo: lenguajes más rápidos, mejores editores, más líneas de código por día. Medíamos productividad en cantidad de código producido y buscábamos constantemente herramientas que nos permitieran escribir más, más rápido y con menos esfuerzo.

Después llegó una herramienta capaz de producir código con buena apariencia y prácticamente gratis. Y entonces quedó claro algo incómodo: hacer el código rara vez fue donde vivía la verdadera dificultad.

¿Qué es lo que realmente se abarata?

La IA lleva casi a cero el costo de generar código, boilerplate, adaptadores y soluciones repetitivas. La décima variación de un formulario, el script de migración que ya escribiste veinte veces, un CRUD, un mapper o una integración sencilla pueden generarse en cuestión de segundos.

Y sí, eso es genuinamente útil.

Pero hay una diferencia importante: la IA solo está llevando un costo a casi cero. Todo lo que rodea la generación de código sigue siendo igual de difícil.

Decidir qué construir y qué dejar fuera. Elegir los trade-offs que serán caros de revertir. Saber qué solución es realmente correcta. Entender el negocio detrás de lo que estás construyendo. Anticipar cómo se comportará un sistema bajo carga. Identificar dónde puede fallar. Entender qué consecuencias tendrá una decisión técnica seis meses después.

Nada de esto se volvió más barato.

Si acaso, se volvió más valioso, porque ahora representa el cuello de botella. Cuando generar código deja de ser la parte costosa del proceso, la habilidad escasa deja de ser escribirlo.

La habilidad escasa pasa a ser el criterio.

La parte incómoda

Esto es lo que hace que la IA sea complicada en lugar de simplemente mágica: es especialmente convincente justo donde puede ser más peligrosa.

Pídele una función utilitaria y probablemente acertará. Pídele que diseñe cómo tu sistema maneja dinero, concurrencia, fallas, resiliencia o escalabilidad, y responderá con la misma fluidez y seguridad. El problema es que puede estar equivocada, y no necesariamente de una manera evidente. Puede ser sutilmente incorrecta.

La IA puede producir una solución que parece perfectamente razonable, que compila, que pasa algunas pruebas y que incluso funciona en producción durante un tiempo. Pero eso no significa que sea la solución correcta.

La IA optimiza para algo que parece correcto. Y eso no es lo mismo que ser correcto.

La diferencia muchas veces no aparece al ejecutar el código por primera vez. Aparece bajo carga, en los casos extremos, cuando ocurre una falla que nadie había contemplado o seis meses después, cuando el sistema ya está en producción y alguien tiene que vivir con las decisiones que se tomaron.

El código generado que no entendiste no deja de ser deuda técnica. Solo es deuda técnica con mejor formato y generada automáticamente.

¿Dónde nos deja esto?

El cambio interesante no es simplemente que la IA escriba código o que pueda generar productos cada vez más rápido. Lo realmente interesante es que la IA separó, silenciosamente, dos cosas que durante mucho tiempo tratamos como si fueran una sola: producir software y entenderlo.

Producir software es cada vez más automatizable. Entenderlo sigue siendo difícil.

¿Qué construir? ¿Por qué construirlo? ¿Qué no deberíamos construir? ¿Cómo debería comportarse? ¿Cómo puede fallar? ¿Qué trade-offs estamos aceptando? ¿Y qué consecuencias tendrán esas decisiones?

Ahí sigue estando gran parte del trabajo.

La IA puede hacer que un buen ingeniero sea dramáticamente más rápido en la ejecución. Puede eliminar horas de trabajo repetitivo, convertir una idea en un prototipo en minutos y escribir una parte considerable de un sistema. Pero no elimina la necesidad de entender lo que estamos construyendo ni la responsabilidad sobre las decisiones que tomamos.

Por eso, la pregunta deja de ser: “¿La IA va a escribir el código?”

Claro que lo va a hacer.

La pregunta importante es otra:

“¿Quién sigue siendo responsable de que ese código sea correcto?”

La respuesta no ha cambiado.

El ingeniero.

Y no creo que vaya a cambiar.