Mi configuración completa de Agentes de Código (Nunca antes compartida)

Aquí está mi configuración completa de agente de codificación. Método completo de andamiaje detrás de mis agentes de código:

• AGENTS.md enruta, no instruye. Apunta al agente hacia la habilidad, documento o herramienta correcta para la tarea que tiene delante.
• Un documento de flujo de trabajo se sitúa en la parte superior, referenciado con @/AGENT_WORKFLOW.md en la mayoría de las sesiones.
• Cada sistema tiene su propio documento de auto-reparación, el agente lo mantiene actualizado, las primeras líneas son un resumen denso para que grep encuentre el archivo rápido.
• El agente ejecuta la propia aplicación. La lanza, prueba el cambio, arregla lo que se rompe, especialmente en ejecuciones mientras duermo.
• Las pruebas de extremo a extremo se escriben y actualizan durante la implementación. Un documento rastrea cada prueba y lo que cubre, otro explica cómo escribir nuevas y qué omitir.
• Los hooks de pre-commit ejecutan linters personalizados. Cuando --fix no puede resolver algo, llama a un modelo más barato, Composer 2.5 o Sonnet, para limpiar el código en lugar de solo marcarlo.
• Revisión cruzada entre agentes en investigación, planificación, implementación y cierre. Codex revisa el trabajo de Claude, Cursor revisa el de Codex.
• Cada revisión se ejecuta a través de una persona: mantenibilidad, seguridad, rendimiento, a veces un especialista del dominio. Cada persona es dueña de una sección de los documentos.
• Las hojas de trabajo siguen cada sesión. Si un agente muere a mitad de camino, le paso la hoja a uno nuevo y retoma donde el anterior se detuvo. Se confirma con el trabajo, etiqueta git que coincide con el nombre de la hoja.
• Al final de la sesión, el agente escribe retroalimentación en un documento. También lo confirmo y lo releo periódicamente para ajustar el flujo de trabajo.
• Una carpeta de herramientas contiene scripts que el agente construyó para sí mismo. agent_review es el que más uso, inicia revisiones entre modelos desde la línea de comandos.
• Barridos periódicos revisan commits recientes en busca de patrones que un solo diff no mostraría.
• Una auditoría de falsa confianza verifica si las pruebas están probando lo que creo que están probando.
• Las regresiones visuales ejecutan capturas de pantalla a través de una herramienta de comparación más una revisión de agente. Confirmado con git LFS.
• Los benchmarks de rendimiento marcan regresiones automáticamente. Una herramienta de perfilado separada permite al agente probar algo y comparar antes y después.
• El final del turno significa validación completa: cada prueba, cada revisión, cada barrido, para que lo que abra esté limpio.
• Hay auditorías de falsa confianza que aún no detectan cosas que quiero que detecten, pero aún no lo he solucionado.

Visto en r/AskVibecoders