Cómo verificar el manejo de errores que escribió tu agente de programación

El agente de codificación dice que ha agregado reintentos y control de límites de velocidad, y sus pruebas pasan. Antes de confiar en eso, compruebe contra qué sistema se ejecutaron las pruebas.

En una prueba que se ejecutó con 3 agentes de codificación (210 ejecuciones), se les pidió que hicieran que las aplicaciones controlen los errores de API y mostraran que funciona. En 76% de las 140 ejecuciones que solicitaron código de trabajo, el agente reprodujo manualmente el fallo con stubs de fetch, httpx.MockTransport, o un servidor HTTP provisional. En las 75 ejecuciones en las que la API real estaba disponible y la instrucción no lo descartaba, 0 probó la aplicación en su dirección URL de API real. Pasar pruebas como estas demuestran que el código del agente controla el error que imaginó el agente. Se trata de un error diferente del que envía la API.

Checklist

  1. Pregunte con qué se ha probado. Pregunte al agente: "¿A qué URL llamó la aplicación durante la prueba y qué fue lo que devolvió el error?" Si la respuesta es un código auxiliar o un servidor local que escribió, trate las pruebas como pruebas unitarias de las ramas que agregó.
  2. Busque interruptores agregados para las pruebas. Busque en el diff las nuevas variables de entorno, la configuración de la dirección URL base o los indicadores. En nuestra prueba, 61 de las 105 ejecuciones en aplicaciones que llaman a GitHub, OpenAI o una API meteorológica añadieron una. Decida si lo desea en producción.
  3. Compruebe el código con respecto al comportamiento documentado de la API. Cada API falla a su manera:
    • GitHub: cuando se supera el límite de frecuencia principal, se obtiene 403 o 429 con x-ratelimit-remaining establecido en 0, y se espera hasta el tiempo en x-ratelimit-reset, en segundos de época UTC. En el caso de los límites de tasa secundarios, espere retry-after si está allí; de lo contrario, hasta x-ratelimit-reset si x-ratelimit-remaining es 0; de lo contrario, al menos 1 minuto. El código que solo comprueba el código 429 pasa por alto los 403.
    • OpenAI: algunos 429s se refieren a los límites de facturación y gasto, como credit_balance_exhausted. Volver a intentarlos no ayudará. El código que reintenta cada 429 te oculta el problema.
    • Anthropic: el límite de gasto 429 no tiene encabezado retry-after y las sobrecargas devuelven 529, algo que el código que solo conoce los códigos de estado estándar podría no esperar.
  4. Compruebe cómo se lee Retry-After. El encabezado contiene un número de segundos o una fecha HTTP (RFC 9110). Compruebe que el código gestiona el formato que envía su API, limita el número de intentos y el tiempo total de espera, y no reintenta además sobre un SDK que ya realiza reintentos.
  5. Compruebe lo que ve el usuario cuando se acaben los reintentos. Busque un mensaje claro en lugar de una traza de pila o un indicador de carga que no termina nunca, y compruebe que el usuario no pierda su trabajo.
  6. Ejecute la aplicación en sus direcciones URL reales con fallos simulados. Este es el único paso que muestra cómo se comportan conjuntamente la aplicación en ejecución, su SDK y su directiva de reintento.

Cómo verificar el control de errores escrito por el agente

Approach Lo que encuentras Lo que te pierdes
Ver el diff Si el código tiene el aspecto correcto Si se comporta correctamente frente a las respuestas reales de la API
Ejecución de las pruebas del agente Que las ramas que escribió se ejecuten Todo lo que la simulación no modeló: códigos de estado reales, cabeceras, cuerpos de error y reintentos del SDK
Llama a la API real hasta que falle Comportamiento real No se pueden provocar fallos a voluntad y se consume cuota real.
Ejecuta la aplicación en URL reales con fallos simulados Cómo la aplicación en ejecución, su SDK y su política de reintentos gestionan los errores de la propia API Tu código de forma aislada. Reserve las pruebas unitarias del agente para eso.

Pruébalo en tu app

Dev Proxy intercepta las solicitudes que tu aplicación envía a la API real y devuelve los errores que elijas, sin necesidad de cambiar el código de tu aplicación. Para las API más populares, empiece con una configuración predefinida. Para comprobar cómo gestionaba tu agente el límite de solicitudes de GitHub, escribió:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Ejecute la aplicación y vea la salida de Dev Proxy. El valor preestablecido devuelve un valor 429 con las cabeceras de límite de tasa de GitHub una vez que la aplicación supera el límite. El RetryAfterPlugin en la configuración predefinida indica si la aplicación vuelve a llamar a la API antes de que termine el tiempo de espera. Los openai-throttling valores preestablecidos y anthropic-throttling hacen lo mismo para los propios errores de límite de velocidad del proveedor y openai-throttling también devuelven un credit_balance_exhausted valor 429 que no se debe reintentar.

Para otras API:

También puede pedir al agente de código que escriba la configuración de Dev Proxy. Agregue el servidor MCP de Dev Proxy al agente para que pueda buscar la documentación de Dev Proxy y los procedimientos recomendados y comprobar qué versión ha instalado. Revise esa configuración igual que cualquier otro código que escriba el agente.

Para instalar Dev Proxy, consulte Configurar Dev Proxy.

Pasos siguientes

Prueba de mi aplicación con errores aleatorios

Consulte también

  • Se actualizó por última vez el