Un agente de IA que corrige errores por sí solo funciona cuando sigue una sola regla: sin reproducción, no hay corrección. El agente convierte el reporte del bug en una prueba que falla hoy, aplica un parche al código en una rama aislada, vuelve a ejecutar esa prueba más la suite completa, y solo informa cuando todo está en verde. Un humano sigue haciendo el merge. Si no puede reproducir el bug, permanece en silencio.
El equipo de DeepSeek Harness presentó esta idea ante una gran audiencia el 1 de noviembre de 2026, en un ensayo sobre el diseño de super-agentes. Esta guía lo convierte en un pipeline que puedes construir esta semana, con la reproducción escrita como una prueba de API que tu agente crea y ejecuta desde la terminal.
Por qué «agente, arregla esto» falla sin una reproducción
Pídele a un agente de programación que corrija un reporte de bug y lo más probable es que obtengas un diff con apariencia confiada. No puedes saber si corrige tu bug, un bug que imaginó, o nada.
Sin un paso de reproducción, tres cosas salen mal:
- El agente adivina la causa. Elige la línea más probable según el mensaje de error y la edita.
- «Corregido» no tiene definición. La única prueba es el resumen del propio agente.
- Se cuelan regresiones. Un parche en un validador compartido puede arreglar un endpoint y romper cuatro más.
Una prueba que falla resuelve los tres problemas: fija el bug, define qué significa «terminado» y permanece en tu suite como verificación de regresiones.
De dónde viene «reproducir y corregir en silencio»
En «Exploring Super-agent Design», el equipo de DeepSeek Harness describe una política de su propio grupo de usuarios: cuando alguien reporta un bug, un agente intenta reproducirlo en segundo plano. Solo habla cuando tiene una corrección confirmada y simple. De lo contrario, no dice nada.
El ensayo llama a esto ejecución especulativa y lo combina con dos piezas que reutilizarás aquí. Los workers obtienen una sesión aislada por tarea, con acceso completo a las herramientas y el modelo más potente, y reportan a un router en lugar de hablar con humanos. Un watchdog es una sesión independiente que verifica si cada worker está avanzando o si se está desviando.
Una advertencia: el ensayo describe una arquitectura, no funcionalidades publicadas de DeepSeek Harness. Parte de ella vive en un plugin prototipo, dsh-superagent-prototype, que según los autores no es un producto oficial de DeepSeek. Para la visión del router y los workers, consulta cómo construir un super-agente.
El pipeline de cinco pasos para un agente que corrige bugs
Un agente que se autocorrige ejecuta el mismo bucle cada vez, con dos compuertas:
- Recepción: recopilar el reporte, la solicitud que falla y la respuesta que obtuvo.
- Reproducir: escribir una prueba que falle por la razón reportada. Sin prueba que falle, no hay corrección.
- Corregir: aplicar el parche al código en una rama o worktree aislado.
- Re-ejecutar: la nueva prueba debe pasar, y la suite existente también.
- Entregar: abrir un pull request con la evidencia, o permanecer en silencio.
Paso 1: Recepción del reporte de bug
Tu agente no puede reproducir «el checkout vuelve a fallar». Dale a la recepción una estructura fija:
| Campo | Ejemplo | Por qué importa |
|---|---|---|
| Endpoint | POST /orders |
Qué handler hay que leer |
| Solicitud | Cuerpo con "coupon": null |
La entrada exacta que lo rompió |
| Respuesta real | 500, {"error":"internal"} |
Lo que la prueba debe ver fallar |
| Respuesta esperada | 201 con el id de una orden |
Lo que la prueba verifica |
| Entorno | staging | Dónde se ejecuta la reproducción |
Si faltan campos, el agente pregunta una vez o extrae la solicitud de los logs. Los cuerpos de error que siguen los problem details de RFC 9457 ayudan, porque el tipo de error llega en un formato predecible.
Paso 2: Reproducir el bug como una prueba de API que falla
Esta es la compuerta. El agente convierte el registro de la recepción en un caso de prueba con dos aserciones —el código de estado esperado y un campo que la respuesta debería contener— y lo ejecuta contra el entorno real. Hay tres resultados posibles:
- Falla por la razón reportada. Tienes una reproducción. Continúa.
- Pasa. El bug no es reproducible tal como se describió. Regístralo y detente.
- Falla por otra razón (error de autenticación, datos faltantes, timeout). Es una reproducción rota, no un bug confirmado. Detente.
Solo el primero desbloquea una corrección. Eso es lo que significa «en silencio» en la práctica: los otros dos generan una entrada de registro para quien revise la cola, no un mensaje en el chat del usuario.
Escribe la reproducción como una prueba de API, no como una prueba unitaria: el agente ataca la misma interfaz que usó el usuario, así que no puede reproducir por accidente un bug diferente.
Paso 3: Corregir el código en una rama aislada
Una vez que la reproducción está en rojo, el worker obtiene su propia copia del código. Un git worktree es la opción más ligera: un segundo directorio de trabajo en una rama nueva, de modo que las ediciones del agente nunca toquen tu checkout. Ejecuta el servicio desde ahí y apunta el entorno de pruebas hacia él.
Mantén dos restricciones estrictas. La corrección debe ser pequeña: fija un límite como 3 archivos o 50 líneas modificadas, y trata cualquier cosa más grande como un reporte para un humano. Y debe apuntar a la reproducción: sin refactors, renombrados ni ordenamientos, porque cada cambio extra es algo que tu revisor tendrá que verificar.
Paso 4: Volver a ejecutar la reproducción y la suite completa
La segunda compuerta tiene dos partes. Primero, el agente vuelve a ejecutar el mismo caso de prueba del paso 2, sin cambios, y debe pasar. Si el agente editó las aserciones para lograrlo, la corrección falla; tu pipeline lo detecta comparando el archivo de prueba antes y después.
Segundo, la suite existente debe seguir en verde. Una corrección que vuelve verde una prueba y pone tres en rojo regresa al paso 3. Limita el bucle en el tiempo, por ejemplo 3 intentos o 20 minutos, y luego detente y registra lo que se probó. Aquí es donde el watchdog gana su lugar: puede eliminar un worker que sigue editando la misma línea o que se desvía hacia archivos que la reproducción nunca tocó.
Paso 5: Entregar solo una corrección confirmada y simple
Cuando ambas compuertas están en verde, el agente abre un pull request con evidencia, no con un relato: el reporte, la ejecución fallida, el diff y la ejecución exitosa con los resultados de la suite. Un humano revisa y hace el merge. Las ramas protegidas garantizan que el token del agente pueda empujar una rama pero nunca hacer merge en main. Si alguna compuerta falla, quien reportó no se entera; el agente escribe una línea de registro y continúa.
Barandillas para un agente de IA que se autocorrige
Configura estas barreras antes de la primera ejecución sin supervisión:
| Barandilla | Configuración | Qué previene |
|---|---|---|
| Alcance | Máximo de archivos y líneas por corrección | Reescrituras presentadas como correcciones |
| Límite de tiempo | Máximo de intentos y minutos por bug | Bucles descontrolados quemando tokens |
| Credenciales | Solo staging, sin claves de producción | Una reproducción que escriba órdenes reales |
| Derechos de merge | Empujar ramas, nunca hacer merge | Código sin revisar llegando a main |
| Integridad de las pruebas | Comparar el archivo de prueba antes y después | Aserciones editadas para que pasen |
| Silencio | Sin mensajes al usuario en caso de fallo | Ruido y afirmaciones a medio confirmar |
Las credenciales son lo más importante: una reproducción ataca la API de verdad, así que usa staging o datos locales sembrados.
Deja que tu agente de programación construya la reproducción con Apidog CLI
El paso 2 es el corazón del pipeline, y es precisamente para lo que está hecho Apidog CLI. Tu agente de programación (Claude Code, Codex, Cursor u OpenCode) escribe el caso de prueba como JSON, lo crea en tu proyecto de Apidog y lo ejecuta desde la terminal. Tú escribes un solo prompt.
Configúralo una vez:
npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com # pick your agent when prompted
Luego dale a tu agente el reporte del bug y este prompt:
Here is a bug report for POST /orders in Apidog project <projectId>.
Turn it into an Apidog test case that fails today: assert status 201
and that $.id exists. Run it against staging and confirm it fails for
the reported reason. If it does, fix the handler on a new worktree
branch until the same test passes, run the endpoint's other cases, and
open a PR with both JSON reports. If it doesn't reproduce, stop and log why.
El agente no construye el payload de memoria. Lee el schema, encuentra una categoría, valida su archivo y solo entonces crea el caso:
apidog cli-schema get test-case-create
apidog test-case category --project <projectId>
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project <projectId> --file repro-orders.json
El archivo que escribe se ve así (los IDs vienen de tu proyecto):
{
"name": "Repro: POST /orders with null coupon returns 500",
"apiDetailId": 123456,
"categoryId": 1,
"method": "post",
"path": "/orders",
"parameters": {},
"commonParameters": {},
"requestBody": {
"type": "application/json",
"data": "{\"items\":[{\"sku\":\"A-100\",\"qty\":1}],\"coupon\":null}"
},
"postProcessors": [
{ "type": "assertion", "defaultEnable": true, "enable": true,
"data": { "name": "status is 201", "subject": "httpCode", "comparison": "equal", "path": "", "value": "201" } },
{ "type": "assertion", "defaultEnable": true, "enable": true,
"data": { "name": "order id exists", "subject": "responseJson", "comparison": "exists", "path": "$.id" } }
]
}
Ahora la ejecución en rojo que demuestra el bug:
apidog run --test-case <caseId> --project <projectId> -e <stagingEnvId> -r cli,json --out-file repro-before
El reporter de la CLI muestra la aserción de estado fallando con un 500, y repro-before.json queda en apidog-reports/. Después de la corrección, el agente ejecuta el comando idéntico con --out-file repro-after y ambas aserciones pasan. Esos dos archivos son la evidencia en el pull request. Para el paso 4, ejecuta todos los casos del endpoint para que la corrección no rompa silenciosamente a un vecino:
apidog test-case run --project <projectId> --endpoint <endpointId> -e <stagingEnvId> -r cli,json
Agrega --upload-report para ver la ejecución en la aplicación de Apidog. Después del merge, el caso de reproducción permanece en tu proyecto como prueba de regresión, y el mismo apidog run con -r junit se integra en CI, como se muestra en ejecutar Apidog CLI en un pipeline de CI/CD. Para más configuraciones, consulta el flujo de trabajo de Apidog CLI con agentes y Apidog CLI en Claude Code. Apidog Free cubre hasta 4 usuarios, así que puedes probar el bucle completo sin un plan de pago.
FAQ
¿Puede realmente un agente de IA corregir bugs sin un humano?
Puede reproducir, aplicar parches y demostrar muchos bugs simples por su cuenta, pero no debería hacer los merges. Mantén a un humano en el merge, y deja que la protección de ramas lo imponga.
¿Qué pasa si el agente no puede reproducir el bug?
Se detiene y registra lo que intentó. Un bug que no puede reproducir es una corrección que no puede confirmar, así que cualquier parche sería una adivinanza. Un humano luego añade detalles al reporte o lo cierra.
¿Cómo evito que el agente edite la prueba para que pase?
Guarda una copia o un hash del caso de prueba cuando falle por primera vez y compáralo antes de aceptar la corrección. Mantén el archivo de prueba fuera de las rutas que el worker puede editar.
¿Necesito DeepSeek Harness para construir esto?
No. El ensayo describe un diseño, y su plugin prototipo no es un producto oficial de DeepSeek. Cualquier agente de programación que ejecute comandos de shell sirve, incluido Claude Code en GitHub Actions. Consulta qué es DeepSeek Harness si quieres probarlo ahí.