⌘J
En esta página 6

Engineering / AI-native workflow

AI-native workflow

Cómo trabajamos con agentes de código en Axel (dónde va el humano, dónde el agente, y por qué el review es el cuello de botella real).

Axel se construye AI-native: la mayor parte del código lo generan agentes (Claude Code) bajo review humano. Esta página fija cómo repartimos el trabajo entre humano y agente, y las reglas que evitan que la velocidad de generación se coma la calidad.

El review humano es el cuello de botella real, no el tipeo. Todo lo de abajo existe para proteger tu capacidad de review, no para generar más código.

La realidad que ordena todo

La data de 2026 es contundente: los equipos que suman IA mergean muchos más PRs pero el review se dispara.

+98% PRs mergeados, +91% tiempo de review

Los PRs asistidos por IA tardan 5.3× más en ser tomados y esperan 2.47× más por review; el 31% se mergean sin ningún review.

Sientes +20%, es −19%

Gap de 39 puntos entre productividad percibida y real. El código de agente mete más redundancia y deuda por cambio que el humano.

Con agentes en paralelo, el humano se vuelve el bottleneck: tu rol pasa de co-escribir código a shapear el trabajo antes de que empiece y juzgarlo cuando termina.

Los cuatro checkpoints human-in-the-loop

Todo trabajo de agente pasa por cuatro compuertas. Ninguna es opcional.

1

Planificación / contexto

Antes de que el agente escriba: issue con acceptance criteria y edge cases (Definition of Ready). El gate más importante es upstream — un buen grooming ahorra más que cualquier review posterior.
2

Ejecución autónoma (sandbox)

El agente clona, trabaja en su entorno y abre un PR con tests que pasan. Tareas chicas y single-purpose — los prompts batcheados grandes dan duplicación e inconsistencia.
3

Verificación por CI

Un suite de tests fuerte corriendo en CI después de cada tarea es lo que deja al agente operar con confianza y cazar sus propios errores.
4

Review humano en el PR

El merge lo decide un humano. Claude Code no puede auto-aprobar ni mergear sus PRs — está bloqueado estructuralmente, así que la aprobación humana (o lógica de CI) es el gate obligatorio.

Qué delega el agente y qué NO

Partimos las tareas por nivel de autonomía:

Alta autonomía (agente)
agente

Boilerplate, backfill de tests, bumps de dependencias, fixes localizados, porteo mecánico con patrón claro.

Humano obligatorio
humano

Migraciones de schema, tuning de performance, seguridad / autorización, debugging de sistemas distribuidos.

Proteger el review (el “review sandwich”)

Tres capas, para reservar tu atención humana a lo que solo tú puedes juzgar:

1

Baseline automático

Lint, type-check, detección de secretos, coverage, SAST. Bloquear cualquier PR de agente que debilite el CI (borra tests, saltea lint) — red flag #1.
2

Triage AI

Un pre-review con un agente (resume + resalta riesgo) antes de tu review. Corta 30–50% de tu tiempo humano. Ver PR review con Claude Code.
3

Review humano

Solo arquitectura, lógica de negocio y mantenibilidad — lo que un reviewer genérico sin contexto del repo no ve.

Para cazar “correctness alucinada” (código que compila pero tiene un off-by-one o un permiso faltante): exige un test que falle con el comportamiento anterior al cambio.

Reglas de la cola de agentes

  • WIP cap en “Awaiting Human Review”: 5–10 cards por reviewer. Tu atención de review es un recurso escaso y se limita aparte de las columnas de agentes.
  • Máx 3–5 ciclos de revisión por tarea antes de escalar a un humano.
  • PRs chicos: cap de tamaño / stacked diffs. Los PRs de IA son ~18% más grandes y suben la carga cognitiva del reviewer.
  • Multi-agente en paralelo con cuidado: 5 agentes al 95% dan 77% de éxito compuesto y consumen 2–5× tokens. Solo cuando el throughput lo justifica.

Métricas que importan

Las de actividad (líneas generadas, cantidad de PRs) suben mientras la entrega se frena. Mira el flujo de review y la entrega estilo , no las métricas de actividad:

Flujo de review

Time-to-first-review · median PR size · review iteration count · reviewer concentration.

Entrega (DORA para IA)

Lead time <1 día · change-failure 0–15% · recovery <1h · AI fix-up PRs.

GitHub como system of record: externaliza todo el estado persistente a AGENTS.md, Issues y PRs para que un agente sin contexto rehidrate rápido al arrancar cada sesión. Los PRs con Closes #N dejan una cadena de trazabilidad recuperable (git blame → commit → PR → issue).