¿Cuánto código de agente de IA tienes que revisar en realidad?

Respuesta corta: en tres semanas de un repositorio donde los agentes de IA escriben casi cada línea, 88 commits cambiaron 35.492 líneas. El commit mediano tuvo 85 líneas, lo bastante pequeño para leerlo con un café, pero 7 commits, el 8% de ellos, cargaron la mitad del total, y un solo día entregó 12.679 líneas en 105 archivos. La carga de revisión de agentes de IA no llega como flujo, llega en ráfagas, así que planifica el día por el pico y no por el promedio.

¿Cuánto código de agente de IA llega en tres semanas?

En el repositorio detrás de CanvasCode, donde los agentes de IA de programación escriben casi cada línea y una persona revisa antes de cualquier merge, tres semanas produjeron 88 commits y 35.492 líneas cambiadas, sumando inserciones y borrados. Esos 88 son los commits que introducen líneas: el período contiene además 27 commits de merge, para los que git no reporta estadística de líneas porque no llevan cambios propios. Esa es la carga bruta de revisión, y cada una de esas líneas tuvo que pasar por los ojos de alguien antes de llegar a la rama principal.

El número que nos sorprendió no fue el total, fue el calendario. De 21 días, solo 10 tuvieron algún commit. Los otros 11 no produjeron nada que revisar, es decir, el trabajo no se repartió por el período. Se apiló en un tercio de los días y dejó el resto vacío. Un promedio de 1.690 líneas por día es aritméticamente cierto y no describe ningún día que haya ocurrido.

¿Por qué la mediana engaña sobre la carga de revisión de IA?

El commit mediano de esas tres semanas cambió 85 líneas. Mediana aquí es el valor del medio una vez ordenados todos los commits por tamaño, y con un número par de commits es el promedio de los dos centrales, 85,5, que el comando de abajo imprime como 85. Leído solo, ese número dice que revisar es fácil: 85 líneas son unos minutos de atención.

La distribución dice otra cosa. Ordenando los mismos 88 commits de mayor a menor, 7 de ellos cargan la mitad de las 35.492 líneas. El commit más grande cambió 4.007 líneas por sí solo. O sea, el commit típico es pequeño y la carga no lo es, porque la carga vive en la cola. Cualquier planificación construida sobre la mediana, del tipo reservar media hora al día para revisar lo que produjeron tus agentes de IA, sobrevive la mayoría de los días y se derrumba justo en los días que importan.

¿Cómo es un día pico de salida de agente de IA?

El peor día de la ventana, 7 de agosto de 2026, entregó 25 commits y 12.679 líneas cambiadas tocando 105 archivos distintos. Es el 36% de tres semanas de producción llegando dentro de un solo día. El primer commit cayó a las 12:51 y el último a las 23:23, diez horas y media después, así que tampoco fue una sentada: el día fue un goteo constante que sumó una inundación.

Esa es la forma que rompe la revisión, y la rompe de un modo específico. Quien revisa 12.679 líneas no puede aplicar el mismo cuidado en la línea 12.000 que en la línea 100. Los desenlaces realistas son aprobar en bloque, lo que anula la revisión, o parar a los agentes mientras te pones al día, lo que anula el paralelismo que montaste. Ninguno de los dos es problema de técnica, y ninguno mejora leyendo más rápido.

¿Cómo medir la carga de revisión en tu propio repositorio?

Dos comandos, git puro y awk POSIX, sin herramienta extra. Suman inserciones y borrados, porque una línea borrada también hay que leerla antes de aceptar que se vaya. El primero imprime el total, la mediana y cuán concentrada está la carga. Ejecútalo dentro de cualquier repositorio:

git log --since=3.weeks --pretty=tformat:'C' --shortstat |
awk '/files? changed/{
  ins=0; del=0
  for (i=1; i<=NF; i++) {
    if ($(i+1) ~ /^insertion/) ins=$i
    if ($(i+1) ~ /^deletion/)  del=$i
  }
  print ins+del
}' | sort -rn | awk '{ t+=$1; a[NR]=$1 }
END {
  half=t/2; s=0
  for (i=1; i<=NR; i++) { s+=a[i]; if (s>=half) break }
  printf "%d commits, %d lines changed\n", NR, t
  printf "median %d lines per commit\n", (NR%2 ? a[(NR+1)/2] : (a[NR/2]+a[NR/2+1])/2)
  printf "%d commits (%.0f%%) carry half of that\n", i, i*100/NR
}'

En nuestro repositorio imprime:

88 commits, 35492 lines changed
median 85 lines per commit
7 commits (8%) carry half of that

Esa salida es la nuestra el 13 de agosto de 2026. La ventana es relativa, así que el mismo comando ejecutado otro día cubre otras tres semanas: compárala con tu número, no con el impreso arriba. El segundo comando muestra el calendario, que es donde la ráfaga se hace visible:

git log --since=3.weeks --pretty=tformat:'C %ad' --date=format:'%Y-%m-%d' --shortstat |
awk '/^C /{ d=$2; next }
     /files? changed/{
       ins=0; del=0
       for (i=1; i<=NF; i++) {
         if ($(i+1) ~ /^insertion/) ins=$i
         if ($(i+1) ~ /^deletion/)  del=$i
       }
       n[d]++; L[d]+=ins+del
     }
     END { for (d in L) printf "%s  %3d commits  %6d lines\n", d, n[d], L[d] }' | sort

Si tu salida tiene pocos días enormes y muchos días vacíos, tu problema de revisión es de agenda, no de técnica.

¿La ráfaga cambia cómo deberías revisar?

Cambia lo que haces antes de revisar, no la revisión en sí. El orden que usamos para leer salida de agente de IA es el mismo en un día tranquilo y en un día pico: empezar por lo que no debería haber cambiado, luego buscar la prueba que fallaría si eso estuviera mal, y solo entonces leer el código. Ese método es otro artículo, cómo revisar código escrito por varios agentes de IA, y este de propósito no lo repite.

La frontera entre los dos merece decirse con todas las letras, porque responden preguntas distintas. Aquel artículo responde cómo revisar una entrega de un agente de IA. Este responde cuánto llega y cuándo, que es una pregunta de capacidad. Ningún método te salva de un día de 12.679 líneas. Solo cambiar la llegada lo hace.

¿Se puede suavizar la ráfaga en vez de absorberla?

Tres cosas mueven la llegada, y ninguna es revisar más rápido. La primera es pedir entregas más pequeñas por frente, que es la única palanca bajo control directo de quien revisa. La segunda es una puerta de máquina antes de la humana: pruebas, formateador y análisis estático corriendo en cada frente, para que lo que llega a una persona ya se sepa que compila y pasa. En nuestro repositorio nada llega a revisión sin esa puerta, y por eso el día pico fue sobrevivible.

La tercera es secuenciar los merges en vez de dejar que los frentes terminen a la vez, que es el mismo problema descrito en cómo integrar el trabajo de varios agentes de IA. Frentes que aterrizan juntos producen ráfaga aunque cada uno fuera razonable por separado. Escalonarlos convierte un día irrevisable en tres días revisables.

Dónde se midió esto, y qué no demuestra

Un repositorio, tres semanas, medido el 13 de agosto de 2026, en una aplicación web Laravel donde agentes de IA escriben contenido y funcionalidades bajo puerta humana. Es una muestra pequeña y un tipo específico de proyecto. Tu distribución será distinta, y los comandos de arriba existen para que compruebes la tuya en vez de confiar en la nuestra.

Dos límites que conocemos. Primero, cinco de los 88 commits no llevan marcador de sesión, así que cualquier lectura por sesión de estos datos está incompleta; los números de este artículo cuentan todo commit sin merge y no dependen de ese marcador. Segundo, línea cambiada es una aproximación del esfuerzo de revisión, no una medida: 500 líneas de una migración generada se leen más rápido que 50 líneas de lógica de negocio. La ráfaga es real, pero el costo exacto de una línea no es algo que esta medición pueda zanjar.