El codigo funciona. Nadie sabe por que.

El mundo está entrando en una fase para la que no está del todo preparado. Pero eso no es nuevo. La tecnología siempre ha funcionado así: llega antes de que sepamos exactamente qué hacer con ella, y los que se quedan parados esperando a entenderla del todo acaban llegando tarde. Lo importante no es tenerlo todo claro desde el principio. Lo importante es no quedarse atrás.

Así que como el buen eterno junior que soy, ese que se asoma a territorios desconocidos con más curiosidad que certezas, yo entré.

La ola de ChatGPT

Cuando ChatGPT irrumpió, lo primero que pensé fue: otro chatbot. Uno más sofisticado, con mejor marketing, pero en el fondo lo mismo de siempre.

Me equivoqué.

La calidad de las respuestas no era la que esperaba. No me refiero a que fueran perfectas, no lo eran, sino a que demostraban un nivel de comprensión del lenguaje y el contexto que no había visto antes en ninguna herramienta automatizada. En cuestión de semanas me quedó claro: Google estaba en peligro. Stack Overflow también.

Eso me generó vértigo. No el tipo que paraliza, sino el que te hace querer entender qué está pasando por dentro. Fue cuando escuché por primera vez conceptos como embeddings y bases de datos vectoriales. No entré en profundidad, tampoco era necesario entonces, pero sí lo suficiente para entender que había una maquinaria enorme y bien construida detrás de algo que parecía magia.

Lo que sí rechacé desde el principio fue la narrativa del “gran reemplazo”. El código que generaba la IA en aquellos primeros meses no era bueno. Funcionaba a veces, pero no con el tipo de rigor que necesita un sistema en producción. Quien lo proclamaba no estaba viendo el mismo código que yo.

El valor real, que no era el que anunciaban

Lo que sí encontré, y que nadie mencionaba porque no es tan espectacular, fue algo diferente: un interlocutor técnico inagotable.

Siempre me ha gustado debatir sobre buenas prácticas, estándares, convenciones de código, decisiones de arquitectura. El problema es que ese tipo de conversación tiene un límite natural en cualquier equipo: la gente se cansa, tiene otras cosas, no siempre comparte el mismo nivel de interés. La IA no tiene ese límite.

Podía cuestionarle una decisión de diseño a las once de la noche y recibir una respuesta razonada. Podía explorar tres alternativas para resolver un problema y que me ayudase a trazar los trade-offs de cada una. No siempre tenía razón, pero siempre tenía algo que decir. Y eso, para alguien que piensa mejor en conversación que en silencio, fue genuinamente útil.

Ese sigue siendo el uso que más valor me da, dos años después.

Cuando la IA llegó al IDE

El salto al editor de código fue otro nivel.

Pasar de un chatbot en una pestaña del navegador a tener un asistente directamente en el IDE cambió la naturaleza del trabajo. Ya no era solo “le pregunto y me responde”. Era algo más integrado, más fluido. El autocompletado evolucionó de sugerir cuatro líneas a escribir clases enteras. Y lo más sorprendente: empezó a entender problemas complejos con suficiente contexto.

El impacto en autonomía y productividad fue real. No el que prometen los demos de marketing, sino algo más sutil y más concreto. Menos tiempo en tareas mecánicas, más espacio mental para decisiones que importan.

Pero ahí fue también cuando empecé a ver el otro lado.

El código funciona. Nadie sabe por qué.

En los últimos meses he revisado varias pruebas técnicas de candidatos. No voy a nombrar a nadie, ni falta que hace: el patrón se repite con suficiente frecuencia como para que sea estructural, no anecdótico.

Lo más visible es lo más superficial: commits llenos de emojis y comentarios con ruido visual, el tipo de estilo que ningún equipo serio adoptaría en producción. Fácil de identificar, fácil de corregir.

Lo que preocupa más es lo que hay debajo.

Arquitecturas que dicen seguir DDD pero mezclan responsabilidades sin criterio: lógica de negocio en los controladores, acceso a datos en la capa de aplicación, infraestructura que se cuela donde no debe. Las capas están nombradas correctamente. Las responsabilidades, no. Alguien siguió la estructura sin entender qué protege esa estructura.

Y luego está lo que más me inquieta: los fallos de seguridad. Payloads con datos sensibles expuestos sin ningún tipo de sanitización. Endpoints que aceptan operaciones de administrador sin verificar si el usuario está siquiera autenticado. Cosas que no son errores de principiante. Son errores de quien no ha pensado en qué pasa cuando alguien malintencionado toca ese código.

La IA lo generó. Nadie lo revisó.

Sobre los tests, la paradoja es casi cruel: la IA hace que escribir tests unitarios sea más fácil que nunca, y aun así muchas de estas entregas no tienen ninguno. Como si el esfuerzo que ahorra la IA en otras partes no se reinvirtiera donde más se necesita.

El denominador común en todos estos casos es el mismo: código construido en modo MVP, sin un solo segundo de reflexión sobre lo que ocurre cuando llega a producción. Y esos segundos de reflexión son exactamente los que la IA no puede tener por ti.

El sobrecoste viene después. Siempre viene.

La pregunta que no me quita de la cabeza

Hay algo que me preocupa más que los fallos técnicos en sí. Por lo que veo en revisiones, en entrevistas técnicas, en conversaciones con otros leads: una proporción sorprendentemente baja de programadores revisa con criterio lo que genera la IA antes de incorporarlo al código base.

¿Qué clase de software estamos desplegando?

No es una pregunta retórica. Es la que me hago cada vez que reviso una prueba técnica y veo ese patrón: código que funciona, que pasa los casos básicos, pero que nadie ha entendido del todo. Y si nadie lo ha entendido, nadie puede mantenerlo, extenderlo ni arreglarlo cuando falle en producción.

Me preocupa especialmente lo que esto significa para los perfiles junior. La IA puede ahorrarte el camino, pero no puede darte el criterio que se construye recorriéndolo. Un junior que resuelve con IA sin entender qué está resolviendo no está aprendiendo: está posponiendo el aprendizaje al peor momento posible, que es cuando algo falla en un sistema real y hay que tomar decisiones rápidas.

La mente ingenieril, esa capacidad de entender un sistema, anticipar puntos de fallo, evaluar trade-offs sin que nadie te los dicte, se va a valorar cada vez más. Y va a ser cada vez más difícil de encontrar, precisamente porque las herramientas que facilitan el trabajo también facilitan evitar desarrollarla.

Cómo uso la IA hoy

Uso Codex CLI, GitHub Copilot y Claude Code de forma regular. Cada uno tiene su lugar en el flujo.

Lo que he cambiado no es qué herramientas uso, sino cómo me posiciono respecto a ellas. Ya no soy el programador que le pide a la IA que escriba código. Soy el analista funcional que define qué hay que construir, por qué y con qué restricciones. Creo historias de usuario, planteo la arquitectura, defino los límites y luego trabajo en modo planificación junto con la IA para revisar el enfoque antes de implementar. Después reviso lo que produce.

Eso último es lo que marca la diferencia. Revisar de verdad, con criterio. No para corregir erratas de sintaxis, sino para evaluar si la solución tiene sentido, si es segura, si va a aguantar el siguiente cambio de requisitos.

Lo que la IA no puede reemplazar, al menos por ahora, es la capacidad de entender qué necesita realmente el cliente más allá de lo que pide, de retener el contexto completo de un sistema durante semanas, de saber cuándo algo que funciona hoy va a ser un problema mañana. Eso requiere criterio, no solo instrucciones.

Una IA mal guiada es un pozo sin fondo de errores acumulados y código imposible de mantener. Las herramientas que incorporan planificación y contexto explícito ayudan a reducir ese riesgo (el modo agente, las skills, el plan antes de tocar nada). Pero el juicio sobre qué construir, cómo hacerlo y qué no hacer sigue siendo responsabilidad del ingeniero.

La IA es tan buena como quien la dirige. No lo digo como advertencia ni como crítica a la tecnología. Lo digo porque es lo que he visto con mis propios ojos, revisión tras revisión.

Así que seguiré haciendo lo que siempre he hecho: asomarme a lo nuevo con más curiosidad que certezas, y procurar entender lo que toco antes de darlo por bueno.