Los agentes de IA para programar no son asistentes. Esto es lo que cambia de verdad cuando das el salto

Le pediste a tu agente de IA algo pequeño: “Agrega soft delete a las facturas”. Diez minutos después tienes un pull request. Catorce archivos modificados, una migración, queries actualizadas, tests nuevos, todo en verde.

Lees el diff como llevas dos años leyendo código generado por IA: línea por línea, buscando algo raro. No hay nada raro. Lo apruebas.

Dos semanas después, el equipo de finanzas pregunta por qué faltan facturas en el reporte de conciliación del mes pasado. Ninguna línea de ese pull request estaba mal. El problema estaba en una decisión que el agente tomó por su cuenta, y nada en tu revisión estaba pensado para detectar decisiones.

Qué hace distinto un agente de IA para programar

Durante mucho tiempo, la conversación sobre las herramientas de IA para programar giró en torno a la calidad de las sugerencias. ¿Qué tan seguido acierta el autocompletado? ¿Entiende la función que lo rodea? ¿Conviene aceptar y corregir, o escribirlo tú?

Esa conversación tenía sentido cuando la herramienta proponía unas pocas líneas a la vez. Tú seguías siendo el autor. La intención vivía en tu cabeza, veías cada sugerencia en contexto y la aceptabas o la descartabas en un segundo.

Un agente de IA para programar trabaja en otro nivel. Le das un objetivo. Lee el codebase, elige qué archivos tocar, decide cómo implementar el cambio, escribe los tests y te entrega un resultado terminado. En el camino toma decenas de pequeñas decisiones de diseño, y no viste ninguna.

Ese es el verdadero cambio. La pregunta deja de ser “¿esta sugerencia es buena?” y pasa a ser “¿qué decidió mientras yo no miraba?”.

Por qué los reflejos del autocompletado se quedan cortos

Revisar autocompletado te entrenó un conjunto concreto de reflejos. ¿Compila? ¿El nombre es claro? ¿Hay un off-by-one? ¿Maneja el null? Esos chequeos funcionan a nivel de línea o de función, porque ahí era donde el autocompletado se equivocaba.

Rara vez es ahí donde el trabajo de un agente se ve mal. El código suele leerse limpio, sigue el estilo de los archivos que lo rodean y viene con tests que pasan. Si lo revisas con reflejos de línea, pasa, porque ese es el nivel donde se ve más sólido.

Los agentes se equivocan un nivel más arriba: en cómo interpretaron el pedido. Qué cuenta como “terminado”. Qué llamadas existentes deberían ver el nuevo comportamiento. Qué patrón existente copiar.

Tu pedido no respondía nada de eso, así que el agente llenó los huecos por su cuenta. Se apoyó en su entrenamiento, como un desarrollador se apoya en su experiencia, o en lo que surgió en tus conversaciones anteriores con él. Esas decisiones no parecen errores en un diff. Parecen código perfectamente razonable.

No te pasa solo a ti. Un estudio de 2026 sobre pull requests generados por IA (More Code, Less Reuse, MSR 2026) encontró que los revisores reaccionaban ante ellos de forma más neutral o positiva que ante los de personas, aunque ese código tenía más redundancia. El código que se ve limpio genera mucha confianza.

También hay un problema de volumen. Leer línea por línea un cambio de catorce archivos exige mucha concentración, y para el archivo nueve la mayoría ya está leyendo en diagonal. Un reflejo pensado para tres líneas sugeridas no escala a un cambio que no escribiste y que no viste escribir.

Qué asumió el agente en el ejemplo de las facturas

Volvamos al soft delete. Para construirlo, el agente tuvo que responder preguntas que nunca hiciste en voz alta:

• ¿Las facturas eliminadas deben desaparecer en todas partes? Decidió que sí, y agregó un filtro deleted_at IS NULL al query scope compartido. El job nocturno de conciliación usa ese mismo scope.
• ¿Qué pasa con la unicidad del número de factura? Cambió el índice único para que ignore las filas eliminadas, así que otra factura puede volver a usar un número eliminado. Tu contador probablemente tenga opiniones sobre eso.
• ¿Las facturas eliminadas pueden volver? Agregó un endpoint de restauración, porque el ejemplo más cercano en el codebase, una tabla customers con soft delete, tenía uno.
• ¿Qué prueban los tests? Prueban que la interpretación del agente funciona. No verifican la tuya, porque el agente los escribió a partir de su propia lectura de la tarea.

Cada una de esas decisiones es defendible, y algunas probablemente son correctas. Igual son decisiones de diseño, y en este pull request nadie las tomó a propósito. Un diff te muestra qué cambió. No te puede decir cuáles de esos cambios fueron decisiones.

Quienes revisan código de agentes describen lo mismo. En un estudio de julio de 2026 basado en hilos de Reddit y blogs de ingeniería sobre code review, uno de ellos explica que el código generado por IA cuesta más de revisar porque “estás reconstruyendo la intención”.

Revisa primero los supuestos, después las líneas

Igual lees el diff. Solo dejas de empezar por ahí. Estos hábitos llevan la revisión al nivel donde los agentes se equivocan:

1. Pide los supuestos antes que el código. Haz que el agente escriba primero un plan corto: qué va a cambiar, qué está asumiendo y qué deja afuera. Revisar cinco oraciones de intención es más rápido que revisar catorce archivos, y es el momento más barato para corregir el rumbo.
2. Vuelve a preguntar después del código. Cuando el cambio esté listo, pídele al agente que liste cada decisión que tomó y que tu pedido no especificaba. No va a detectar todas. Va a mostrarte las que tiene presentes, y eso te da una lista para revisar en lugar de un diff para recorrer.
3. Empieza por los archivos que no esperabas. Antes de leer línea por línea, mira qué archivos cambiaron. Un query scope compartido, una clase base, un archivo de configuración, una migración sobre una tabla que nunca mencionaste: ahí viven las decisiones de mayor alcance. Los helpers nuevos también cuentan. Los agentes suelen escribir una utilidad nueva en lugar de reutilizar la que ya tienes, lo que significa que asumieron que no existía nada que sirviera.
4. Lee los tests como una spec. Pregúntate “¿estos son los comportamientos que quería?” antes de preguntarte “¿pasan?”. Una suite de tests que escribió el agente describe lo que el agente creyó que era la tarea. Revisa también que el agente no haya borrado, omitido ni aflojado ningún test existente para llegar al verde. METR documentó casos de modelos de frontera que modificaban tests para sacar mejores puntajes en tareas de programación.
5. Anota las restricciones que sigue pasando por alto. La mayoría de los agentes lee un archivo de reglas del proyecto (CLAUDE.md, AGENTS.md o una carpeta de reglas, según la herramienta). Cuando una revisión saca a la luz un supuesto que va a volver a aparecer, como “los reportes siempre incluyen las facturas eliminadas”, anótalo ahí para que el próximo cambio ya arranque con él.

Dónde se nota la seniority al revisar a un agente

Nada de esto es una habilidad nueva. Es lo que ya hace un buen revisor con el pull request de un ingeniero rápido y seguro de sí mismo que entró el mes pasado: primero revisa qué entendió que era la tarea, después revisa el código. La diferencia es que ahora lo haces varias veces por día.

Eso también explica por qué los agentes hacen que revisar sea más exigente. El agente escribe el código. El contexto que le falta (por qué la conciliación depende de ese scope, por qué los números de factura nunca pueden repetirse) es justo lo que un ingeniero senior lleva en la cabeza. Ya escribimos sobre por qué el pull request es donde se nota la seniority. Es el mismo criterio que analizamos en qué mide realmente a un ingeniero senior cuando todos usan agentes de IA, aplicado a un nuevo tipo de autor.

Así que la próxima vez que un agente te entregue un pull request limpio y en verde, hazte una pregunta antes de abrir el diff: ¿qué tuvo que asumir para construir esto? Si no sabes responder, ahí empieza tu revisión.