Patrones de Diseño
Flujo de TrabajoIntermedio

Gobernanza basada en compuertas

Cómo implementar compuertas de calidad automatizadas y con intervención humana (human-in-the-loop) para el código generado por agentes.

Resumen

La Gobernanza basada en compuertas es un patrón de control de calidad que dirige el código generado por agentes a través de un sistema por niveles de verificaciones automatizadas y puntos de revisión humana antes de que llegue al código base principal. En lugar de revisar toda la salida del agente con el mismo escrutinio, este patrón separa las validaciones rutinarias (que las máquinas manejan bien) de las decisiones que requieren gran criterio (que requieren atención humana), dirigiendo cada una a la compuerta adecuada.

El patrón implementa el pilar de Gobernanza basada en compuertas del Agentic Development Handbook. Las compuertas automatizadas — potenciadas por un Eval Harness — detectan violaciones de formato, fallos en las pruebas, errores de tipo y problemas de conformidad arquitectónica. Las compuertas Human In The Loop detectan compromisos de diseño, implicaciones de seguridad y decisiones que requieren contexto de negocio. Juntas, garantizan una calidad constante sin crear cuellos de botella.

Problema

Los equipos que introducen agentes de IA en su flujo de trabajo de desarrollo se enfrentan a un dilema de gobernanza:

  • Sin compuertas en absoluto. El código del agente va directamente a las pull requests. Los revisores se ven abrumados por el volumen y la calidad inconsistente. Las violaciones arquitectónicas, los problemas de seguridad y los errores lógicos sutiles pasan desapercibidos porque los revisores humanos no pueden escalar para igualar la velocidad de salida del agente.
  • Revisión de talla única. Cada cambio generado por el agente recibe el mismo proceso de revisión manual. Las correcciones de formato triviales consumen la misma atención del revisor que los cambios de autenticación críticos para la seguridad. Los revisores se agotan y comienzan a aprobar sin revisar a fondo.
  • Solo revisión a posteriori. Los controles de calidad ocurren después de que el agente ha terminado. En ese punto, una violación arquitectónica puede estar profundamente arraigada en la implementación. El retrabajo es costoso. El agente puede haber construido cinco componentes sobre una base defectuosa.
  • Sin ruta de escalada. Cuando una verificación automatizada falla, no hay un proceso definido para lo que sucede a continuación. ¿Vuelve a intentarlo el agente? ¿Interviene un humano? ¿Se reasigna la tarea? Sin una escala de escalada clara, los fallos estancan el flujo de trabajo.

Solución

Implementar un sistema de compuertas por niveles con cuatro componentes:

  1. Compuertas automatizadas — Verificaciones rápidas y deterministas que se ejecutan en cada salida del agente. Estas incluyen linting, verificación de tipos, ejecución de pruebas, escaneo de seguridad y validación de conformidad arquitectónica. Configúrelas como parte del Eval Harness con criterios de aprobación/fallo extraídos de los criterios de aceptación de Live Spec.

  2. Bucle de reintento del agente — Cuando una compuerta automatizada falla, el agente recibe los diagnósticos del fallo e intenta solucionar el problema. Establezca un límite de reintentos (normalmente 2-3 intentos) para evitar bucles infinitos.

  3. Compuertas Human In The Loop — Los cambios que superan las compuertas automatizadas pero cumplen ciertos criterios (rutas críticas de seguridad, decisiones arquitectónicas, alto radio de impacto) se marcan para revisión humana antes de la integración. Estas compuertas centran la atención humana donde tiene el mayor impacto.

  4. Escala de escalada — Un proceso definido de cuatro fases para manejar los fallos que los reintentos automatizados no pueden resolver. Sigue la Escala de Escalada de Cuatro Fases del manual: reintento automatizado, ajuste de parámetros, Blocker Flag y pausa, Rescue Mission con intervención humana.

El Eval Harness es el motor detrás de las compuertas automatizadas. Lee los criterios de aceptación del Live Spec, ejecuta las verificaciones configuradas y genera un informe de aprobación/fallo. El Context Architect y el Ingeniero de Evaluación colaboran para definir qué verificaciones se ejecutan en cada compuerta.

Implementación

1

2

3

4

5

Ejemplos de Código

CI/CD Gate Configuration (GitHub Actions)
# .github/workflows/agent-gates.yml
name: Agent Output Gates

on:
  pull_request:
    branches: [main]
    # Only run on PRs labeled as agent-generated
    types: [labeled]

jobs:
  automated-gates:
    if: contains(github.event.pull_request.labels.*.name, 'agent-generated')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Gate 1 — Lint and Format
        run: |
          npm run lint
          npm run format:check

      - name: Gate 2 — Type Check
        run: npm run typecheck

      - name: Gate 3 — Unit Tests
        run: npm run test:unit -- --coverage

      - name: Gate 4 — Security Scan
        run: |
          npm audit --audit-level=high
          npx semgrep --config p/typescript src/

      - name: Gate 5 — Architecture Conformance
        run: node scripts/check-architecture.js

  hitl-gate-triage:
    needs: automated-gates
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Check HITL triggers
        id: hitl
        run: |
          node scripts/check-hitl-triggers.js \
            --pr=${{ github.event.pull_request.number }}

      - name: Request human review
        if: steps.hitl.outputs.required == 'true'
        uses: actions/github-script@v7
        with:
          script: |
            await github.rest.pulls.requestReviewers({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: ${{ github.event.pull_request.number }},
              reviewers: ${{ steps.hitl.outputs.reviewers }}
            });
Architectural Conformance Check
// scripts/check-architecture.ts
import { readFileSync, readdirSync } from "fs";
import { join } from "path";

interface ConformanceRule {
  name: string;
  check: (filePath: string, content: string) => string | null;
}

const rules: ConformanceRule[] = [
  {
    name: "no-direct-db-access-in-components",
    check: (filePath, content) => {
      if (filePath.includes("/components/") && content.includes("prisma")) {
        return `Components must not access the database directly. Use a service layer. Found in ${filePath}`;
      }
      return null;
    },
  },
  {
    name: "no-circular-imports",
    check: (filePath, content) => {
      if (
        filePath.includes("/services/") &&
        content.includes("from '../components/")
      ) {
        return `Services must not import from components. Found in ${filePath}`;
      }
      return null;
    },
  },
  {
    name: "test-co-location",
    check: (filePath, content) => {
      if (
        filePath.endsWith(".tsx") &&
        !filePath.endsWith(".test.tsx") &&
        filePath.includes("/components/")
      ) {
        const testPath = filePath.replace(".tsx", ".test.tsx");
        try {
          readFileSync(testPath);
        } catch {
          return `Missing co-located test file for ${filePath}`;
        }
      }
      return null;
    },
  },
];

function checkConformance(directory: string): string[] {
  const violations: string[] = [];

  function walk(dir: string) {
    for (const entry of readdirSync(dir, { withFileTypes: true })) {
      const fullPath = join(dir, entry.name);
      if (entry.isDirectory() && entry.name !== "node_modules") {
        walk(fullPath);
      } else if (entry.name.endsWith(".ts") || entry.name.endsWith(".tsx")) {
        const content = readFileSync(fullPath, "utf-8");
        for (const rule of rules) {
          const violation = rule.check(fullPath, content);
          if (violation) violations.push(`[${rule.name}] ${violation}`);
        }
      }
    }
  }

  walk(directory);
  return violations;
}

const violations = checkConformance("src/");
if (violations.length > 0) {
  console.error("Architectural conformance violations found:");
  violations.forEach((v) => console.error(`  - ${v}`));
  process.exit(1);
} else {
  console.log("All architectural conformance checks passed.");
}
HITL Gate Trigger Detection
// scripts/check-hitl-triggers.ts
interface HITLTrigger {
  condition: string;
  reason: string;
  reviewer: string;
}

const triggers: HITLTrigger[] = [
  {
    condition: "auth",
    reason: "Security-critical path modified",
    reviewer: "security-lead",
  },
  {
    condition: "migration",
    reason: "Database migration detected",
    reviewer: "dba-team",
  },
  {
    condition: "package.json",
    reason: "Dependencies modified",
    reviewer: "tech-lead",
  },
];

function evaluateTriggers(changedFiles: string[]): HITLTrigger[] {
  return triggers.filter((trigger) =>
    changedFiles.some((file) => file.includes(trigger.condition))
  );
}

Consideraciones

Beneficios
  • **Consistent quality at scale.** Automated gates catch the same classes of issues every time, regardless of how many agents are producing code. Human reviewers do not need to check for formatting, type errors, or known security patterns.
  • **Focused human attention.** [[human-in-the-loop]] gates direct reviewer effort to decisions that genuinely require human judgment — architectural trade-offs, security implications, business logic correctness. This reduces reviewer fatigue and improves review quality.
  • **Measurable governance.** Gate pass rates, retry success rates, and escalation rates provide concrete data on agent output quality and governance effectiveness. Teams can identify systemic issues and track improvement over time.
  • **Clear escalation path.** The Four-Phase Escalation Ladder eliminates ambiguity about what happens when something fails. Every team member knows the process, reducing ad-hoc interventions and blocked work.
  • **Early failure detection.** Gates catch issues before they compound. An architectural violation caught at the gate level is far cheaper to fix than one discovered after five dependent components have been built on top of it.
Desafíos
  • **Initial gate configuration effort.** Defining which checks run, what thresholds to set, and which HITL triggers to configure requires upfront investment. Start with a minimal set and expand based on data from the first few weeks.
  • **False positive management.** Overly strict automated gates produce false positives that slow the workflow and erode trust. Monitor the false positive rate and tune thresholds regularly. An advisory (non-blocking) tier helps identify where gates are too aggressive.
  • **Balancing speed and thoroughness.** Too many gates slow the development loop. Too few gates let quality issues through. The right balance depends on the codebase, the team's risk tolerance, and the maturity of the agents. Review gate configuration monthly.
  • **Escalation culture.** The escalation ladder only works if the team uses it consistently. If engineers bypass gates or skip phases, the system degrades. Leadership must reinforce that escalation is a normal part of the workflow, not a sign of failure.
  • **Gate maintenance.** As the codebase evolves, gates must evolve with it. New architectural rules need new conformance checks. New security patterns need new scanning rules. Assign ownership of gate maintenance to the Evaluation Engineer role.