Hace unos días gasté cerca de 2.500 AI Credits intentando resolver un bug.
El problema era aparentemente sencillo. Durante un flujo de navegación dejaba de mostrarse un componente personalizado y decidí pedirle a un agente que investigara la causa y propusiera una solución.
Treinta minutos después tenía una respuesta extensa.
Había recorrido buena parte del proyecto, identificado posibles causas y propuesto un cambio de unas veinticinco líneas que, además de mejorar ligeramente la comprensión del código, no solucionaba el problema.
El bug seguía exactamente donde estaba.
Cerré el agente.
Abrí el debugger.
Puse un par de puntos de ruptura.
Seguí la navegación paso a paso.
Y en pocos minutos encontré el origen del problema: un conflicto entre dos animaciones.
No salí de aquella experiencia pensando que la IA fuera mala.
Salí pensando que quizá la estaba utilizando mal.
Delegué la tarea equivocada
Durante un rato estuve convencido de que el agente había fallado.
Después entendí que quien se había equivocado era yo.
Yo no necesitaba que alguien resolviera el bug.
Necesitaba ayuda para entenderlo.
Son dos cosas completamente distintas.
En lugar de pedir:
"Investiga el problema y arréglalo."
Probablemente debería haber pedido algo como:
"Este es el síntoma. Estas son las condiciones. ¿Cuáles serían tus primeras hipótesis? ¿Qué comprobarías antes de tocar una sola línea de código?"
La diferencia parece pequeña.
No lo es.
En el primer caso estaba delegando el razonamiento.
En el segundo simplemente estaba utilizando la IA para reducir el espacio de búsqueda.
Y creo que esa diferencia cambia por completo la relación que establecemos con estas herramientas.
El debugger veía algo que el agente no
No encontré antes la solución porque fuera más inteligente.
La encontré porque tenía acceso a información que el agente no podía observar.
El comportamiento real de la aplicación.
El agente podía leer el código.
Podía formular hipótesis.
Yo podía ejecutarlas y comprobar si sobrevivían al contacto con la realidad.
El código le permitía imaginar qué estaba ocurriendo.
El debugger me permitía saberlo.
Y esa diferencia sigue siendo enorme.
Porque la ingeniería no consiste únicamente en leer código.
Consiste en observar sistemas reales, formular hipótesis y validarlas continuamente.
Lo que realmente me hizo reflexionar
Lo curioso es que el problema no fue que el agente se equivocara.
Todos nos equivocamos.
Lo que realmente me hizo pensar fue otra cosa.
Si hubiese aceptado aquella solución sin comprobarla, el bug seguiría existiendo.
Y probablemente habría dado por buena una explicación incorrecta.
El agente no habría aprendido nada de su error.
Y yo tampoco.
Porque nadie había contrastado aquella respuesta con la realidad.
Fue ahí cuando entendí que el verdadero riesgo no era una respuesta equivocada.
Era dejar de cuestionarla.
Una analogía inesperada
Mientras preparaba esta reflexión me encontré con un concepto del que no había oído hablar hasta ahora: el Model Autophagy Disorder (MAD).
Describe un fenómeno que preocupa a quienes investigan modelos generativos.
Cuando un modelo aprende progresivamente de contenido generado por otros modelos en lugar de datos reales, puede empezar a perder diversidad, matices y capacidad para representar correctamente los casos menos frecuentes.
No quiero establecer una equivalencia entre ese fenómeno y cómo aprendemos las personas.
Pero la analogía me resultó difícil de ignorar.
Porque quizá el problema no sea únicamente que los modelos dejen de contrastar sus respuestas con la realidad.
Quizá también deberíamos preguntarnos qué ocurre cuando nosotros dejamos de hacerlo.
No quiero dejar de pensar
Aquella experiencia no hizo que dejara de utilizar agentes.
Todo lo contrario.
Sigo utilizándolos para tareas repetitivas.
Para migraciones masivas.
Para generar tests.
Para buscar documentación.
Para hacer refactors mecánicos.
Todo aquello donde el coste de equivocarse es bajo o donde el resultado puede verificarse fácilmente.
Lo que sí cambió fue el tipo de preguntas que intento hacerles.
Cada vez me interesa menos pedirles que resuelvan un problema completo.
Y cada vez me interesa más que me ayuden a entenderlo.
Que cuestionen mis hipótesis.
Que me propongan caminos alternativos.
Que reduzcan el tiempo dedicado a explorar.
Pero procuro que la decisión siga siendo mía.
Porque empiezo a pensar que el verdadero valor de estas herramientas no está en sustituir nuestro razonamiento.
Está en ampliar nuestra capacidad para ejercerlo.
La IA debería reducir el coste de pensar.
No eliminar la necesidad de hacerlo.
El verdadero riesgo
Estoy convencido de que los modelos seguirán mejorando.
Tendrán acceso a más contexto.
Podrán ejecutar código.
Inspeccionar aplicaciones.
Utilizar herramientas de depuración.
Resolver problemas que hoy todavía requieren intervención humana.
Ese no me parece el verdadero debate.
El verdadero debate somos nosotros.
Porque el mayor riesgo de la IA no es que piense por nosotros.
Es que llegue un momento en el que dejemos de comprobar cuándo se equivoca.
Y ese día el problema ya no será la calidad de sus respuestas.
Será la pérdida de nuestro criterio.
Una pregunta para el futuro
El Model Autophagy Disorder intenta explicar qué ocurre cuando una inteligencia artificial aprende cada vez más de sí misma y cada vez menos de la realidad.
La pregunta que todavía no sabemos responder es otra.
¿Qué ocurrirá cuando los ingenieros empecemos a aprender cada vez menos de nuestra propia experiencia y cada vez más de la experiencia sintetizada por una IA?