Solo en momentos así se ponen de acuerdo.
Tanto OpenAI, que lleva “Open” hasta en el nombre y aun así actúa con un descaro evidente,
como Anthropic, que salió corriendo diciendo que OpenAI había cambiado,
¿están haciendo esto por dinero o porque ven a la IA como una disputa por la hegemonía y el gobierno interviene para manipular a la directiva a su antojo?
Creo que el punto más difícil es el 3 (separar responsabilidades entre agentes). Hace tiempo revisé algunos traces de benchmarks públicos y comparto un patrón que vi ahí.
Lo más común no eran las "decisiones incorrectas", sino que la misma tarea se ejecutara dos veces. Que se repitiera el envío de un correo con los mismos parámetros, o que se volviera a escribir el mismo archivo. Salía mucho, sobre todo, en la parte de reintentos después de un timeout. Básicamente, como la primera llamada solo iba lenta, se asumía que había fallado y se volvía a invocar.
Lo complicado de rastrear esto es que no genera error. Las dos veces devuelve 200 y los logs se ven limpios, así que después, viendo solo los logs, no se nota.
La forma en que lo hacemos nosotros es agrupar por (herramienta, argumentos normalizados, hash de salida) y contar mecánicamente si se repite la misma combinación. Como no depende del juicio del LLM sino solo de cálculo, también es reproducible. Pero la limitación es clara: solo sabes hasta "se llamó dos veces"; con el trace solo no puedes confirmar si "realmente se ejecutó dos veces". En herramientas que devuelven un entity ID en la respuesta (como una API de creación de documentos), sí se puede verificar comparando el ID, pero en herramientas como correo electrónico, que solo devuelven "envío exitoso", no encontramos forma.
También coincido con lo que comentaste en el punto 2 sobre "dejarlo pasar por velocidad". Nosotros también evaluamos bloquearlo en tiempo real, pero antes de ejecutar no puedes ver el resultado, así que hay que decidir solo con los argumentos y la precisión era baja. Terminamos descartándolo porque a veces bloqueaba incluso reintentos válidos.
Corregir bugs también se volvió muy barato, y el costo de actualizar software tiende a cero; además, si no es algo del nivel del sector financiero, muchas veces basta con arreglar el bug y listo...
Pero si esta percepción se acumula, al final seguramente terminará ocurriendo un accidente grande.
Si lo prueban y ven alguna conversación donde Jumpback dé vueltas en falso o algo que les haga pensar "esto es un poco incómodo", no duden en dejar un comentario. Como la estructura de las conversaciones cambia según el sitio, los casos de uso reales son los que más ayudan. Después estoy viendo soporte para Perplexity y exportación a Notion/Obsidian, pero si hay algo más urgente, pienso hacer eso primero jaja
Gracias. Pruébenlo y, si hay alguna conversación en la que Jump Back no se detecte, no duden en avisarme~
Yo también lo he estado usando, pero creo que estaría bueno poder escuchar también los inconvenientes reales de otros usuarios jaja
También parece posible observar el log de diff cada vez que un agente hace una modificación y, si provoca cirugía de escopeta o una gran cantidad de cambios, considerarlo un mal olor desde la ingeniería de software y usarlo para aprendizaje por refuerzo...
[Para que sea más fácil de leer, les dejé una traducción al coreano del README.]
Clew
Un detector determinista que encuentra trabajo desperdiciado en trazas de agentes.
Clew lee trazas completas de ejecución de agentes de IA y encuentra pasos que repiten trabajo ya hecho: volver a llamar la misma herramienta con los mismos argumentos, reintentar una llamada fallida con los mismos argumentos, o volver a consultar información que ya está en el contexto. Como funciona sin evaluación de LLM, si le das la misma traza siempre devuelve el mismo resultado.
estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
Por qué importa esto
En las sesiones de agentes de codificación con IA, el desperdicio solo se hace visible en la factura. Como todas las llamadas a herramientas devuelven 200 y nada da error, el desperdicio no se ve a simple vista. Pero dentro de la traza, el agente vuelve a leer el mismo archivo dos veces, reintenta llamadas fallidas con los mismos argumentos y vuelve a invocar la misma herramienta con el mismo payload.
Como las operaciones de lectura (read) representan entre 65% y 90% de los tokens en una sesión de agente de codificación, este tipo de desperdicio se acumula sin llamar la atención. Las herramientas de observabilidad muestran la traza, pero no te dicen qué pasos fueron redundantes.
Qué detecta
Clew busca tres patrones de redundancia:
repeat — se repite la llamada a la misma herramienta/nodo
requery — se vuelve a llamar la misma herramienta con la misma entrada (misma salida)
pingpong — dos agentes intercambian esencialmente el mismo contenido (multiagente)
Cada hallazgo se clasifica en cuatro tipos:
error_repeat — la salida es un error y aun así se repite la misma llamada
side_effect — se vuelve a ejecutar una herramienta que cambia el estado (enviar/escribir/crear, etc.)
idempotent — se repite una herramienta de solo lectura/declarativa (sin efectos secundarios, pero consume tokens)
unclassified — herramientas fuera del mapeo. Como el efecto depende del payload, no se infiere solo por el nombre de la herramienta (Bash/PowerShell, etc.)
[Cómo funciona]
Es una cascada de 2 etapas:
compuerta estructural — agrupa llamadas a la misma herramienta con los mismos argumentos (normalizados)
compuerta de identidad — verifica si el sha256 de la salida coincide exactamente. Si no coincide, significa que el estado cambió, así que no se marca
Primero, una verificación estructural barata filtra candidatos, y la verificación semántica cara (embeddings + coseno) solo se ejecuta cuando hace falta. Como no hay evaluación de LLM, el resultado es determinista; eso importa si quieres meterlo en CI.
[Formatos de entrada]
Claude Code — analiza directamente el JSONL de la sesión
LangGraph — detecta redundancia de cadenas dentro de la traza
LangChain·CrewAI·AutoGen·LlamaIndex, etc. — parsea trazas instrumentadas en formato estándar OpenTelemetry/OpenInference (hay soporte de formato, y la validación empírica por framework sigue en curso)
trazas públicas de benchmark (Toolathlon, RedundancyBench)
Las sesiones de Cursor y Codex todavía no están soportadas; se están revisando sus formatos locales.
[Resultados de validación]
Benchmark público (Toolathlon, 6,780 trazas, 176,270 tool spans):
se detectaron 8,042 llamadas redundantes. De esas, 47% están en zona gris (operaciones idempotentes, declaración de completado); excluyéndolas, quedan 4,251 casos (2.41% de los tool spans). Aproximadamente 3 veces más que en sesiones de Claude Code (0.80%).
Se detectaron 1,343 ejecuciones redundantes de herramientas que modifican estado, incluyendo 459 envíos de correo repetidos con los mismos argumentos. Aun así, esto solo detecta que la misma herramienta fue llamada de forma redundante con los mismos argumentos; no se confirmó si realmente ocurrió un efecto secundario.
Benchmark etiquetado (RedundancyBench):
precision 0.826 (estimación de límite inferior para redundancia dentro de un archivo). Una parte importante de las etiquetas de RB corresponde a redundancia entre archivos (cross-file), fuera del alcance de un diseño de análisis por sesión. El recall es bajo, 0.157.
[Límites honestos]
Todavía no hay casos medidos de ahorro real. Se puede detectar y estimar, pero hay 0 casos con datos before/after donde un usuario haya corregido algo y la factura realmente haya bajado.
El 47% de lo marcado en el benchmark está en zona gris (re-ejecución idempotente). No se filtra; solo se clasifica, porque que una re-ejecución de solo lectura sea desperdicio depende de contexto que no se puede ver.
Como exige coincidencia exacta de sha256, no se marca nada si la salida cambia aunque sea un poco. Esa es la razón del recall bajo; es un diseño inclinado hacia la precisión.
Claude Code está inusualmente bien optimizado. Se midieron seis patrones de posible desperdicio en sesiones reales de CC, y cinco de ellos no estaban presentes allí. El desperdicio interesante apareció no en CC en sí, sino en entornos MCP con múltiples herramientas.
La estimación de costo (amplification) es una estimación, no una medición, y solo es posible en el formato de Claude Code.
Se descarta lo que no está validado
Se había creado un detector de relectura de archivos, pero en una muestra de 30 anotaciones humanas su precisión quedó muy por debajo del umbral preregistrado (70%): 3.3% siendo generosos, o 0% con criterio estricto, así que fue descartado. Tanto la predicción como el resultado quedaron registrados juntos en el documento de preregistro.
Actualización del autor. Publiqué un artículo aparte que resume la parte del servidor MCP que en el texto principal solo se mencionaba en una línea: es una estructura que resuelve el problema de que el agente asigne nombres de columnas a su antojo al escribir migraciones, cambiando el nombre físico de una “entrada” a un “cálculo” basado en un diccionario de palabras: https://sqemo.com/blog/erd-mcp-server
(Todavía es solo local por stdio, así que no admite MCP remoto; la app principal es privada y solo el servidor MCP está abierto).
Se puede probar de inmediato sin registrarse (app.sqemo.com), así que si encuentran algo que les moleste, dejen un comentario; como está en etapa inicial, el feedback se refleja enseguida.
Desde la primera publicación, seguí ampliando Repolis más allá de un simple navegador 3D de repos, hacia un pequeño pueblo al que dan ganas de volver.
El tráfico de GitHub y la información pública del repo se reflejan diariamente en los edificios y en la iluminación nocturna.
Añadí Starlight Row, con 8 habitantes y sus propias casas, además de rutinas de vida de día/noche y breves paseos e interacciones entre los residentes.
Con Explorer Passport, Village Chronicle y Town Gazette puedes seguir viendo el historial de visitas y los cambios en nuevos repos, releases, pushes y métricas.
Coloqué en la ciudad real de Repolis el World Tree procedural creado con el plugin de Copilot threejs-sculpt-dna.
La base sigue siendo una static app zero-build que no necesita backend ni claves, y solo las funciones de taxi/scholar con grounded AI son opcionales.
En lugar de crear una nueva publicación, también iré registrando los cambios posteriores en los comentarios de esta publicación original.
En el teclado coreano de Mac no se puede ingresar “yu” Claude parece usar mucho más esa marca al responder, pero para los usuarios de coreano no es algo familiar...
Soy el autor. Para complementar algunas cosas que no pude incluir en el texto —
· El video demo (flujo de aprobación en el teléfono, centro de comando de escritorio en 3 paneles) está en la landing con captura real: adhf.dev
· Para self-host, basta una sola línea: npm i -g adhdev; el dashboard aparece en localhost:3847 (no se requiere cuenta)
· También son bienvenidas preguntas de diseño, como por qué está planteado el merge ff-only o qué detecta realmente la validación cruzada de MAGI
Últimamente ya no se habla de deuda técnica, sino de deuda cognitiva.
A veces, al hablar con colegas, me da un poco de escalofrío ver que ni siquiera entienden bien cómo funciona algo que ellos mismos hicieron.
Con el tiempo, esto podría llevarnos a un punto en el que nadie entienda cómo funciona nada, aunque también pienso que tal vez no sea un problema porque siempre se le puede pedir a la IA que lo analice y preguntarle.
Solo en momentos así se ponen de acuerdo.
Tanto OpenAI, que lleva “Open” hasta en el nombre y aun así actúa con un descaro evidente,
como Anthropic, que salió corriendo diciendo que OpenAI había cambiado,
¿están haciendo esto por dinero o porque ven a la IA como una disputa por la hegemonía y el gobierno interviene para manipular a la directiva a su antojo?
puaj...
Vender educación es lo más rentable. No hay responsabilidad, solo cobro de costos. La IA se quedará con una gran parte de este negocio.
Creo que lo vi hace unos años.
Al entrar al sitio original, está explicado con imágenes, así que resulta fácil de entender de forma intuitiva.
Ayuda hacer más actividades fuera de línea, como salir a caminar o leer. Jaja
Creo que el punto más difícil es el 3 (separar responsabilidades entre agentes). Hace tiempo revisé algunos traces de benchmarks públicos y comparto un patrón que vi ahí.
Lo más común no eran las "decisiones incorrectas", sino que la misma tarea se ejecutara dos veces. Que se repitiera el envío de un correo con los mismos parámetros, o que se volviera a escribir el mismo archivo. Salía mucho, sobre todo, en la parte de reintentos después de un timeout. Básicamente, como la primera llamada solo iba lenta, se asumía que había fallado y se volvía a invocar.
Lo complicado de rastrear esto es que no genera error. Las dos veces devuelve 200 y los logs se ven limpios, así que después, viendo solo los logs, no se nota.
La forma en que lo hacemos nosotros es agrupar por (herramienta, argumentos normalizados, hash de salida) y contar mecánicamente si se repite la misma combinación. Como no depende del juicio del LLM sino solo de cálculo, también es reproducible. Pero la limitación es clara: solo sabes hasta "se llamó dos veces"; con el trace solo no puedes confirmar si "realmente se ejecutó dos veces". En herramientas que devuelven un entity ID en la respuesta (como una API de creación de documentos), sí se puede verificar comparando el ID, pero en herramientas como correo electrónico, que solo devuelven "envío exitoso", no encontramos forma.
También coincido con lo que comentaste en el punto 2 sobre "dejarlo pasar por velocidad". Nosotros también evaluamos bloquearlo en tiempo real, pero antes de ejecutar no puedes ver el resultado, así que hay que decidir solo con los argumentos y la precisión era baja. Terminamos descartándolo porque a veces bloqueaba incluso reintentos válidos.
Corregir bugs también se volvió muy barato, y el costo de actualizar software tiende a cero; además, si no es algo del nivel del sector financiero, muchas veces basta con arreglar el bug y listo...
Pero si esta percepción se acumula, al final seguramente terminará ocurriendo un accidente grande.
Si lo prueban y ven alguna conversación donde Jumpback dé vueltas en falso o algo que les haga pensar "esto es un poco incómodo", no duden en dejar un comentario. Como la estructura de las conversaciones cambia según el sitio, los casos de uso reales son los que más ayudan. Después estoy viendo soporte para Perplexity y exportación a Notion/Obsidian, pero si hay algo más urgente, pienso hacer eso primero jaja
Gracias. Pruébenlo y, si hay alguna conversación en la que Jump Back no se detecte, no duden en avisarme~
Yo también lo he estado usando, pero creo que estaría bueno poder escuchar también los inconvenientes reales de otros usuarios jaja
También parece posible observar el log de diff cada vez que un agente hace una modificación y, si provoca cirugía de escopeta o una gran cantidad de cambios, considerarlo un mal olor desde la ingeniería de software y usarlo para aprendizaje por refuerzo...
[Para que sea más fácil de leer, les dejé una traducción al coreano del README.]
Clew
Un detector determinista que encuentra trabajo desperdiciado en trazas de agentes.
Clew lee trazas completas de ejecución de agentes de IA y encuentra pasos que repiten trabajo ya hecho: volver a llamar la misma herramienta con los mismos argumentos, reintentar una llamada fallida con los mismos argumentos, o volver a consultar información que ya está en el contexto. Como funciona sin evaluación de LLM, si le das la misma traza siempre devuelve el mismo resultado.
pip install "clew-custos[detect]"python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.mdEjemplo de salida real ejecutado sobre una sesión pública de Claude Code:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsPor qué importa esto
En las sesiones de agentes de codificación con IA, el desperdicio solo se hace visible en la factura. Como todas las llamadas a herramientas devuelven 200 y nada da error, el desperdicio no se ve a simple vista. Pero dentro de la traza, el agente vuelve a leer el mismo archivo dos veces, reintenta llamadas fallidas con los mismos argumentos y vuelve a invocar la misma herramienta con el mismo payload.
Como las operaciones de lectura (
read) representan entre 65% y 90% de los tokens en una sesión de agente de codificación, este tipo de desperdicio se acumula sin llamar la atención. Las herramientas de observabilidad muestran la traza, pero no te dicen qué pasos fueron redundantes.Qué detecta
Clew busca tres patrones de redundancia:
repeat — se repite la llamada a la misma herramienta/nodo
requery — se vuelve a llamar la misma herramienta con la misma entrada (misma salida)
pingpong — dos agentes intercambian esencialmente el mismo contenido (multiagente)
Cada hallazgo se clasifica en cuatro tipos:
error_repeat — la salida es un error y aun así se repite la misma llamada
side_effect — se vuelve a ejecutar una herramienta que cambia el estado (enviar/escribir/crear, etc.)
idempotent — se repite una herramienta de solo lectura/declarativa (sin efectos secundarios, pero consume tokens)
unclassified — herramientas fuera del mapeo. Como el efecto depende del payload, no se infiere solo por el nombre de la herramienta (Bash/PowerShell, etc.)
[Cómo funciona]
Es una cascada de 2 etapas:
compuerta estructural — agrupa llamadas a la misma herramienta con los mismos argumentos (normalizados)
compuerta de identidad — verifica si el sha256 de la salida coincide exactamente. Si no coincide, significa que el estado cambió, así que no se marca
Primero, una verificación estructural barata filtra candidatos, y la verificación semántica cara (embeddings + coseno) solo se ejecuta cuando hace falta. Como no hay evaluación de LLM, el resultado es determinista; eso importa si quieres meterlo en CI.
[Formatos de entrada]
Claude Code — analiza directamente el JSONL de la sesión
LangGraph — detecta redundancia de cadenas dentro de la traza
LangChain·CrewAI·AutoGen·LlamaIndex, etc. — parsea trazas instrumentadas en formato estándar OpenTelemetry/OpenInference (hay soporte de formato, y la validación empírica por framework sigue en curso)
trazas públicas de benchmark (Toolathlon, RedundancyBench)
Las sesiones de Cursor y Codex todavía no están soportadas; se están revisando sus formatos locales.
[Resultados de validación]
Benchmark público (Toolathlon, 6,780 trazas, 176,270 tool spans):
se detectaron 8,042 llamadas redundantes. De esas, 47% están en zona gris (operaciones idempotentes, declaración de completado); excluyéndolas, quedan 4,251 casos (2.41% de los tool spans). Aproximadamente 3 veces más que en sesiones de Claude Code (0.80%).
Se detectaron 1,343 ejecuciones redundantes de herramientas que modifican estado, incluyendo 459 envíos de correo repetidos con los mismos argumentos. Aun así, esto solo detecta que la misma herramienta fue llamada de forma redundante con los mismos argumentos; no se confirmó si realmente ocurrió un efecto secundario.
Benchmark etiquetado (RedundancyBench):
precision 0.826 (estimación de límite inferior para redundancia dentro de un archivo). Una parte importante de las etiquetas de RB corresponde a redundancia entre archivos (
cross-file), fuera del alcance de un diseño de análisis por sesión. El recall es bajo, 0.157.[Límites honestos]
Todavía no hay casos medidos de ahorro real. Se puede detectar y estimar, pero hay 0 casos con datos before/after donde un usuario haya corregido algo y la factura realmente haya bajado.
El 47% de lo marcado en el benchmark está en zona gris (re-ejecución idempotente). No se filtra; solo se clasifica, porque que una re-ejecución de solo lectura sea desperdicio depende de contexto que no se puede ver.
Como exige coincidencia exacta de sha256, no se marca nada si la salida cambia aunque sea un poco. Esa es la razón del recall bajo; es un diseño inclinado hacia la precisión.
Claude Code está inusualmente bien optimizado. Se midieron seis patrones de posible desperdicio en sesiones reales de CC, y cinco de ellos no estaban presentes allí. El desperdicio interesante apareció no en CC en sí, sino en entornos MCP con múltiples herramientas.
La estimación de costo (
amplification) es una estimación, no una medición, y solo es posible en el formato de Claude Code.Se descarta lo que no está validado
Se había creado un detector de relectura de archivos, pero en una muestra de 30 anotaciones humanas su precisión quedó muy por debajo del umbral preregistrado (70%): 3.3% siendo generosos, o 0% con criterio estricto, así que fue descartado. Tanto la predicción como el resultado quedaron registrados juntos en el documento de preregistro.
Actualización del autor. Publiqué un artículo aparte que resume la parte del servidor MCP que en el texto principal solo se mencionaba en una línea: es una estructura que resuelve el problema de que el agente asigne nombres de columnas a su antojo al escribir migraciones, cambiando el nombre físico de una “entrada” a un “cálculo” basado en un diccionario de palabras:
https://sqemo.com/blog/erd-mcp-server
(Todavía es solo local por stdio, así que no admite MCP remoto; la app principal es privada y solo el servidor MCP está abierto).
Se puede probar de inmediato sin registrarse (app.sqemo.com), así que si encuentran algo que les moleste, dejen un comentario; como está en etapa inicial, el feedback se refleja enseguida.
Registro de actualizaciones (2026-07-25)
Desde la primera publicación, seguí ampliando Repolis más allá de un simple navegador 3D de repos, hacia un pequeño pueblo al que dan ganas de volver.
threejs-sculpt-dna.En lugar de crear una nueva publicación, también iré registrando los cambios posteriores en los comentarios de esta publicación original.
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis
En el teclado coreano de Mac no se puede ingresar “yu” Claude parece usar mucho más esa marca al responder, pero para los usuarios de coreano no es algo familiar...
A mí también me llegó el despliegue, así que lo probé... mmm, el coreano todavía no :(
Soy el autor. Para complementar algunas cosas que no pude incluir en el texto —
· El video demo (flujo de aprobación en el teléfono, centro de comando de escritorio en 3 paneles) está en la landing con captura real: adhf.dev
· Para self-host, basta una sola línea:
npm i -g adhdev; el dashboard aparece en localhost:3847 (no se requiere cuenta)· También son bienvenidas preguntas de diseño, como por qué está planteado el merge ff-only o qué detecta realmente la validación cruzada de MAGI
Si me dan feedback, lo reflejo de inmediato.
Yo esperaba
gpt6... ya salióopus5, ¿no debería salir un modelo nuevo?Últimamente ya no se habla de deuda técnica, sino de deuda cognitiva.
A veces, al hablar con colegas, me da un poco de escalofrío ver que ni siquiera entienden bien cómo funciona algo que ellos mismos hicieron.
Con el tiempo, esto podría llevarnos a un punto en el que nadie entienda cómo funciona nada, aunque también pienso que tal vez no sea un problema porque siempre se le puede pedir a la IA que lo analice y preguntarle.
Me encantan mucho este tipo de artículos.