AI Radar — 21 de octubre de 2026
tsrs (TypeScript en Rust, escrito por agentes), DeepSeek abre DeepInfer con sus numeros de margen, y Claude reduciendo la superficie de ataque de OpenSSH: 493 hallazgos en 25 proyectos.
AI Radar — 21 de octubre de 2026
Ventana: 20 oct 06:45 → 21 oct 06:45 (Europe/Madrid). 126 posts de 40 handles, más dos cuentas corregidas (@arena, @SST_dev). Contraste con fuente primaria en cada item. Duplicados con las ediciones del 15-20 oct filtrados.
🔥 Lo más importante
1. Cloudflare y VoidZero publican tsrs: el compilador de TypeScript portado a Rust, 8x más rápido y escrito casi entero por agentes (lanzamiento, 20 oct) [N5/I4/A5/R4]
Qué pasó: Cloudflare anunció el 20-oct que adopta tsrs, el port a Rust del compilador de TypeScript que empezó Max Schwenk (Owner.com), bajo el paraguas de oxc-project y con el equipo de TypeScript colaborando. Números del blog: hasta 8x más rápido y ~70% menos memoria que TypeScript 7.0 con el mismo número de workers; en el codebase de VS Code, 17,7x más rápido y 2,8x más eficiente en memoria que tsc 7 en una máquina de 64 vCPU (esa cifra es de otro benchmark, no del blog). El caso de origen: el monolito de Owner, ~37.000 ficheros TS, tardaba 19 GiB y 80 s en un chequeo single-threaded. Se instala hoy con npm install tsrs / npx tsrs, y existe build WASM (@tsrs/wasm) porque Rust compila a Wasm sin arrastrar un GC, cosa que el compilador en Go no hace limpio. Cloudflare es explícita: no están forkeando TypeScript, el equipo de TS mantiene el control del lenguaje, y parte de las optimizaciones de 7.1 beta (hasta 2,5x sobre 7.0) salieron de tsrs.
Por qué importa: el ángulo no es "otro port rápido", es quién lo escribió. Schwenk contó que pidió a Claude Opus 5.5 un port fiel del compilador en Go y que "no escribió código"; Theo Browne había construido su propio ts-rust con ~24.000 $ de tokens de Claude, lo desplegó por accidente en producción de T3 Code, aguantó 8 horas y ahora ambos proyectos se fusionan en un solo paquete con LSP. Cloudflare lo dice sin rodeos en el post: "los modelos frontera ya pueden hacer ports a gran escala casi de forma independiente en cuestión de días". El trabajo de un compilador —el artefacto de infraestructura más conservador del ecosistema JS— ha pasado a ser un problema de dirección de agentes y revisión, no de tecleo.
Consecuencias: npx tsrs -p . --noEmit como drop-in en CI es una prueba de 15 minutos con beneficio inmediato; pero es experimental (sin watch mode ni LSP todavía, --init/--showConfig no soportados, PRs cerrados por falta de banda), así que en CI sí, en el editor aún no. Y la lección de gestión: si dos personas con tokens pueden portar TypeScript en semanas, la pregunta para cualquier equipo es qué parte de su stack es "portable por agentes" y cuánto les cuesta no haberlo intentado.
Enlaces: https://blog.cloudflare.com/typescript-rust-port · https://github.com/oxc-project/tsrs · https://building.owner.com/tsrs · https://x.com/steipete/status/2112571535731106013 (20-10-2026)
2. DeepSeek libera DeepInfer (Apache 2.0): su stack de inferencia de producción, y con él los primeros números públicos de márgenes (lanzamiento, 20 oct) [N5/I5/A3/R5]
Qué pasó: DeepSeek publicó el 20-oct DeepInfer, el motor que sirve V4.1-Flash en producción, en Apache 2.0 (más deepseek-recipe, el encoder/decoder de tokens, en MIT). Soporta un solo modelo (V4.1-Flash) y dos chips: NVIDIA SM100 (Blackwell) y Huawei Ascend 950. Dentro: kernels propios (FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect), atención en data-parallel con MoE en EP64-EP128, DSpark (5 tokens de draft + una cabeza de confianza que decide qué verificar; ~30% menos tokens de draft comprobados, 4-7% más throughput) y una técnica que reejecuta solo los últimos 128 tokens del prompt por las capas del decoder y casi parte en dos el coste de prefill. Cifras de la casa: >25.000 tokens/s/GPU de salida con 256 requests por rank (EP64, contexto 131k) y 155 billones de tokens/día por clúster. Lo que no incluye, y es importante: sistema de KV cache, disaggregación prefill/decode y balanceo entre réplicas — es inferencia offline; para servir de verdad lo montas tú.
Por qué importa: dos cosas. (a) Es la primera vez que un laboratorio frontera publica el motor que usa en producción con números operativos, justo después de negarse a hacerlo en abril de 2025 por "ser un fork viejo de vLLM y no tener banda para mantenerlo". Eso abarata el suelo de coste de servir modelos abiertos para todo el mundo, no solo para DeepSeek. (b) Los números permiten hacer la cuenta que hizo swyx: a 38 $/GPU-hora de ingresos con precios off-peak y un coste estimado de 5-10 $/GPU-hora, el margen de servir sería del orden del 80%. Es su cálculo, no una cifra publicada por DeepSeek, pero encaja con el resto de la semana (M3.1 Flash a 0,15/0,60 $, Mercury 3 a 1.068 tok/s).
Consecuencias: si alguien te vende "inferencia privada barata", ahora tiene una referencia open source que competir; y el detalle de que swyx sacara el dato de Zhihu y no de X ("si solo lees Twitter, lees lo aprobado para guiris") es un recordatorio operativo: el alpha de los labs chinos vive en sus canales nativos.
Enlaces: https://github.com/deepseek-ai/DeepInfer · https://github.com/deepseek-ai/deepseek-recipe · https://x.com/deepseek_ai/status/2112476496283775135 · https://x.com/swyx/status/2112587397380943953 · Q&A de despliegue: https://github.com/deepseek-ai/DeepInfer/blob/main/doc/inference_deployment_qa.md (20-10-2026)
3. Anthropic usa Claude para reducir la superficie de ataque: 493 hallazgos en 25 proyectos y un quinto del código pre-auth de OpenSSH eliminado (investigación, 20 oct) [N4/I5/A5/R4] Qué pasó: Anthropic publicó el 20-oct los resultados de pasar Claude por 25 proyectos OSS (>5M líneas, C/C++/Java/PHP/Python): inventarió 17.000 opciones de configuración, de las que 3.842 afectaban a controles de seguridad, y encontró 493 problemas con tres métodos: código alcanzable en la configuración por defecto que no hace falta, código que corre antes de una compuerta dura (auth, entrada de la máquina de estados) y combinaciones de configuración que apagan un control en silencio. Los hallazgos que importan: los 11 proyectos "gated" tenían código alcanzable sin autenticar; 162 combinaciones de opciones aceptadas sin error ni documentación, de las que 94 desactivaban un control; un conflicto de dos flags que eliminaba por completo la exigencia de certificado de cliente llevaba 21 años en el código; y un patrón repetido en 4 proyectos donde una regla de denegación por hostname falla abierta si el reverse DNS está desactivado (una regla por hostname nunca puede casar con una IP). El caso estrella: OpenSSH, donde Claude encontró ~4.500 líneas de ML-DSA-44 (16% del código pre-auth) alcanzables sin autenticar aunque el algoritmo estuviera desactivado; el fix de 10.6 elimina ~un quinto del código pre-auth alcanzable. Por qué importa: esto es lo contrario de "encontrar bugs". Reducir alcanzabilidad baja la severidad de vulnerabilidades que aún no conoces, incluidas las que ya se están explotando; no necesitas encontrarlas para mitigarlas. Y el hecho de que sobreviva superficie innecesaria en OpenSSH —el C más auditado del mundo— dice que el método tiene recorrido en cualquier codebase. Consecuencias: Anthropic empaquetó el método en una skill (tres pasadas, cada una con contexto vacío más un resumen de la anterior, cada hallazgo confirmado con traza dinámica, y toda compuerta nueva debe dejar los tests del proyecto en verde) y la está integrando en OSS Scanner. Traducible a negocio: una auditoría de "superficie" acotada, con criterio de aceptación verificable, es mucho más vendible que otra ronda de pentesting. Enlaces: https://www.anthropic.com/research/attack-surface-reduction · https://x.com/thepunit/status/2112671584959750340 · notas de OpenSSH 10.6: https://www.openssh.org/releasenotes.html#10.6 (20-10-2026)
4. Vercel abre durable-harness: sesiones de Claude Code, Codex, OpenCode y Pi que sobreviven a un crash a mitad de turno (lanzamiento, 20 oct) [N5/I4/A4/R5]
Qué pasó: Vercel publicó el 20-oct durable-harness (Apache 2.0, vercel-labs/durable-harness, aún 0.0.x), un conjunto de adaptadores que meten Pi, OpenCode, fx, Claude Code y Codex dentro de un World del Workflow SDK. Cada turno escribe en un log durable: intención antes de cada llamada a modelo o tool y resultado después; el turno va respaldado por un mensaje en cola, así que si la función muere, otra lee el log y sigue. Las llamadas completadas no se repiten (no te cobran dos veces los tokens); las tools marcadas replay: 'safe' se reejecutan y las demás vuelven al modelo como "posiblemente ejecutadas" para que decida. Corre en Vercel, en local con ficheros, o en tu Postgres/Mongo/Redis/Turso cambiando dos variables. Claude Code y Codex solo corren en el sandbox de la propia sesión, nunca en una Function compartida.
Por qué importa: el "agente always-on" que se discutía la semana pasada necesitaba exactamente esto. La sesión deja de vivir en tu portátil y deja de ser un proceso que hay que mantener vivo: es un log que se puede reanudar en otra máquina. Y el detalle de facturación —no repetir llamadas de modelo ya completadas— es la diferencia entre "durable" y "reintentar el turno entero", que es lo que hacen casi todos los wrappers caseros.
Consecuencias: si tienes un agente que lanza PRs y espera CI, este es el patrón a copiar aunque no uses Vercel (el World es una interfaz: log + cola + stream). Aviso: API inestable entre releases e infra joven (1 star, creado el 16-oct).
Enlaces: https://vercel.com/blog/making-every-harness-durable · https://github.com/vercel-labs/durable-harness · docs: https://vercel.com/docs/agent-harnesses (20-10-2026)
5. Compromiso de 8 CAs intermedias de eMudhra: cualquier sitio era suplantable, y toca actualizar trust stores hoy (incidente, 20 oct) [N4/I5/A5/R3] Qué pasó: se publicó el 20-oct que las claves privadas de ocho CAs intermedias de eMudhra están comprometidas; encadenan a raíces confiadas por Mozilla, Microsoft, Apple y Chrome. El reporter (Wayne) lo demostró firmando un mensaje con la clave de cada una y lo reportó el 17-oct; Firefox y Chrome bloquearon los certificados ese mismo día, Apple el 19 y Microsoft el 20. Con una de esas claves se puede suplantar cualquier web o servicio. Parches ya disponibles: Go 1.27.3/1.26.10, Electron 44.9.1/43.8.1/42.11.16, Python certifi 2026.10.19, Rust webpki-roots 1.0.10, Homebrew ca-certificates 2026-09-25_1, NSS 3.131.1; Node.js y Composer siguen pendientes. Por qué importa: no es una historia de IA, pero es la clase de incidente que rompe agentes que hablan con APIs por HTTPS desde imágenes viejas, y la respuesta correcta esta semana es una actualización de trust store, no un parche de aplicación. Cualquier contenedor que construyas hoy con una base de la semana pasada puede seguir confiando en una CA comprometida. Consecuencias: reconstruye imágenes y actualiza runtimes; en Nix, un solo cambio arregla también las dependencias transitivas (ver tip 5). Y si tienes clientes con pinning o trust stores propios, avísales hoy: los que no consumen revocación solo se arreglan con actualización de software. Enlaces: https://emudhra.we-have-a-problem.com/ · contexto operativo: https://ghuntley.com/patch/ (20-10-2026)
🛠️ Herramientas
Hugging Face Agent Manager — un terminal en el navegador para todos tus coding agents, con Hermes soportado
Qué es: gestor de terminales cloud privado y de un solo usuario para Claude Code, Codex, Gemini CLI, opencode y Hermes, más shell y navegador de ficheros; cada agente vive en una carpeta de trabajo y en un PTY del backend, con una rejilla libghostty-vt como pantalla autoritativa.
Problema que resuelve: sesiones que mueren al cerrar el portátil y agentes repartidos en cinco terminales distintas sin ver el coste.
Diferencia: las sesiones viven en el backend (sobreviven a desconexiones y se pueden mirar desde varios dispositivos, con un solo controlador de input), hay una página Skills que distribuye SKILL.md a todos los agentes y una página Usage con tokens, coste y cuota de 5 h/semanal. Se despliega duplicando un Space privado y montando un bucket privado en /data.
Ejemplo: duplicar lvwerra/agent-manager-template como Space privado, crear el bucket y montarlo en /data, entrar y crear un agente eligiendo la carpeta del repo. Alternativa por script con duplicate_repo(..., space_volumes=[Volume(type="bucket", ...)]).
Enlace: https://github.com/huggingface/agent-manager · https://huggingface.co/spaces/lvwerra/agent-manager-template · https://x.com/lvwerra/status/2112556991482610014
Veredicto: probar — es la forma más barata que he visto de tener Hermes y Claude Code corriendo en un sitio al que puedes entrar desde el móvil; asume que es single-user y que el estado se checkpointa cada 15 s.
LangChain Managed Deep Agents 0.8 — credenciales del usuario y memoria por persona en un harness gestionado
Qué es: runtime gestionado para el harness open source Deep Agents; un proyecto es un directorio con agent.py, identity.py, memory.py, tools/, channels/, skills/, evals/ y schedules/, y se despliega con mda deploy.
Problema que resuelve: lo que hay que construir cuando un agente deja de ser tuyo y lo usan 200 personas: identidad (actuar en nombre de quién), memoria separada por usuario, canales, sandbox y evals.
Diferencia: la 0.8 añade credenciales propiedad del usuario, memoria a nivel de usuario en /memories/user/ (frente a /memories/agent/ compartida, sin copiar contenido entre capas), canales HTTP, transferencia de ficheros en Slack y búsqueda web de Parallel gratis durante la beta.
Ejemplo: uv tool install managed-deepagents, mda init research-assistant, mda dev (local en LangSmith Studio), mda deploy.
Enlace: https://langchain.com/blog/langsmith-managed-deep-agents-whats-new · https://x.com/hwchase17/status/2112644945697976630
Veredicto: seguir — beta, solo LangSmith Cloud en US y CLI-first; pero la separación memoria-agente / memoria-usuario y credenciales-por-persona es el diseño que copiaría en cualquier "company harness" propio.
Cline Desktop + plugins: /goal como hook de verificación
Qué es: app de escritorio de Cline (macOS, Windows, Linux) con sistema de plugins en TypeScript que aportan slash commands, tools propias, hooks de ciclo de vida (beforeTool, afterRun) y reglas dinámicas.
Problema que resuelve: agentes que declaran "hecho" sin comprobarlo; el plugin Goal añade /goal y un afterRun que empuja a Cline a verificar y solo le deja llamar a mark_goal_complete cuando lo ha hecho.
Diferencia: la verificación deja de ser una instrucción en el prompt y pasa a ser un hook del harness que no se puede saltar por olvido.
Ejemplo: cline plugin install https://github.com/cline/typescript-lsp-plugin.git para ver el patrón; en la app, Customize → Marketplace → Plugins → instalar Goal, y luego /goal ship the feature.
Enlace: https://docs.cline.bot/customization/plugins · https://x.com/cline/status/2112644617141371061
Veredicto: probar — es la implementación más limpia que he visto del "definition of done" como código; ojo, Desktop sigue en 0.0.x y ya ha roto plugins en un release (0.0.46 → arreglado en 0.0.48).
Perplexity Computer en local (Mac) — modelo, harness y ejecución en el dispositivo Qué es: Computer puede correr entero en un Mac con Apple silicon, incluido el modelo, con PPLX Pro (Qwen post-entrenado) o Qwen 3.6 como opciones locales, y trabajar sobre Notes, Mail, Messages, Numbers y ficheros locales. Problema que resuelve: tareas de agente sobre datos sensibles que hoy obligan a subirlos a la nube. Diferencia: el usuario elige por tarea entre totalmente local, Hybrid (razonamiento en la nube, datos privados en local) y nube; el orquestador local puede escalar a 15+ modelos frontera cuando hace falta información actual. Ejecución de código y tools en sandbox aislado en ambos modos. Ejemplo: app de Perplexity para Mac, descargar el modelo local y elegir "fully local"; recomiendan 36 GB de memoria unificada. Enlace: https://www.perplexity.ai/hub/blog/perplexity-computer-now-runs-fully-local-on-mac · https://x.com/perplexity_ai/status/2112571597798461920 Veredicto: seguir — requiere Mac potente y suscripción Pro/Max/Enterprise, pero marca la pauta: el agente personal con datos privados se está mudando al dispositivo.
💡 Tips aplicables hoy
1. Separa plan, ejecución y auditoría en tres modelos distintos (y usa worktrees, no subagentes)
Problema: un solo agente planificando y ejecutando se enamora de su plan; los subagentes comparten el mismo contexto y el mismo sesgo.
Técnica (steipete, 20-oct): Astra planifica, Sol 6.1 escribe el código lanzando codex cli en worktrees, y "un segundo agente supervisa para mantener a Astra en el camino". Su conclusión textual: "promptear Astra para correr codex en worktrees funciona MUCHO mejor que depender de subagentes". Lo convirtió en un plugin de OpenCode ("smart goal") donde el que revisa no es el mismo agente leyendo un fichero, sino otro que discute.
Implementación:
git worktree add ../wt-$TASK -b feat/$TASK
(cd ../wt-$TASK && codex exec "$(cat PLAN.md)") # ejecutor
(cd ../wt-$TASK && claude -p "audita el diff contra PLAN.md; lista lo que falta") # auditor
Enlace: https://x.com/steipete/status/2112605703219347503
2. Antes de cambiar de modelo, cambia el esfuerzo de razonamiento
Problema: se cambia de modelo (y de precio) para arreglar un problema de calidad que a veces es de presupuesto de test-time compute.
Técnica: los datos de Arena del 20-oct muestran que GPT-6 Luna y GPT-6.1 Sol ocupan 6 de los 11 puntos de la frontera de Pareto del Agent Arena solo variando reasoning effort: Luna domina por debajo de 0,10 $/tarea y Sol entre 0,22 y 0,65 $. La conclusión de Arena es la correcta: "a veces el mejor movimiento es cambiar el esfuerzo, no el modelo".
Implementación: en tu eval, para cada tarea corre el mismo modelo en low/medium/max y dibuja coste vs acierto; elige el punto por tipo de tarea, no un default global. Es la optimización más barata que existe (cero cambios de código, solo un parámetro).
Enlace: https://x.com/arena/status/2112600237491810662
3. Hazle a tu propio código la auditoría de superficie de tres pasadas Problema: los bugs que no encuentras se explotan por rutas que no sabías que estaban abiertas: config por defecto, código pre-auth y combinaciones de flags. Técnica (Anthropic, 20-oct): tres pasadas con contexto nuevo cada una —(1) código alcanzable en la config por defecto que no usa ninguna funcionalidad prevista, (2) código que corre antes de una compuerta dura o de la entrada de la máquina de estados, (3) pares de opciones que juntas apagan un control— y cada hallazgo confirmado con una traza dinámica, no con lectura. Para las compuertas propuestas: los tests del proyecto y una suite de regresión black-box deben dar resultados idénticos a la baseline; si cambiaría el comportamiento en una config no-default, lo decide un humano. Implementación: escribe la skill con esos tres prompts y el gate de tests; y busca a mano los dos patrones concretos del post: reglas de deny por hostname con reverse DNS desactivado (fallan abiertas porque un hostname nunca casa con una IP) y flags de certificado de cliente que se ignoran según el namespace de la opción. Enlace: https://www.anthropic.com/research/attack-surface-reduction
4. Calibra el judge con tráfico de producción, no con un dataset de juguete Problema: los evals offline no contienen los fallos que sí ocurren; y un LLM-as-judge sin calibrar marca lo que le parece. Técnica (Harrison Chase, 20-oct): el valor de un judge en producción está en qué pasa con lo que marca — calibrarlo contra labels humanos, quedarse con los scores bajos, confirmar cuáles son fallos reales, añadirlos al set de evals, arreglar y volver a correr. "Producción encuentra los fallos que tu dataset offline nunca tuvo". Implementación: muestrea 50 marcados y 50 no marcados por semana, etiqueta a mano, mide acuerdo; si el acuerdo baja del 80%, el problema es el rubric del judge, no el agente. Cada fallo confirmado entra como caso de test con su input original. Enlace: https://x.com/hwchase17/status/2112621016518377491
5. Parches temporales con fecha de caducidad, gestionados por el propio agente
Problema: los workarounds de seguridad (blacklists de CA, pins, overrides) se quedan años porque nadie recuerda quitarlos. La deuda técnica se paga en incidentes.
Técnica (Huntley, 20-oct, con el caso eMudhra de fondo): un solo prompt para saber si su flota Nix estaba afectada, un plan, el parche aplicado, y luego un recordatorio dentro de AGENTS.md que el agente relee: "en o después del 2026-10-22, comprueba si el canal trae el commit X; cuando lo traiga, revierte el workaround, borra estos ficheros e imports, verifica que los bundles ya no confían en las cuatro raíces, y elimina esta sección".
Implementación: entrada temporal en AGENTS.md con (a) fecha de reevaluación, (b) comando exacto de comprobación, (c) lista de ficheros a borrar, (d) criterio de verificación. El agente hace el check en su siguiente sesión y, si toca, revierte y limpia la nota.
Enlace: https://ghuntley.com/patch/ · https://x.com/GeoffreyHuntley/status/2112577998796783697
🧠 Qué hacen los mejores
- Peter Steinberger: dos migraciones grandes en dos semanas, y "la deuda técnica se mide en tokens". Movió el frontend de OpenClaw de Lit a Solid 2.0 en un loop de dos semanas: ~600 PRs, revisando la sesión cada dos días, "el proceso fue casi automático", con menos JS/CSS y actualizaciones más finas; y cambió OpenCode a tsrs en un fin de semana ("drop-in, ~5x más rápido"). Su frase del día: "la deuda técnica ahora se puede contar en tokens". Enlaces: https://x.com/steipete/status/2112597162924351909 · https://x.com/steipete/status/2112571535731106013
- Harrison Chase: el "company harness" tiene cinco primitivas, y casi nadie las tiene todas. De sus agentes internos en marketing, ventas e ingeniería: vive donde la gente ya trabaja (Slack), sabe quién pregunta y actúa en su nombre para unos servicios y con identidad propia para otros, tiene memoria global y por usuario, corre código en un sandbox donde los CLIs autenticados funcionan, y la mayoría de sus runs son programados, no invocados (agentes ambientales). Y su orden de construcción, repetido dos veces el mismo día: "empieza por el harness, no por un workflow de 20 pasos con if/else; añade contexto; luego middleware; y solo si hace falta, LangGraph". Enlaces: https://x.com/hwchase17/status/2112644945697976630 · https://x.com/hwchase17/status/2112489626061738209
- Geoffrey Huntley: zonas de seguridad para agentes y compilación fuera de la VM. Añadió a su infra un tablón de mensajes entre agentes con perfiles tipo clasificación (
oss,standard,customer, este último sin conectividad saliente), donde las entradas se borran cuando la máquina se apaga — coordinación sin memoria compartida. Y una regla de infraestructura que ahorra dinero: la compilación no debe ocurrir en la VM del agente; con Nix como imagen guest, se descarga a un build farm con caché. Enlaces: https://x.com/GeoffreyHuntley/status/2112639259496849830 · https://x.com/GeoffreyHuntley/status/2112642841092788489 - Zach Lloyd (Warp): "code review ya es mitigación de riesgo". Su tesis del 20-oct: el objetivo no es leer cada diff línea a línea, es reducir el riesgo de pulsar merge sin haberlo leído; la revisión cercana será cada vez menos necesaria y lo que se mide es la fábrica. Warp publica sus números: +40% de PRs mergeados y −67% de coste por PR en tres meses. Enlaces: https://x.com/zachlloydtweets/status/2112654624301654078 · https://x.com/warpdotdev/status/2112605226196750762
- swyx: el margen de inferencia, en Zhihu. Sacó de la página china de DeepSeek las cifras de producción (155 billones de tokens/día, 38 $/tarjeta-hora) y su lectura: "si solo lees Twitter, estás leyendo lo aprobado para guiris". Su conclusión, con la que el resto de la semana encaja: el beneficio real del frontier inference estaba ahí y no en las valoraciones. Enlace: https://x.com/swyx/status/2112587397380943953
- poteto (Grok Bot): 204 tickets en 10 minutos con una sola aprobación. Su caso operativo del 20-oct: el bot detecta incidentes en la cola de soporte y responde a todos los tickets asociados; en un incidente despachó 204 en ~10 minutos con un ingeniero aprobando el lote. Su resumen de 24 h como usuario incluye ~1.000 $ recuperados de una aerolínea y 66 listas de spam dadas de baja. Enlace: https://x.com/poteto/status/2112645531076096330
📈 Señales del futuro
1. Servir inferencia se convierte en software libre, y el margen pasa a ser el producto Señales: DeepInfer en Apache 2.0 con cifras de producción (155T tokens/día, 38 $/GPU-h), MiniMax a 0,15/0,60 $ con pesos anunciados, Mercury 3 a 1.068 tok/s, y ports de infraestructura escritos por agentes en días (tsrs). Hechos vs hipótesis: los lanzamientos y los precios son hechos; el "80% de margen" es un cálculo de tercero con coste GPU estimado, y los benchmarks de DeepInfer son de la casa, sin verificación independiente. Confianza: alta en la dirección, media en los números. Por qué importa: cuando el motor de servir es commodity, la ventaja no está en el modelo sino en el coste de operación y en la distribución — y eso lo puede replicar una consultora pequeña.
2. La durabilidad de sesión se estandariza como capa del harness
Señales: durable-harness (Vercel) con adaptadores para cuatro harnesses, Managed Deep Agents con ejecución durable, Agent Manager de HF con checkpoints cada 15 s y sesiones en backend, Pi Durable en Cloudflare y Vercel. Hechos: los lanzamientos. Hipótesis: que "sesión durable" deje de ser una feature y pase a ser un requisito de compra. Confianza: alta. Consecuencia: el portátil deja de ser el runtime; y quien no tenga log de intención/resultado por llamada va a pagar tokens duplicados en cada crash.
3. El acceso a modelos para seguridad se está convirtiendo en un permiso Señales: Huntley no pasó el Anthropic Cyber Verification Program porque usaba una cuenta personal patrocinada y "Node.js no tiene cuenta de empresa de Claude"; su conclusión: "usar los mejores modelos para seguridad se está volviendo cosa de unos pocos elegidos". En paralelo, OSS Scanner es opt-in y con filtros de aceptación. Hechos vs hipótesis: el rechazo es un hecho contado por el afectado; la tendencia (acceso mediado por verificación para trabajo ofensivo/defensivo) es hipótesis razonable. Confianza: media. Por qué importa: la infraestructura crítica la mantienen individuos sin contrato enterprise, y si el acceso a capacidad defensiva se gatea, la asimetría con el atacante (que usa modelos abiertos) crece.
🚀 3 cosas que probaría hoy
1. Medir tsrs en el CI de un repo TypeScript tuyo
Qué: npm install -D tsrs y npx tsrs -p . --noEmit en un repo real, comparando tiempo y memoria contra tsc --noEmit.
Por qué: es un drop-in sin riesgo de runtime (solo type-check) y el ahorro en CI se mide en minutos por push; en el codebase de VS Code hablan de 17,7x.
Esfuerzo: 15-30 min. Beneficio: CI más rápido y un dato propio frente a los benchmarks del fabricante. Si el repo es grande, ojo con --checkerAssignment go --noLazyMembers para comparar manzanas con manzanas.
Enlace: https://github.com/oxc-project/tsrs
2. Levantar Agent Manager en un Space privado y meter Hermes dentro
Qué: duplicar la plantilla, montar un bucket privado en /data, crear un agente sobre un repo de pruebas y abrir la misma sesión desde el móvil.
Por qué: resuelve el problema más repetido de la semana (sesiones que mueren con el portátil) sin montar infraestructura, y trae página de skills y de coste.
Esfuerzo: 45-60 min. Beneficio: un panel único para Hermes/Claude Code/Codex, con sesiones que sobreviven a desconexiones; y un sitio donde ver el gasto por agente.
Enlace: https://github.com/huggingface/agent-manager
3. Escribir la skill de superficie de ataque y correrla sobre un repo propio (o de un cliente) Qué: tres pasadas (default config, pre-auth, interacción de config) con contexto nuevo cada una, cada hallazgo con traza dinámica, y una compuerta propuesta que debe dejar los tests en verde. Por qué: es el entregable de seguridad más vendible de la semana —no promete encontrar el bug, promete reducir la superficie donde los bugs importan— y Anthropic ya publicó el método completo. Esfuerzo: 2-3 h para la skill + 1 h por repo. Beneficio: un informe con hallazgos verificables y parches, reutilizable como producto de entrada. Enlace: https://www.anthropic.com/research/attack-surface-reduction
💬 Conversaciones a seguir
- "Code review is risk mitigation" (Zach Lloyd) — la frase que va a dar que hablar: si el objetivo es reducir el riesgo de mergear sin leer, entonces la revisión línea a línea es un medio caro, no un fin. La objeción obvia (y correcta) es que sin leer no sabes qué riesgo estás aceptando; la respuesta de Warp es medición: 40% más PRs y 67% menos coste por PR. Merece seguimiento porque afecta a cómo se contrata y se revisa. https://x.com/zachlloydtweets/status/2112654624301654078
- Huntley y el Cyber Verification Program — "no lo pasé porque uso la cuenta personal patrocinada por Anthropic; Node.js no tiene cuenta de empresa de Claude. ¿Cómo mantenemos Node.js y otra infraestructura crítica a salvo?". El debate de fondo: ¿debe el acceso a capacidad defensiva depender de una relación comercial? https://x.com/GeoffreyHuntley/status/2112576252657676319
- El "company harness" de Harrison Chase — hilo con las cinco primitivas y una pregunta abierta: si todos los agentes se parecen por dentro, ¿por qué no usar uno off-the-shelf? Su respuesta: independencia de modelo, co-construcción con producto y observabilidad propia. Los comentarios de Caspar sobre qué hace difícil un "companyOS" son la parte útil. https://x.com/hwchase17/status/2112644945697976630
- El flywheel de los harnesses, según poteto y jediahkatz — su charla defiende que tras un periodo de estancamiento (los modelos se comieron el trabajo del harness) vuelve la innovación: software factories, Cursor Projects, Grok Bot. Buen contrapunto a "el harness ya no importa". https://x.com/poteto/status/2112669091219542269
- La brecha entre quien tiene agente personal y quien no (steipete) — "OpenClaw es tan bueno ahora que empiezo a ver una brecha real de skills entre quien no ha montado un agente personal y quien sí. No da miedo". Es la versión individuo de la conversación de las fábricas de software. https://x.com/steipete/status/2112643373064482845
⚠️ Fallos de fuentes
bagderdevuelve un timeline de noviembre de 2024 aunque la cuenta está viva (58.165 followers, id 14893620, bio de curl). Es fallo deuser-postspara cuentas con mucho volumen de replies, no un handle equivocado; el contexto de curl lo saqué de daniel.haxx.se y de las notas de release de OpenSSH, no de X.- Dos handles estaban mal en la watchlist y los he corregido:
lmarena_aies una cuenta migrada a @arena (bio: "Moved to @arena", 235k followers) ysstera un usuario vacío de 2007 con 45 followers; el equipo de SST está en @SST_dev. Metí a mano los posts de @arena de la ventana (de ahí el dato de la frontera de Pareto y del #1 de V4.1-Flash en Agent Arena); @SST_dev no tuvo posts en ventana. - El endpoint no devuelve métricas: todos los posts llegan con 0 likes y 0 replies, así que no puedo priorizar por engagement esta edición; he priorizado por contenido y por contraste con fuente primaria.
- Benchmarks de fabricante sin verificación independiente: tsrs (8x/70% es de Cloudflare/Oxc; el 17,7x es del repo de Schwenk con otra máquina y otra config), DeepInfer (25.000 tok/s/GPU y 155T tokens/día son de DeepSeek; no hay benchmark independiente), y los 493 hallazgos de Anthropic son su propia medición sobre proyectos que eligieron ellos.
- El 80% de margen de DeepSeek es un cálculo de swyx, no una cifra publicada: usa 38 $/GPU-h de ingresos off-peak y un coste estimado de 5-10 $/GPU-h. La parte verificable es el 38 $/GPU-h (está en el Q&A de despliegue); el coste no.
- tsrs: "escribió cero código" y "24.000 $ de tokens" son afirmaciones de los propios implicados (Schwenk y Theo Browne) recogidas por prensa secundaria; no hay auditoría. Las trato como testimonio, no como hecho medido.
- Duplicados gestionados: Muse Wonder (12-oct) reaparece hoy solo por distribución (Cline, Cloudflare, Cursor) y por el ranking de Arena; no lo repito como lanzamiento. CatJam de Reflection ya estaba en
tools_seen. La vuelta de Aleksander Mądry a OpenAI (19-oct) es noticia de personas, sin componente técnico verificable hoy: la dejo fuera. - eMudhra no es una historia de IA: la incluyo por impacto operativo (trust stores de runtimes y contenedores) y porque el método de Huntley para parchearla sí lo es. Si prefieres el radar estrictamente AI, esta es la entrada a saltar.
- Sin bloques de código copiados sin verificar:
npm install tsrs,npx tsrs -p . --noEmit,cline plugin install,mda init/dev/deployvienen de la documentación o del blog; los comandos degit worktree+codex exec+claude -pson un esqueleto propio, no una cita de steipete; el fragmento deAGENTS.mdestá parafraseado del ejemplo de Huntley, no copiado entero.