Dice que lo arregló. No lo arregló.
¿Quieres hablar de este ensayo? Escríbeme: amitkvint@gmail.comcopiado· o escríbeme por LinkedIn
El agente dice que encontró el problema.
Te cuenta qué falló, suena razonable, y reescribe la función. Lo ejecutas otra vez.
El error sigue ahí.
Así que le pegas el error de vuelta. Pide disculpas, dice que ahora sí ve el problema real, y cambia otra cosa. Sigue ahí. En la tercera ronda envuelve el síntoma en un try/except, para que al menos desaparezca el stack trace. En la cuarta ya ha reescrito tres archivos que nunca le pediste tocar, y ya no sabrías explicar qué hacía el código cuando funcionaba.
He perdido tardes enteras en ese bucle. Casi todos los que conozco que construyen con estas herramientas también.
El diagnóstico habitual es que hiciste mal el prompt.
No creo que sea eso.
Está adivinando, y no puedes notarlo
El agente tiene tu mensaje de error, el contexto que haya conseguido leer, y muy buen olfato para cómo suele ser un arreglo de este tipo de error. Con eso produce algo plausible.
Plausible no es lo mismo que correcto, y aquí viene la parte incómoda: cuando acierta, se ve exactamente igual que cuando se equivoca. El mismo tono seguro, la misma explicación ordenada de la causa raíz, el mismo diff limpio.
No hay señal que lo delate.
(Escribí la semana pasada sobre esta misma forma del problema en soporte, cuando un agente se encuentra con un bug que todavía nadie ha reportado y responde con esa misma voz tranquila. Otro terreno, el mismo fallo.)
Así que la pregunta nunca fue si el agente suena seguro. Siempre suena seguro.
La pregunta es si tú puedes comprobarlo.
Normalmente no puedes, porque no conoces el sistema lo bastante bien, que suele ser justo la razón por la que le pasaste el bug.
Eso no es un problema de prompting. Es un problema de depuración, y lo ha sido desde el principio.
Arreglarlo nunca fue lo difícil
Yo vengo de programar. Doce años con una pequeña agencia web de código abierto: PHP, MySQL, Python, servidores ajenos. Ya no escribo código en producción y no voy a fingir lo contrario. Lo que sí sigo haciendo es leer el código, leer los logs y reproducir el bug.
Eso último es el trabajo, y es la parte que el agente no puede hacer por ti.
Escribir el arreglo nunca fue donde se iba el tiempo. Cuando ya sabes que un valor llega vacío a la tercera función, y sabes por qué, el arreglo suele ser pequeño y bastante aburrido. Diez minutos. A veces una línea.
Llegar a esa frase es el trabajo.
La costumbre la aprendí antes de todo eso, de adolescente, montando PCs para mí y con amigos. Un ordenador que no arranca no te puede decir qué estaba pensando. Lo averiguas acotando.
La salida no es un prompt mejor ni un modelo más listo. Es la habilidad de ingeniería más vieja que hay: encontrar dónde deja de funcionar un proceso, antes de tocar nada.
Primero acotar, luego dejar que escriba
Cómo se ve eso en la práctica, en mis propios proyectos hechos con IA igual que en cualquier otro:
Reprodúcelo cuando quieras. Si no consigues que el bug ocurra a voluntad, todavía no estás depurando: estás reaccionando a reportes.
Busca el último punto donde el estado sigue siendo el que esperas, y el primero donde ya no lo es. El bug vive entre esos dos, y en ningún otro sitio.
Cambia una sola cosa. Y mira.
Si un cambio hace desaparecer el error y no sabes explicar por qué, no tienes un arreglo. Tienes una casualidad, y volverá dentro de un mes, normalmente en la máquina de otra persona.
Nada de esto va contra la IA. El agente es realmente bueno acotando cuando le señalas algo concreto: añade este log, escribe el test que falla, recorre esta función y dime qué valor hay en la línea 40. Es bueno escribiendo el arreglo una vez que el fallo está localizado. Lo que no sabe hacer es decidir que todavía no lo sabe.
La diferencia está en si le entregas un síntoma o una ubicación.
La parte que me sigue rondando
Hay una versión de esta preocupación que dice que estas herramientas empeoran a los programadores. No me lo acabo de creer, o al menos no así.
Lo que creo que hacen es mover la habilidad. Se quedan con la parte que siempre se pudo enseñar, la sintaxis, el boilerplate, el arreglo que podrías haber buscado, y te dejan con la parte que nunca se enseñó: saber qué se supone que tiene que hacer el sistema, y ver el punto exacto donde deja de hacerlo.
Esa parte no se vuelve más fácil según mejoran los modelos. Si acaso pesa más, porque las respuestas equivocadas llegan más rápido y mejor vestidas.
Una IA puede escribir el arreglo. No puede decirte dónde se rompió, y no te va a avisar cuando no lo sepa.
Planifica pensando en lo segundo.