Errores de agentes de código y la regla que los detiene

Cinco fallos que nos enseñaron una regla esencial

En un pequeño laboratorio open‑source en Suiza, los repositorios están casi íntegramente escritos por agentes de código AI de varios proveedores. Cada cambio debe ser revisado por otro agente antes de integrarse, pero la práctica ha mostrado que la confianza del agente no garantiza la validez. A continuación, cinco incidentes y la regla que los evitó.

1. “Tests pasan” en un subconjunto

Un agente ejecutó la suite de pruebas, obtuvo un resultado verde y reportó la confirmación. Poco después, la CI volvió roja porque había ejecutado tests/ en lugar de tests/unit/. El agente también ejecutó seis de diez verificaciones de publicación, recordando solo las que había visto. Regla: enumerar los puntos de control a partir de su definición (configuración CI, archivo de checklist), no de la memoria. El informe debe incluir el comando exacto.

2. Archivo correcto, código que se ejecuta no

Durante una prueba de mutación, se modificó un archivo, el test lo detectó, luego se restauró el archivo desde una copia de seguridad. El hash SHA256 coincidía con HEAD, git status estaba limpio y inspect.getsource mostraba el código correcto, pero la prueba siguió viendo el comportamiento mutado porque el intérprete CPython usó el bytecode caché. Regla: un digest prueba el archivo, no lo que se ejecuta. Para pruebas de mutación, borre __pycache__ o use PYTHONDONTWRITEBYTECODE=1.

3. “Mi watcher está en marcha” falsamente

Un agente afirmó que su observador de mensajes estaba activo durante toda la sesión. La verificación se basó en pgrep -f 'syn-wait.*<name>', que coincía con el propio proceso del agente. Los demás agentes creyeron que el agente era vivo. Regla: una declaración de vivacidad necesita evidencia que excluya al comprobante: espere un PID, socket o archivo marcador.

4. Suite de navegador verde con la compilación equivocada

Un agente inició un servidor estático para pruebas end‑to‑end y detuvo el anterior usando el PID registrado. El proceso real en el puerto era otro, sobrante de una compilación limpia. El nuevo servidor no pudo enlazarse, el runner reutilizó el puerto y la suite quedó verde contra la compilación errónea. Regla: después de iniciar un servidor, lea el PID del puerto, verifique el directorio de trabajo o el ID de compilación y registrelo.

5. Código correcto, commit equivocado

Un agente recibió instrucciones para integrar un commit revisado, pero terminó integrando la punta de la rama, asumiendo que el SHA era un error de copia‑pega. Los dos commits tenían el mismo árbol de archivos; la diferencia era el autor. Regla: integrar el SHA revisado exactamente, no el que apunte la rama. Si el SHA parece incorrecto, confirme antes de integrar.

Lecciones y herramientas

La regla central: la afirmación de un agente no es evidencia. "Tests pasan" vale solo cuando otro agente los re‑ejecuta en el mismo commit con el mismo comando y lo registra. Un hub de coordinación local (SYNAPSE CHANNEL) mantiene un registro durable de eventos, y los agentes sostienen reclamaciones explícitas sobre los archivos que tocan para evitar ediciones silenciosas. Las revisiones se realizan contra un objeto congelado, no contra una rama cambiante.

Los componentes son open‑source:

• SYNAPSE CHANNEL – hub de coordinación local para agentes paralelos.
• Rigor Foundry – revisión vinculada a evidencia y auditoría de repositorios.

Si ejecuta varios agentes en paralelo, comparta los fracasos que más le afectaron. El laboratorio es pre‑seed y recibe financiación de GitHub Sponsors.