El loop de verificación

El código generado parece seguro de sí mismo esté bien o mal. La única defensa confiable es un loop que lo verifique: pruebas que deciden, un diff que tú lees y gates que corren sin importar quién escribió el código.

pytest / Jest / go testSemgrepCodeQLpre-commitGitHub Actionsmutation testing (Stryker, mutmut)

Qué es

Un es el conjunto de comprobaciones que todo cambio pasa antes de ser considerado confiable, sin importar quién lo escribió. Con código escrito por IA el loop importa más, porque el volumen es mayor y los errores son plausibles: nombres de función inventados, comportamiento alterado en silencio, pruebas reescritas para que pasen, casos límite ausentes.

Capas de verificación

Primero las pruebas: escribe o aprueba la prueba antes de la implementación, para que una prueba fallida defina qué es "terminado". Pide al agent que la ejecute y muestre la salida.
Lee el diff: no el resumen del agent, el cambio real. Mira qué tocó más allá de lo pedido, pruebas eliminadas, aserciones relajadas, nuevas dependencias y configuración modificada.
Gates automatizados en CI: lint, tipos, pruebas unitarias y de integración, , escaneo de dependencias y de secretos. Corren en cada pull request sin importar el autor.
Revisión independiente: pide a otro modelo, o a una persona, que revise con contexto nuevo y sin memoria del razonamiento del autor.
Ejecútalo: para cualquier cosa de cara al usuario, ejecuta el flujo real en lugar de confiar en que el código compila.

Modos de falla comunes del código generado

APIs y paquetes alucinados: la llamada o la biblioteca no existe, o existe con otro nombre (y un atacante pudo haber registrado el nombre inventado).
Pruebas que no demuestran nada: aserciones sobre mocks, snapshots actualizados para coincidir con el bug o pruebas eliminadas para poner el build en verde.
Solo el camino feliz: sin manejo de entrada vacía, timeouts, concurrencia o entrada hostil.
Valores por defecto inseguros: SQL armado con strings, verificación TLS desactivada, amplio, secretos hard-coded, falta de verificaciones de autorización.
Scope creep: refactors no relacionados mezclados con el cambio, que ocultan el diff real.

Un gate que puedes copiar

Haz que las verificaciones sean obligatorias y automáticas. El workflow de abajo corre en cada pull request y bloquea el merge cuando falla cualquier paso; es el mismo para autores humanos y agents.

.github/workflows/verify.ymlyaml

name: verify
on: pull_request
permissions:
  contents: read
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<full-commit-sha>
      - uses: actions/setup-node@<full-commit-sha>
        with: { node-version: 22 }
      - run: npm ci --ignore-scripts
      - run: npm run lint && npm run typecheck
      - run: npm test -- --coverage
      - run: npx semgrep --config p/owasp-top-ten --error src/
      - run: npx osv-scanner --lockfile=package-lock.json

pre-commit (local, rápido)bash

# el .pre-commit-config.yaml ejecuta esto antes de cada commit, incluidos los de agents
gitleaks protect --staged --redact
npm run lint --silent
npm test --silent -- --bail

Hábitos

Nunca aceptes un cambio que no podrías explicar a un compañero.
Mantén los cambios lo bastante pequeños como para revisarlos en minutos.
Protege las pruebas: exige revisión para ediciones en archivos de prueba y en la configuración de CI.
Pide al agent que enumere sus supuestos y lo que no probó.
Mide la calidad de las pruebas, no solo la cobertura: el mutation testing muestra si las pruebas detectarían un cambio roto.

Loop de verificaciónLas comprobaciones que todo cambio debe pasar antes de ser considerado confiable: pruebas que deciden, un diff que tú lees, gates de CI y revisión independiente.ver en el glosario →SASTAnálisis estático: examina el código sin ejecutarlo. Encuentra problemas por análisis de flujo, no por adivinación.ver en el glosario →CORSintercambio de recursos entre orígenesUn mecanismo del navegador que permite a un servidor indicar qué otros orígenes pueden leer sus respuestas. Un origen comodín combinado con credenciales es una mala configuración.ver en el glosario →

conexiones en el mapa

Orquestación y agents en paraleloproduce trabajo paraEl loop de verificación
Context engineering para agents de códigodefine las verificaciones deEl loop de verificación
El loop de verificaciónincluyeProteger al propio agent

actualizado el 14/10/2026 · fuentes para profundizar · reportar un error

en otros dominios

SASTappsecel gate que vale para cualquier autor, humano o agente
DevSecOpsappsecgates automáticos en el pipeline, sin excepción para código generado