Por qué no se puede confiar en que un agente de IA revise su propio trabajo: un informe que declaraba -9.500 líneas cuando el código en realidad creció +21.489

• Discrepancia entre el informe y el git diff: se declaró una "reducción de ~9.500 líneas", pero el commit real tocó 206 archivos con un crecimiento neto de +21.489 líneas (+34.934 / -13.445)
• Precisión del fact-checking de un libro hecho por un enjambre: se verificaron ~150 afirmaciones en 20 capítulos (69.293 palabras), detectando 13 distorsiones ocultas de estadísticas y fechas
• Embudo de compresión del meta-casebook: 11,67 GB de sesiones JSONL en crudo comprimidos 160 veces hasta 73,8 MB de resúmenes (147 lotes, 860 tarjetas únicas)
• Ancho óptimo de la oleada paralela: 8-14 subagentes simultáneos (al lanzar 44 workers de golpe, toda la oleada choca con los límites del proveedor)

Cuando un proyecto acumula "objetos divinos" (`God objects`) —toda la lógica de base de datos en un archivo, todo el bot en otro—, la refactorización manual tarda semanas. Lancé un enjambre de 25 subagentes contra una base de código así, organizado en cuatro fases: cerrar brechas de seguridad, reanimar contenedores, desarmar monolitos y migrar funcionalidades. Día y medio después, el orquestador entregó un informe brillante: `database.py`, de 1.004 líneas, quedó dividido en 15 archivos de modelos; `report_bot.py`, de 1.759 líneas, en 11 módulos; se habían escrito "185+ tests"; y el mensaje del commit lucía la línea `Net reduction: ~9500 lines of code`.

Medio año después decidí verificar cada cifra de ese informe con comandos de `git`. Resultó que el trabajo estructural se había ejecutado a la perfección, pero casi todos los números del informe vivían en una realidad paralela.

¿Por qué las afirmaciones estructurales del enjambre coinciden archivo

por archivo, mientras que las cifras de líneas y horas son falsas?

El comando `git show --shortstat` sobre el commit de refactorización mostró: 206 archivos modificados, 34.934 inserciones y 13.445 eliminaciones, es decir, un crecimiento neto del árbol de +21.489 líneas, justo donde el agente había declarado una reducción de 9.500 líneas. Los tamaños originales de los archivos también diferían de lo reportado (`883`, `1.696` y `650` líneas en lugar de `1.004`, `1.759` y `904`), y en el diff aparecían solo 164 funciones `test_*`, no "185+".

Sin embargo, todas las afirmaciones estructurales coincidían hasta el último archivo: el paquete de modelos terminó con exactamente 15 módulos, y el viejo `database.py` se había convertido en un wrapper de compatibilidad retroactiva de 8 líneas (`from .models import *`). Una segunda pasada independiente del enjambre encontró y dividió más tarde otros 9 archivos de más de 1.000 líneas que no aparecían en la primera lista (hoy, de 313 archivos con 98.264 líneas, solo queda un módulo de 1.013 líneas).

La distorsión numérica surge de tres causas: pérdida de contexto en los reinicios de sesión, informar la intención antes de comprobar la salida real de la herramienta, y doble contabilización al agregar datos. Cuando un script que construía un casebook a partir de 860 sesiones sumó el campo `time_saved` de las tarjetas de un mismo proyecto —donde cada sesión había estimado por separado el ahorro de todo el proyecto en "40 horas"— el resultado fue la cifra cómicamente inflada de 44.683 horas ahorradas. Cualquier agregado numérico generado por un enjambre debe recalcularse con un script sobre los registros primarios, nunca aceptarse tal cual se reporta.

¿Cómo funciona un pipeline de auditores de solo lectura y correctores,

y por qué comprimir los logs de sesión 160 veces?

Para evitar que el ejecutor califique su propio trabajo, dividimos los roles: primero actúan 5 auditores paralelos de solo lectura (seguridad, bugs, calidad, código muerto, duplicados) con las herramientas de escritura físicamente deshabilitadas y un contrato obligatorio `modifications_made: false` en la cabecera YAML; después, 3 correctores actúan sobre esos informes, que incluyen números de línea exactos y escenarios de reproducción (como una condición de carrera de `row_factory` sobre una conexión SQLite compartida).

El mismo esquema de verificación independiente, aplicado a un manuscrito de libro de 20 capítulos (69.293 palabras), revisó 150 afirmaciones y detectó 13 alucinaciones (una cita invertida —"91% satisfechos" convertida en "90% insatisfechos"—, un acuerdo de licencia de 2.400 millones de dólares etiquetado erróneamente como adquisición, y una previsión de mercado para 2032 de 37.000 millones de dólares citada en lugar de la cifra actual de 4.000 millones). Y para hacer pasar un enjambre por un archivo de 11,67 GB de logs JSONL en crudo, escribimos un preprocesador de resúmenes:

```python SKIP_TOOLS = { "Read", "Glob", "Grep", "LS", "TodoWrite", "ToolSearch", "NotebookRead", "BashOutput", "KillShell", "Monitor", "TaskOutput" }

# Solo conservamos mutaciones (Write/Edit), comandos Bash y la creación de subagentes,

# y la salida de las herramientas se recorta con un tope TOOLRES_CAP = 250 caracteres. ```

Esto comprimió el corpus 160 veces, de 11,67 GB a 73,8 MB (147 lotes de `MAXKB=900`, `MAXN=6`), lo que permitió que un pipeline con IDs de lote estables sobreviviera a tres caídas por límites de la API y aun así reuniera 860 tarjetas.

¿Por qué el propio verificador también puede equivocarse con APIs

nuevas y oleadas demasiado grandes?

Un agente verificador es tan probabilístico como cualquier otro y puede equivocarse en ambas direcciones. Al implementar 173 métodos de una gran Bot API (ampliando la cobertura de la CLI de 19 a 163 comandos, documentada en una referencia de 2.977 líneas), los verificadores cruzaban cada método con 4-5 SDKs de código abierto.

Al topar con una función real recién lanzada que todavía no existía en las librerías antiguas, el enjambre declaró por unanimidad que era una "alucinación del explorador"; hubo que demostrar que era real ejecutando pruebas automatizadas contra un fork recién actualizado. De paso, se descubrió un límite de paralelismo: lanzar 44 verificadores a la vez hizo que toda la oleada chocara con los límites de la API, mientras que los lotes de 8-14 agentes se ejecutaban sin pérdidas.

Un orquestador de enjambres con aceptación independiente y separación de auditores está integrado en [Nomad AI](https://nomadnet.ai) y en el servicio en la nube [agent.nomadnet.ai](https://agent.nomadnet.ai). Se puede aprender a gestionar enjambres multiagente en [Hamidun Academy](https://academy.hamidun.com) (prueba de 72 horas), y los scripts de compresión de logs y los prompts de los revisores están disponibles en [Vibe Club](https://hamidun.com/club).