Cuando los AI coding agents se vuelven más capaces, lo que más entusiasma a los equipos es que ya no se limitan a completar unas líneas de código. Pueden leer una tarea, modificar archivos, ejecutar tests e incluso enviar un pull request por su cuenta.

Pero si eres quien va a incorporarlos a un flujo real de desarrollo, la primera pregunta no debería ser “¿van a reemplazar a los ingenieros?”. La pregunta importante es: “¿en qué puntos vamos a detenernos para revisar?”.

Puedes delegar trabajo en un agent, pero no puedes delegar la responsabilidad junto con él. Al final, quien publica, mantiene, revierte y explica el cambio a los usuarios sigue siendo tu equipo.

Divide el trabajo en un proceso que se pueda revisar

Esto no es una lista de advertencias sueltas. Es la secuencia de checks que conviene definir antes de introducir un coding agent en el flujo del equipo. Primero reduce el alcance de la tarea y luego coloca checkpoints, para no descubrir que la dirección era incorrecta cuando el PR ya se volvió enorme.

Antes de empezar: no le entregues todo el requerimiento de una vez

Muchos problemas con coding agents no ocurren porque el agent no sepa escribir código en absoluto. Ocurren porque la tarea es demasiado grande desde el inicio.

Si solo escribes “refactoriza el flujo de login”, “mejora el manejo de errores de pago” o “termina esta funcionalidad”, es posible que el agent se ponga a trabajar. El problema es que completará supuestos por su cuenta: qué archivos debe tocar, qué tests son suficientes y qué casos límite puede dejar para después.

Lo que recibas puede parecer un diff completo, pero dentro puede haber supuestos de producto, APIs obsoletas, formatos de datos incorrectos o un montón de archivos que no deberían haberse modificado.

Checkpoint 1: revisa primero el plan

Antes de escribir código, pídele al agent que exponga su plan.

Debes mirar esto: ¿qué archivos piensa cambiar? ¿Por qué esos archivos? ¿Qué partes no están claras? ¿Qué tests hay que añadir? ¿Podría afectar comportamiento existente?

Si el plan ya es demasiado vago, no lo dejes pasar a implementación. Este paso ahorra mucho dolor cuando llegue el momento de revisar el diff.

Checkpoint 2: trabaja en alcances pequeños

Dividir la tarea es más útil que escribir un prompt más largo.

Por ejemplo, primero pide al agent que agregue un test que falle, luego que cambie una función y después que actualice la documentación relacionada. Cada paso se puede aceptar, verificar y revertir. No permitas que cambie “tests, lógica, UI, documentación y configuración” de una sola vez, a menos que estés preparado para revisar durante bastante más tiempo.

Los lotes pequeños no son lentos. Los lotes pequeños evitan que los errores se propaguen.

Checkpoint 3: valida los supuestos, no solo el resultado

Que los tests pasen no significa que la tarea esté bien hecha.

Al revisar el PR de un agent, no mires solo si el CI está en verde. Revisa también los supuestos que usó: ¿los datos siempre existen? ¿el permiso siempre está presente? ¿el formato de respuesta de la API de terceros es realmente estable? ¿los usuarios seguirán de verdad el camino que el agent espera?

Estos no suelen ser los juicios más fuertes de un agent. Justamente ahí es donde debe permanecer el reviewer humano.

Recordatorio para equipos de ingeniería

Los coding agents funcionan mejor con tareas claras, comprobables y bien delimitadas. No son una buena opción para rellenar directamente requerimientos ambiguos, flujos centrales sin tests o reglas de negocio que nadie puede explicar con claridad.

Si tu equipo todavía no tiene buenos templates de issues, una estrategia de testing y hábitos de rollback, el agent amplificará esas brechas. Define checkpoints primero y luego introduce la herramienta. Suele ser más seguro que comprar la herramienta primero.

Referencias