Los titulares no dejan de decirnos que la IA hará que los desarrolladores de software queden obsoletos. No lo creo. El verdadero riesgo no es que las máquinas se apoderen de la ingeniería. El riesgo es que los ingenieros dejen de hacer el arduo trabajo de pensar.

El software nunca se trató de escribir sintaxis. Siempre se trató de mantener la complejidad en la cabeza, comprender los modos de fallo y realizar compensaciones cuando ninguna opción es perfecta. La IA ha cambiado la velocidad a la que producimos código, pero no ha cambiado el porqué necesitamos humanos en el proceso. En todo caso, ha hecho que el pensamiento claro sea más valioso y más escaso.

El primer borrador no es ingeniería

Veo a un número creciente de desarrolladores junior tratando a ChatGPT o Claude como al ingeniero senior sentado en la silla de al lado. Pegan la descripción de un ticket, copian la respuesta, ejecutan las pruebas y hacen el commit. Si compila, la tarea se cierra. El ciclo es rápido, sin fricciones y peligroso.

Usar la IA no es el problema. Yo la uso. La mayoría de los ingenieros productivos que conozco la usan. El problema comienza cuando la IA se convierte en el único ingeniero en la sala. Aceptar la primera solución porque funciona no es ingeniería. Es la externalización del juicio a un modelo que no entiende a tus usuarios, tus restricciones de negocio o la última vez que tu stack se cayó a las 2 de la mañana.

Los modelos de lenguaje de gran tamaño ofrecen respuestas con una confianza inquietante, incluso cuando están completamente equivocados. Un ingeniero le pidió a una IA que diseñara una arquitectura escalable. El modelo devolvió una propuesta detallada y autoritaria construida enteramente en torno a una funcionalidad que no existía en el producto real. Parecía correcta. Era internamente coherente. También era inútil. El peligro no es solo que la IA alucine. El peligro es que demasiada gente confíe ahora en esas alucinaciones porque ya no tienen el contexto para detectar la mentira.

Aprendes de la fricción

Cuando pienso en lo que me convirtió de un desarrollador junior en alguien capaz de hacerse cargo de un sistema, no recuerdo la sintaxis que memoricé. Recuerdo las caídas del servicio. Recuerdo las consultas lentas que tuve que rastrear a mano, las condiciones de carrera que solo aparecían bajo carga de producción y los despliegues que fallaban porque mi entorno local no se parecía en nada al mundo real.

La depuración es donde ocurre el aprendizaje. Cuando recorres el código manualmente, ves por qué los sistemas fallan realmente. Descubres dónde aparecen los cuellos de botella. Aprendes cómo se comporta una arquitectura cuando pasas de una demo con diez usuarios a un sistema de producción que maneja diez mil solicitudes concurrentes. Absorbes, en tus propios huesos, cómo la producción difiere de una demo bien guionizada.

Nada de ese conocimiento proviene de aceptar una respuesta generada. Proviene de luchar con el problema. Si la IA elimina cada dificultad, si escribe el código, corrige los errores y justifica los fallos, ¿cómo exactamente la próxima generación de desarrolladores ganará su seniority? La experiencia no es un certificado que descargas. Es el tejido cicatricial que construyes a partir de incidentes en producción y despliegues fallidos. Elimina la fricción y eliminarás el crecimiento.

El juicio vence a la generación

Durante un tiempo, la industria trató el prompt engineering como la nueva habilidad de moda para incluir en un currículum. Eso perdió el punto por completo. La habilidad más valiosa en un entorno saturado de IA no es generar opciones. Es saber qué sugerencias rechazar.

Los mejores ingenieros con los que trabajo no son los que escriben más prompts. Son los que hacen las preguntas más difíciles. Saben cuándo una refactorización introduce una dependencia oculta. Reconocen cuándo una prueba generada cubre el happy path pero ignora el edge case que corromperá los datos del cliente. Pueden mirar un código perfectamente válido y decir: "Este código es correcto, pero la arquitectura es errónea".

Esa última frase es la línea divisoria entre dos culturas muy diferentes. La ingeniería asistida por IA significa que usas la máquina para redactar el scaffolding, explorar patrones o automatizar el boilerplate, mientras tu cerebro se encarga de las decisiones. La ingeniería dependiente de la IA significa que confías en que la máquina conduzca. Muchas organizaciones se están desplazando silenciosamente hacia la dependencia porque parece más rápido a corto plazo. Rápido no es lo mismo que correcto.

El trabajo que aún pertenece a los humanos

La IA puede acelerar casi todas las etapas del ciclo de vida del desarrollo; sin embargo, existen prácticas fundamentales que deben permanecer firmemente en manos humanas. El diseño de sistemas requiere equilibrar restricciones contrapuestas: costo, latencia, confiabilidad y mantenibilidad futura. Las revisiones de arquitectura dependen de la memoria institucional y de la capacidad de proyectar efectos de segundo orden. La mentoría requiere de alguien que realmente haya sufrido los modos de falla sobre los que te está advirtiendo. El conocimiento profundo del producto proviene de hablar con los usuarios y observar su comportamiento en el mundo real, no de leer datos de entrenamiento.

El juicio de ingeniería es la suma de esas experiencias. Es esa voz silenciosa que te dice que una migración es demasiado arriesgada para lanzarla un viernes por la tarde, incluso si la revisión de código fue aprobada. Es la intuición de que una optimización de rendimiento ahora podría crear un agujero de seguridad más adelante. Un LLM no tiene intuición. Tiene patrones. Los patrones son útiles, pero no son juicio.

Las empresas que están contratando ahora mismo deben dejar de optimizar para personas que simplemente son buenas usando herramientas de IA. Contraten a personas que puedan desafiar a la IA. Busquen candidatos que se detengan, lean cuidadosamente el resultado generado y expliquen por qué no están de acuerdo con él. Esos son los ingenieros que mantendrán la salud de sus sistemas cuando el código generado se enfrente a la desordenada realidad de producción.

Aceleración sin brújula

Piense en la IA como un pedal del acelerador. En un automóvil con un