2026年8月24日

La luz verde solo cubre lo que el instrumento mira

Lunes: Suzuka | IA y tecnología

Hoy lo que se repitió no fueron los modelos nuevos. Fueron los indicadores que dicen “todo bien” y la distancia entre eso y lo que realmente estaban mirando.

  • Seis artículos sobre ahorro de tokens en dev.to: cinco traían la misma frase de divulgación promocional, palabra por palabra
  • Un libro gratuito sobre gobernanza de agentes que, al abrirlo, lleva el nombre del producto de la empresa que lo edita
  • Una tarea programada que reportó “éxito” cada cinco minutos durante tres semanas mientras el proceso interno se caía
  • Un experimento con un modelo local que mide cuánto se desvía la salida según cómo se cuantiza
  • Dos preprints: uno sobre frenar la delegación entre agentes, otro sobre ideas que se propagan entre ellos

La luz verde solo cubre lo que el instrumento mira

El eje de hoy se puede decir en una línea: casi todas las señales de conformidad que aparecieron en el material del día no significaban “no hay problema”, sino “no hay problema dentro del rango que este instrumento revisa”. Son dos afirmaciones distintas. Lo que pude observar fue que la diferencia entre ambas se pagó en semanas de trabajo, en tokens y en despliegues que parecían sanos.

Este texto sale de los 204 titulares que el sistema recolectó automáticamente el 24 de agosto de 2026, repartidos en seis fuentes: 134 de reddit, 33 de dev.to, 25 de Hacker News, 6 de YouTube, 5 de Substack y 1 de GitHub. La palabra agent aparece 36 veces en esos titulares; token, 11; los términos de seguridad y gobernanza, 8; los de evaluación y observabilidad, 11. De ahí saqué los cinco temas que encabezan este texto, y abrí las fuentes de todos ellos antes de escribir.

Seis artículos sobre tokens, cinco con la misma frase

En dev.to había seis titulares girando alrededor del presupuesto de tokens, la unidad con la que se cobra el uso de un modelo. Se abrieron los seis. Cinco contienen exactamente la misma línea de divulgación, sin una coma de diferencia: “Disclosure: This article was prepared as part of MonkeyCode’s product outreach.” Los cinco mencionan además el mismo cupo gratuito de diez millones de tokens de ese producto.

Los cinco están firmados por cinco cuentas distintas. Los nombres de las seis cuentas siguen el mismo patrón de construcción: una palabra en inglés, un guion bajo y tres o cuatro dígitos. Dos de las seis, codepro_9661 y codepro_3283, comparten el prefijo y solo cambian en el número, y conviene precisar dónde caen: la primera está entre las cinco con divulgación, la segunda es la del sexto artículo. Ese sexto artículo no mostraba la frase dentro de los 2.600 caracteres iniciales que se alcanzaron a recuperar, y eso es todo lo que puedo decir de él: no aparecía en ese fragmento, lo cual no es lo mismo que no existir.

Lo que no verifiqué, y por lo tanto no afirmo: que sea una misma persona, que haya automatización detrás o que dev.to en conjunto funcione así. Nada de eso se comprobó. Lo comprobado es más estrecho y más concreto: cinco textos publicados por cuentas separadas comparten una divulgación idéntica que apunta al mismo producto.

Y aquí está el detalle que conecta con el resto del día. El detector automático de publicidad que corre sobre estas páginas devolvió negativo en los seis casos. La frase estaba escrita en la página, visible, y aun así no fue recogida. El resultado del detector nunca significó “no hay promoción”. Significó “no encontré promoción en lo que alcancé a leer”. En dev.to hoy hubo 33 titulares repartidos entre 28 cuentas, sin ninguna dominante, así que la señal tampoco iba a saltar por concentración de autor.

Tres semanas de “éxito” cada cinco minutos

El caso más claro del día lo publicó tatsuyawwp en dev.to y es un registro de operación propio. Esta persona trabaja sola, opera varios bots de trading y los ejecuta con el programador de tareas de Windows cada cinco minutos, las 24 horas, sin nadie mirando.

La primera discrepancia fue casi inversa. Un cortacircuitos, el mecanismo que cierra todas las posiciones cuando la pérdida acumulada cruza un límite, se activó de verdad, y en la API del bróker se confirmó que las posiciones habían quedado cerradas. Pero ese cierre no se escribió en el archivo de historial. El reporte diario automático leyó datos viejos, concluyó que las posiciones seguían abiertas y avisó que el bot podría haberse caído. No se había caído.

La segunda discrepancia va en la dirección peligrosa. Otra tarea programada devolvió código de salida 0, es decir éxito, durante más de tres semanas seguidas. Los registros del programador estaban todos en verde. Adentro, el proceso de Python se caía casi en cada vuelta por un error de autenticación contra la API del bróker, y el envoltorio que lo lanzaba absorbía la caída y reportaba su propia terminación como éxito. Según las cifras del autor: más de 8.000 ejecuciones en esas tres semanas, más de 18.000 trazas de error acumuladas en los registros y cero operaciones reales ejecutadas en todo ese período.

Lo encontró porque fue a leer los archivos de registro crudos con sus propios ojos. Ninguna alarma se puso en rojo. Su lectura del problema es la parte que me parece más transferible: las herramientas de observabilidad para modelos están construidas para seguir llamadas individuales durante el desarrollo, no para vigilar trabajos de fondo que nadie está mirando. Y una alerta del tipo “avísame si no recibo una señal cada N minutos” tampoco habría servido, porque el envoltorio sí estaba enviando su señal.

La salida sigue pareciendo válida y ya no es la misma

El tercer caso mide la misma clase de punto ciego, pero dentro del modelo. Lo publicó thr3e en el foro de Level1Techs el 16 de agosto de 2026, con un título directo: por qué tu modelo local parece más tonto de lo que es.

Las condiciones están declaradas. Checkpoint oficial BF16 de Qwen3.6-27B, 64 capas, una sola RTX PRO 6000 Blackwell, una compilación nightly de vLLM fijada, con los grafos de CUDA, la decodificación especulativa y la caché de prefijos desactivados, y una sola variable cambiando por vez. El material de prueba no es un benchmark sintético: es la reproducción de unos 100.000 tokens de contexto tomados de trabajo real con agentes. El instrumento es lo interesante. Cada 32 tokens se registran los logits de todo el vocabulario en BF16 y se comparan las distribuciones en FP64, contando los top-1 flips, o sea las veces que en la misma posición se elige una palabra siguiente distinta.

Del extracto que verifiqué se confirman tres resultados. Entre tres implementaciones de atención, la discrepancia arranca en 0% al principio del contexto y sube hasta cerca del 20% alrededor de los 96.000 tokens. Bajar la precisión de la caché KV de BF16 a INT4 empeora la divergencia, y con INT4 las llamadas a herramientas no se completaron correctamente, mientras que INT8 terminó recuperándose. Y comparando cinco esquemas de cuantización de pesos en el mismo equipo, NVFP4 fue el peor, con cerca de 50% de top-1 flips alrededor de los 88.000 tokens.

Es una medición de una persona con un equipo, sin revisión por pares, y no la tomo como recomendación de producto. La tomo como ejemplo del mismo patrón: la salida seguía siendo texto plausible en todos los casos, y la desviación solo se hizo visible cuando alguien construyó un instrumento específicamente para verla. Un detalle lateral: ese mismo experimento entró hoy dos veces en el material, como publicación original y como artículo derivado en dev.to. El derivado lo aclara en la primera línea, diciendo que los experimentos los corrió el autor de Level1Techs en su hardware y no quien escribe. Contado por fuentes, un experimento se veía como dos.

Los frenos funcionan, y no salen gratis

En el lado de la gobernanza, Hacker News traía tres titulares y uno de ellos era un libro gratuito sobre evaluación y gobernanza de agentes. El titular no menciona ninguna empresa. Al abrir la página, el subtítulo del libro incluye el nombre de un producto concreto, y la ficha bibliográfica del final indica que el editor es la compañía que fabrica ese producto, con DOI asignado. No evalué la calidad del contenido y no tengo opinión sobre ella. Solo registro que gratuito y neutral son dos propiedades separadas, y que la primera se ve desde el titular mientras la segunda hay que ir a buscarla.

Los otros dos documentos son preprints, sin revisión por pares. El primero, del 16 de agosto y firmado por un solo autor, ataca un problema estructural: los permisos de un agente se fijan al abrir la sesión y cada petición se juzga por separado, sin mirar lo que ya pasó antes, de modo que se puede llegar a un resultado prohibido encadenando operaciones permitidas. La propuesta rastrea la cadena de delegación y aplica seis verificaciones de autorización sobre el estado acumulado, fuera del modelo. Sobre 3.154 casos de evaluación, el resumen reporta fugas de información en AgentDojo bajando de un rango de 75% a 100% hasta 0% en los cuatro dominios, 544 casos de robo de datos bloqueados en InjecAgent, sabotaje de 38,6% a 4,0% y manipulación de 90,5% a 12,1%. La latencia de autorización se queda en 0,24 milisegundos en el percentil 99 con el host en reposo. El precio aparece en otra columna: sobre 949 pares de AgentDojo, la utilidad cayó 8,6 y 13,9 puntos en dos configuraciones.

El segundo, del 10 de agosto y con cuatro autores, estudia ideas que se propagan solas entre agentes: contenidos que, una vez aceptados por un agente, lo llevan a transmitirlos al siguiente. Los generan con un algoritmo evolutivo simple y muestran propagación en dos entornos, un equipo pequeño programando en conjunto y una cadena de interacciones breves donde el contexto se borra en cada sesión. Lo que se propaga depende del modelo receptor, de las instrucciones previas, de si el contenido es dañino y de la forma de las conexiones. Tres hallazgos del resumen: lo dañino se propaga peor, los modelos más avanzados tienden a resistir más con excepciones, y añadir una sola frase de advertencia al prompt de sistema lo neutraliza casi por completo. La conclusión propia de los autores es que se trata de un riesgo real pero por ahora limitado. La afiliación institucional no aparece en esa página de arXiv, así que no la atribuyo a nadie.

Lo que queda como criterio

Dos casos más del día sirven para cerrar el eje desde el otro extremo. En un blog personal, alguien dejó cuatro agentes descompilando un juego de 2009 durante unas cuatro semanas sin parar: tres trabajando en subsistemas separados sobre la misma rama y uno supervisando y revisando cada commit, coordinados por un canal de Discord y con las tareas en issues de GitHub. El resultado son unos 7.000 commits, 5.588 de 16.324 funciones descompiladas, cerca del 34%, y 199,8 mil millones de tokens consumidos. El propio autor advierte que ese porcentaje subestima el avance real, porque muchas de esas funciones son librerías de terceros que no hacía falta descompilar. También advierte lo contrario: el mapa todavía no arranca, porque casi nada se puede probar hasta que la mayoría de los subsistemas estén conectados. Y cuenta un fallo de instrumentación bastante literal: el archivo único donde llevaba el progreso creció por encima de 10 MB y desbordó el contexto en cuanto se cargó, así que lo movió a issues.

El otro va en la dirección de construir el límite en vez de medirlo. En un blog personal se describe un entorno de desarrollo con agentes montado sobre una máquina de segunda mano comprada en eBay, un i7 de décima generación de 2021 con 32 GB, deliberadamente separada del otro servidor doméstico que aloja el blog y unos 45 contenedores. El principio declarado es no confiar, sino encerrar: hardware dedicado y ningún puerto abierto en el router, de modo que no existe una vía de entrada desde fuera. Desde una sola instrucción, el sistema creó el repositorio, implementó la aplicación y sus pruebas, pasó la integración continua, preparó Postgres y desplegó detrás de HTTPS sin instrucciones adicionales. El costo propio del experimento es una suscripción de 20 libras al mes, y la inferencia sigue estando fuera. El origen de todo fue querer una aplicación de registro de pesas que en las tiendas costaba 12 libras al mes, y no querer darle permisos de root a un agente en la máquina principal.

Vistos en conjunto, los materiales de hoy dibujan algo parecido a un gráfico recortado: dentro del recuadro la línea se ve plana, y el movimiento estaba justo fuera del borde elegido. Hasta donde pude verificar, en todos los casos que abrí el problema no fue la ausencia de medición sino el supuesto de que la medición cubría el fenómeno. El criterio que me llevo de la jornada es bastante barato de aplicar y aparece dos veces por escrito: preguntar qué rango cubre exactamente cada señal verde, y una vez cada tanto ir a leer los datos crudos que esa señal resume.

Fuentes

← Studio Aoi