Su agente escribe más rápido de lo que usted puede leer

El martes pasado, mi agente de codificación autónomo completó una refactorización de 47 archivos en 9 minutos. Las pruebas pasaron. El linting pasó. Las puertas de calidad encontraron cero violaciones. Fusioné el PR, desplegué y seguí adelante. Tres días después, un compañero de equipo preguntó por qué la lógica de reintentos en el servicio de pagos había cambiado de backoff exponencial a polling de intervalo fijo. Yo no sabía que había cambiado. El mensaje de commit del agente decía “refactor: standardize retry patterns across services.” El cambio era técnicamente correcto. Nunca leí la línea 847 del archivo 31.

Esa brecha entre lo que se desplegó y lo que yo comprendí es deuda cognitiva.

TL;DR

Cinco equipos de investigación independientes publicaron sobre el mismo problema estructural en una semana: los agentes de codificación producen resultados más rápido de lo que los desarrolladores pueden verificar, comprender y mantener. Margaret-Anne Storey nombró el patrón “deuda cognitiva.” Investigadores de Microsoft, ETH Zurich y múltiples universidades están construyendo sistemas para detectar comportamientos erróneos de agentes, hacer transaccionales las llamadas a herramientas y evaluar cómo los agentes aprenden a través de la interacción. La convergencia importa porque señala que la comunidad investigadora está alcanzando un problema que los profesionales han estado resolviendo con puertas de calidad ad-hoc. El problema de fiabilidad de agentes ahora tiene un nombre, una taxonomía y cinco enfoques en competencia. A continuación: la investigación, cómo detectar la deuda cognitiva en su propio flujo de trabajo y una intervención mínima viable que puede implementar hoy.

Cinco artículos, una semana, un problema

Entre el 15 y el 21 de febrero de 2026, cinco grupos independientes publicaron trabajo que aborda la misma falla estructural en los agentes de codificación con IA. Ninguno citó a los otros. Cada uno abordó el problema desde un ángulo diferente. Todos convergieron en la misma conclusión: el cuello de botella en el desarrollo asistido por agentes ya no es la calidad del código. El cuello de botella es la comprensión humana.

Margaret-Anne Storey articuló el concepto de “deuda cognitiva” para describir lo que se acumula cuando los agentes producen código que puede ser limpio, probado y bien estructurado mientras los desarrolladores pierden la noción de lo que el código realmente hace.¹ La deuda técnica vive en el código fuente. La deuda cognitiva vive en la cabeza del desarrollador. El marco de Storey desplaza la pregunta de fiabilidad del agente de “¿funciona el código?” a “¿el desarrollador comprende el código?”

Nanda et al. en Microsoft publicaron Wink, un sistema para detectar y recuperarse automáticamente de comportamientos erróneos de agentes de codificación.² Su taxonomía identifica tres modos de fallo: desviación de instrucciones (el agente hace algo diferente de lo que se le pidió), bucles repetitivos (el agente intenta el mismo enfoque fallido repetidamente) y uso incorrecto de herramientas (el agente llama a la herramienta equivocada o pasa argumentos incorrectos). Wink monitorea el comportamiento del agente en tiempo real e interviene antes de que el error se acumule.

Mohammadi et al. en ETH Zurich introdujeron Atomix, un entorno de ejecución que envuelve las llamadas a herramientas del agente en transacciones.³ Cuando el plan de múltiples pasos de un agente falla a mitad de camino, Atomix revierte los efectos secundarios. La idea clave: los agentes actúan sobre sistemas externos (bases de datos, APIs, sistemas de archivos), y esas acciones tienen consecuencias que el agente no puede deshacer sin infraestructura explícita de reversión.

Hallinan et al. crearon OpaqueToolsBench, un benchmark que mide cómo los agentes aprenden el comportamiento de herramientas a través de la interacción en lugar de la documentación.⁴ Las herramientas del mundo real están mal documentadas. El benchmark evalúa si los agentes pueden descubrir modos de fallo, mejores prácticas y casos límite por ensayo y error. El hallazgo: los agentes que exploran el comportamiento de las herramientas de forma independiente producen mejores resultados que los agentes a los que se les da documentación perfecta que nunca verifican.

Deng et al. evaluaron 28 sistemas de pruebas de penetración basados en LLM e identificaron dos categorías distintas de fallos.⁵ Los fallos de Tipo A provienen de capacidades faltantes (herramientas incorrectas, prompts deficientes) que la ingeniería corrige fácilmente. Los fallos de Tipo B persisten independientemente de las herramientas porque el agente carece del juicio para evaluar sus propios hallazgos. El Tipo B es el problema de la deuda cognitiva expresado como riesgo de seguridad: el agente encuentra seis de siete vulnerabilidades pero reporta con confianza que el sistema es seguro.

La convergencia importa más que cualquier artículo individual

Un artículo sobre fiabilidad de agentes es interesante. Cinco artículos en una semana de equipos no relacionados es una señal. La comunidad investigadora está llegando independientemente a la misma conclusión que los profesionales han estado descubriendo a través de fallos en producción.

Construí el sistema de calidad Jiro a partir de mayo de 2025. El sistema impone un bucle de calidad de 7 pasos, una puerta de evidencia de 6 criterios y 7 modos de fallo nombrados que se mapean directamente a los patrones que estos artículos describen:

La línea temporal importa. Nueve meses de depuración por ensayo y error en producción, construyendo puertas de calidad un fallo a la vez, resultaron en una arquitectura que cinco artículos de investigación están ahora formalizando de forma independiente. Los problemas estructurales son reales. Las soluciones ad-hoc funcionan. La investigación está alcanzando a la práctica con marcos, taxonomías y benchmarks que hacen las soluciones reproducibles.

Las tres leyes de la deuda cognitiva

El marco de Storey cristaliza lo que he observado a lo largo de 11 meses de desarrollo con agentes autónomos. Tres patrones se mantienen independientemente del modelo, las herramientas o el dominio:

1. La deuda cognitiva se acumula con la velocidad. Mi agente promedia 140-200 líneas de cambios significativos de código por minuto durante una sesión de refactorización (medido desde git diffs, excluyendo espacios en blanco). Un desarrollador humano enfocado produce aproximadamente 20-40 líneas por minuto durante la codificación activa.⁸ El bucle Ralph que ejecuta Claude a $10/hora no produce 5 veces la deuda cognitiva de un desarrollador humano. Produce mucho más, porque la velocidad de escritura del desarrollador humano está acoplada a su velocidad de pensamiento. La velocidad de salida del agente no tiene acoplamiento con su velocidad de comprensión. La salida se duplica; la comprensión permanece constante; la deuda se acumula.

2. Pasar las pruebas no retira la deuda cognitiva. Cada artículo en el grupo de esta semana trata el paso de pruebas como una señal necesaria pero insuficiente. Los fallos de Tipo B de Deng et al. pasan todas las verificaciones automatizadas. La taxonomía de comportamientos erróneos de Wink incluye agentes que producen código funcional que no coincide con la intención. Mi puerta de evidencia requiere seis criterios más allá de “las pruebas pasan,” y el criterio más difícil de verificar sigue siendo “¿el desarrollador comprende lo que cambió?”⁶

Aquí hay un ejemplo concreto. Mi agente refactorizó una consulta de base de datos para usar un CTE (Common Table Expression) en lugar de una subconsulta. Ambos enfoques devolvían resultados idénticos. Las pruebas pasaron. La versión con CTE se ejecutaba 3 veces más lento en nuestro conjunto de datos porque el planificador de consultas no podía empujar los predicados dentro del CTE. Lo detecté durante una verificación rutinaria de EXPLAIN ANALYZE dos semanas después. Las pruebas del agente verificaron la corrección. Nada en el conjunto de pruebas verificaba las características de rendimiento. La deuda cognitiva no era “código malo.” La deuda cognitiva era “no sabía que el plan de ejecución había cambiado.”

3. La deuda cognitiva es invisible hasta que deja de serlo. La deuda técnica se anuncia a través de compilaciones lentas, pruebas inestables y conflictos de merge. La deuda cognitiva es silenciosa hasta que alguien pregunta “¿por qué el servicio de pagos usa polling de intervalo fijo?” y nadie lo sabe. La contribución de Storey es darle un nombre al problema invisible.

Cinco señales de advertencia de que está acumulando deuda cognitiva

Antes de poder solucionar el problema, necesita verlo. Estas cinco señales aparecen antes de los incidentes en producción:

1. No puede explicar el último PR del agente sin releerlo. Abra el PR más reciente que su agente creó. Sin mirar el diff, describa qué cambió y por qué. Si no puede, fusionó código que no comprende. Yo registro esto agregando una “verificación de resumen” de una línea a mi proceso de revisión: antes de aprobar, escribo una explicación de una oración en el comentario del PR. Si no puedo escribir la oración, no he revisado lo suficiente.

2. Su git log --stat muestra sesiones con más de 20 archivos modificados. Ejecute esto ahora mismo:

git log --stat --since="1 week ago" --author="$(git config user.name)" | \
  awk '/files? changed/ {files+=$1} END {print files, "files changed this week"}'

Compare el número con cuántos de esos archivos podría describir de memoria. La brecha es su backlog de deuda cognitiva.

3. Revisa los diffs desplazándose, no leyendo. Desplazarse es reconocimiento de patrones: “eso se ve bien.” Leer es comprender: “esto cambia el intervalo de reintento de exponencial a fijo, lo que significa que el servicio downstream verá un patrón de tráfico diferente.” Si su revisión toma menos de un minuto por cada 100 líneas de diff, está desplazándose.

4. Sus mensajes de commit describen QUÉ, no POR QUÉ. “Refactor: standardize retry patterns” describe lo que el agente hizo. “Fix: exponential backoff caused thundering herd after service restart” describe por qué. Si los mensajes de commit de su agente se leen como el primer ejemplo y no los reescribe, nadie (incluido su yo futuro) sabrá el razonamiento detrás del cambio.

5. Se siente productivo pero no puede enumerar lo que cambió. Al final de un día usando un agente, escriba los tres cambios de código más significativos de memoria. Si le cuesta, el agente fue productivo. Usted no. La deuda se acumuló mientras se sentía eficiente.

Comience aquí: El protocolo de tres archivos

No necesita 95 hooks, 7 modos de fallo nombrados ni un sistema de deliberación multi-agente para comenzar a gestionar la deuda cognitiva. Comience con una regla y construya a partir de ahí.

La regla: Después de cada sesión con el agente, lea completamente tres archivos. No echar un vistazo. No desplazarse. Leer cada línea de los tres archivos con los diffs más grandes.

¿Por qué tres? Porque tres archivos es alcanzable (realmente lo hará) y diagnóstico (descubrirá si los cambios del agente coinciden con su modelo mental). Si coinciden, su deuda es manejable. Si no, tiene un indicador adelantado de que el resto de los cambios de la sesión también divergen de su comprensión.

Implementación

Después de que su agente termine, ejecute:

# Show the 3 files with the largest diffs from the last commit
git diff HEAD~1 --stat | sort -t'|' -k2 -rn | head -3

Luego lea esos tres archivos. No el diff. El archivo completo. El contexto importa: el diff muestra lo que cambió, pero el archivo muestra lo que el cambio significa en contexto.

Ruta de mejora

Una vez que el protocolo de tres archivos sea un hábito (aproximadamente una semana), agregue una capa a la vez:

Cada capa retira una categoría específica de deuda cognitiva. La lectura de tres archivos detecta brechas de comprensión. El resumen del PR detecta desalineación de intención. La verificación de consultas detecta el incidente del CTE que describí anteriormente. La reescritura de commits preserva el razonamiento que de otro modo se evaporaría. Los modos de fallo nombrados previenen errores repetidos.

Lo que la investigación propone (y lo que realmente funciona)

Los cinco artículos apuntan hacia cuatro intervenciones estructurales. Las cuatro existen en alguna forma en mi conjunto de herramientas de Claude Code, construidas antes de que los artículos fueran publicados, validadas por los mismos patrones que los artículos describen.

Verificación independiente. Wink monitorea el comportamiento del agente contra la intención declarada. Mi bucle de calidad requiere releer cada línea escrita, prohibiendo explícitamente el modo de fallo de Verificación Fantasma (afirmar que las pruebas pasan sin ejecutarlas en la sesión actual).⁷ La solución es estructural: la verificación debe ser realizada por un proceso diferente al que produjo el resultado.

En la práctica, impongo esto con un hook post-sesión que ejecuta el conjunto de pruebas de forma independiente en lugar de confiar en el reporte del agente:

# Post-session verification hook (simplified)
# Agent says "tests pass" — verify independently
cd "$PROJECT_DIR"
test_output=$(python -m pytest --tb=short -q 2>&1)
exit_code=$?

if [ $exit_code -ne 0 ]; then
  echo "AGENT CLAIMED TESTS PASS. INDEPENDENT RUN FAILED:"
  echo "$test_output"
  exit 1
fi

El agente reportó “todas las pruebas pasan” y lo decía en serio. La ejecución independiente detecta diferencias de entorno, fixtures faltantes y pruebas que pasan por efectos secundarios en lugar de corrección. En 11 meses de ejecutar este hook, ha detectado 23 falsos positivos de auto-reportes del agente.⁹

Límites transaccionales. Atomix envuelve las llamadas a herramientas en transacciones con reversión. Mi sistema de deliberación bloquea las acciones irreversibles detrás del consenso de múltiples agentes independientes. Ambos enfoques agregan fricción a la ejecución del agente en los puntos donde los errores son más costosos. La versión práctica para la mayoría de los equipos: exigir un paso de aprobación manual antes de cualquier migración de base de datos, despliegue o llamada a API externa iniciada por el agente.

Taxonomías de comportamiento. Los tres modos de fallo de Wink (desviación, bucles, uso incorrecto de herramientas) y mis siete modos de fallo nombrados (Espiral de atajos, Espejismo de confianza, Meseta de lo suficientemente bueno, Visión de túnel, Verificación fantasma, Deuda diferida, Reporte vacío) cumplen el mismo propósito: hacen visibles las fallas invisibles al darles nombres.⁷ Un desarrollador que puede decir “el agente está exhibiendo Visión de túnel” puede intervenir antes de que la deuda se acumule. Comience con tres nombres para los tres errores de agente más comunes de su equipo. Los nombres importan más que la taxonomía.

Compromiso selectivo. La distinción Tipo A/Tipo B de Deng et al. y el módulo de confianza en mi sistema de deliberación codifican la misma idea: no todo resultado del agente merece el mismo nivel de escrutinio. Una heurística útil:

La pregunta que nadie respondió todavía

Los cinco artículos describen el problema. Wink, Atomix y OpaqueToolsBench proponen soluciones parciales. Ninguno responde la pregunta que más importa: ¿cómo se mide la deuda cognitiva?

La deuda técnica tiene indicadores aproximados: complejidad ciclomática, cobertura de pruebas, antigüedad de dependencias. La deuda cognitiva no tiene una métrica equivalente. Mi puerta de evidencia pregunta “¿el desarrollador comprende lo que cambió?” pero impone la respuesta a través de auto-reporte, que es exactamente el método de verificación que el modo de fallo Espejismo de confianza explota.

Una métrica útil rastrearía la diferencia entre lo que el agente cambió y lo que el desarrollador puede explicar. El conteo de archivos es un indicador aproximado. La complejidad del diff (no el conteo de líneas, sino la densidad de cambio semántico) es mejor. La métrica ideal se correlacionaría con la probabilidad de un incidente en producción causado por una incomprensión del código generado por el agente. Nadie ha construido esa métrica todavía. La calculadora interactiva de arriba aproxima el ratio, pero un ratio no es un umbral. Aún no sabemos dónde cae la línea entre “deuda manejable” e “incidente en espera.”

Hasta que alguien construya esa métrica, la respuesta práctica es la misma que existía antes de los agentes de IA: leer el código. La velocidad del agente hace impráctico leer cada línea. El protocolo de tres archivos, las taxonomías de comportamiento y los límites transaccionales reducen el volumen de código que requiere atención humana. La deuda cognitiva que permanece después de esos filtros es la deuda que importa.

Puntos clave

• Cinco grupos de investigación independientes convergieron en el mismo problema en una semana. Cuando equipos no relacionados llegan a la misma conclusión simultáneamente, el problema subyacente es estructural, no teórico.
• La deuda cognitiva es el cuello de botella, no la calidad del código. Los agentes producen código correcto más rápido de lo que los desarrolladores pueden comprenderlo. Las pruebas, los linters y las puertas de calidad reducen el problema pero no pueden eliminarlo.
• Comience con el protocolo de tres archivos. Después de cada sesión con el agente, lea completamente los tres archivos con los diffs más grandes. Agregue capas adicionales (resúmenes de PR, verificaciones de consultas, reescrituras de commits, modos de fallo nombrados) una por semana.
• Nombre los modos de fallo. La taxonomía de Wink y los modos de fallo nombrados de Jiro cumplen el mismo propósito: hacer visibles los problemas invisibles. Si su sistema de agentes no tiene nombres para sus patrones de fallo, no puede detectarlos.
• Agregue fricción en los límites irreversibles. Las llamadas transaccionales a herramientas (Atomix) y el consenso multi-agente (deliberación) agregan costo en los puntos donde los errores son más costosos. El costo lo vale.

Preguntas frecuentes

Referencias