416 pruebas y un botón 'destruir todo': dónde fallan los proyectos de agentes

El autor ha estado ejecutando un agente autónomo llamado Groundhog (Surok) desde febrero de 2026 en un bucle de investigación con Claude Code y la bandera --dangerously-skip-permissions. Luego auditó seis de sus propios proyectos de agentes frente a una lista de verificación compuesta de seis fuentes (incluyendo la metodología de ciclo de vida de desarrollo de producto AI-DISRUPT de Sber) y encontró tres patrones de falla recurrentes: seguridad aplicada solo en instrucciones (el modelo puede ser anulado), acciones irreversibles sin confirmación (por ejemplo, un comando de reconstrucción borra todos los datos enriquecidos) y cero pruebas de regresión para errores de comportamiento. El autor también revisó un proyecto anónimo de agente de código abierto grande: tenía verificaciones de permisos a nivel de código y pruebas de regresión para errores pasados, pero aún así enviaba correos electrónicos de forma irreversible sin un paso de borrador/confirmación. Un framework de código abierto más nuevo (HarnessX) ofrece una puerta de interrupción (interrupt_on) pero es opcional y no está activada por defecto. La metodología de ciclo de vida de desarrollo de producto de Sber formaliza muchos de los controles faltantes: políticas como código, evaluaciones como contratos de finalización y una escalera de permisos R0–R5 con aborto/retroceso obligatorio para operaciones que cambian el estado en R3+. El autor construyó un séptimo proyecto implementando algunas lecciones aprendidas: ahora las evaluaciones se ejecutan antes de cada lanzamiento y los incidentes se convierten en pruebas de regresión con nombre.