Bucle de verificación de IA

El bucle de verificación de IA mide si un agente de codificación con IA puede preparar el proyecto, ejecutarlo y verificar su propio cambio sin ayuda humana. Este es el quid del trabajo autónomo de los agentes — un agente que puede comprobar su trabajo se potencia de forma compuesta; uno que no puede se limita a generar texto plausible — y por ello tiene el mayor peso en la insignia de Preparación para IA.

• Categoría: Preparación para IA (40 % dentro de la categoría)
• Peso en el índice general: 1.6%
• Clave de la métrica: ai_verify_loop

Cómo se calcula el valor

Pinned-Dependencies es evidencia compartida: aporta información de reproducibilidad de la cadena de suministro al bucle de verificación del agente, sin dejar de ser un componente pleno de Seguridad. Se excluye cuando Scorecard no está disponible o informa n/a.

Evidencia, no solo equipamiento

Todos los demás componentes de aquí leen los archivos del repositorio: existe un ejecutor de tareas, existe un lockfile. Cada uno es un indicador indirecto de un bucle que nadie ha visto ejecutarse.

Los commits cuya autoría corresponde a un agente de codificación — o que se le acreditan en un trailer Co-authored-by — son el único registro disponible de que el bucle se cerró de verdad. Se propuso un cambio, se verificó y se fusionó con un agente en el bucle, y el propio historial del proyecto lo dice.

El pull request de un bot de dependencias también tiene autoría de máquina, y debe superar las mismas puertas: las pruebas se ejecutan, las comprobaciones pasan, se fusiona. Un proyecto que ya absorbe ese tráfico ha mostrado la vía que un agente necesita, y por eso el mantenimiento automatizado se puntúa junto a la práctica de agentes en lugar de plegarse dentro de ella: cualquiera de los dos puede darse sin el otro.

Lo que cuenta son los commits observados, no el archivo de configuración. Un dependabot.yml puede estar en un repositorio con la integración desactivada, y Renovate suele configurarse por completo fuera del repositorio: dos proyectos de amplio uso lo ejecutan en aproximadamente un tercio de sus commits sin llevar ningún archivo de configuración reconocible. Solo califican los bots que redactan su propio contenido — un robot que fusiona el trabajo ajeno no está escribiendo cambios.

Esos mismos commits cuentan en contra de un repositorio en actividad de desarrollo, donde la automatización que desplaza el trabajo humano es una señal de alerta. Es deliberado. Las dos métricas hacen preguntas distintas: si las personas siguen manteniendo un proyecto, y si las máquinas pueden contribuir a él. Ambas respuestas pueden ser ciertas a la vez.

Esto evidencia adopción, no autonomía. Quien mantiene el proyecto trabajando de forma interactiva con un agente deja el mismo rastro que una ejecución sin supervisión, y los datos públicos no permiten distinguirlos; por eso el componente lleva un peso modesto y no afirma nada sobre qué parte del trabajo hizo el agente. La detección, además, solo reconoce los agentes que conoce, de modo que un proyecto que use una herramienta no reconocida simplemente se lee como carente de evidencia — nunca como suspenso.

El componente se excluye en lugar de puntuarse como cero cuando no se recogió ninguna muestra de commits.

Por qué la cadena de herramientas cuenta como arranque

cargo test y go test ./... son los bucles de verificación canónicos de sus lenguajes. Acreditar solo los ejecutores de tareas penalizaba a esos ecosistemas por tener mejores valores por defecto — proyectos Rust bien llevados puntuaban cero en este componente por no incluir Makefile. package.json y pyproject.toml deliberadamente no se acreditan: npm y Python no definen ningún comando de prueba universal, y si un proyecto concreto define uno reside en contenidos de archivo que esta métrica no lee.

Por qué este bucle decide la utilidad del agente

Cada componente elimina un modo de fallo del trabajo autónomo:

• Arranque — el agente puede pasar del clon a la ejecución sin arqueología.
• Pruebas — el agente puede demostrar que un cambio hizo lo que se pretendía.
• Lint y tipos — clases enteras de errores se detectan mecánicamente, antes de la revisión.
• Entorno reproducible — «funciona en el sandbox del agente» significa que también funciona en otros lugares.

Cabe destacar que se trata de la misma infraestructura que sirve a los contribuyentes humanos — la métrica no premia ninguna rareza específica de agentes más allá de lo que un proyecto disciplinado ya posee. Un proyecto fuerte en Calidad de Ingeniería suele partir con ventaja aquí.

Cómo leer el resultado

• Las señales confirman la existencia del bucle, no su velocidad ni su cobertura — la regla de honestidad basada en presencia de toda la insignia.
• Un bucle de verificación alto con un contexto para agentes en estado de esbozo suele indicar un proyecto bien construido que simplemente aún no ha escrito orientación para agentes — la mejora más barata posible.

Cómo mejorar el valor

• Añadir un Makefile (o justfile/Taskfile) que exponga los objetivos install, test y lint.
• Mantener una suite de pruebas automatizadas ejecutable en local con un solo comando.
• Adoptar la verificación de tipos — incluso un mypy/tsconfig mínimo cuenta.
• Confirmar en el repositorio un lockfile, un Dockerfile o un devcontainer para la reproducibilidad del entorno.
• Donde ya se usen agentes, conservar el trailer Co-authored-by que las herramientas añaden por defecto. Eliminarlo suprime la única evidencia pública de que el bucle se cierra en la práctica.

Relacionado: Legibilidad del código para IA · prácticas de ingeniería