Agente de IA que corrige bugs: crea uno que primero reproduzca el error

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.

Prueba Apidog hoy

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:

1. Recepción: recopilar el reporte, la solicitud que falla y la respuesta que obtuvo.
2. Reproducir: escribir una prueba que falle por la razón reportada. Sin prueba que falle, no hay corrección.
3. Corregir: aplicar el parche al código en una rama o worktree aislado.
4. Re-ejecutar: la nueva prueba debe pasar, y la suite existente también.
5. 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 [REDACTED PROMPT]
Here is a bug report for POST /orders in Apidog project .
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:

bash
apidog cli-schema get test-case-create
apidog test-case category --project
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project --file repro-orders.json

El archivo que escribe se ve así (los IDs vienen de tu proyecto):

json
{
"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:

bash
apidog run --test-case --project -e -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:

bash
apidog test-case run --project --endpoint -e -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](https://apidog.com/es/blog/apidog-cli-ci-cd-pipeline?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). Para más configuraciones, consulta el [flujo de trabajo de Apidog CLI con agentes](https://apidog.com/es/blog/apidog-cli-agent-workflow?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) y [Apidog CLI en Claude Code](https://apidog.com/es/blog/apidog-cli-in-claude-code?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). 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](https://apidog.com/es/blog/claude-code-github-actions?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation). Consulta [qué es DeepSeek Harness](https://apidog.com/es/blog/what-is-deepseek-harness?utm_source=dev.to&utm_medium=wanda&utm_content=n8n-post-automation) si quieres probarlo ahí.