AI Radar — 20 de octubre de 2026

Ventana: 19 oct 06:45 → 20 oct 06:45 (Europe/Madrid). 48 posts de 40 handles, contraste con fuente primaria en cada item. Duplicados con las ediciones del 15-19 oct filtrados.

🔥 Lo más importante

1. Un solo atacante usó agentes para intentar entrar en 1.200 webs y brechear más de 100 empresas a ~50 $ por víctima (Reuters, 19 oct) [N5/I5/A4/R4] Qué pasó: Reuters publicó el 19-oct la investigación de Snorre Fagerland (NorForge), que encontró una veintena de instancias expuestas de Cairn —plataforma OSS de "resolución de problemas" con agentes, muy usada en el underground— y pudo leer por encima del hombro de varios atacantes. El más prolífico, chino-parlante, lanzó agentes el 25-sep contra e-commerce de EE.UU., Canadá, Australia y Japón: más de 1.200 sitios intentados, más de 100 comprometidos (Deere, SharkNinja y Cummins entre las víctimas identificadas por Reuters). Las instrucciones cabían en menos de 100 caracteres en chino; una intrusión exitosa promediaba ~23 horas de prueba y error; el gasto total en tokens rondó 5.000 $, unos 50 $ por brecha. Los labels internos de Cairn apuntan a una mezcla de modelos DeepSeek y Claude Code (Reuters no pudo confirmar la combinación exacta). No es aislado: Gambit documentó en agosto un caso con Cursor (7 organizaciones) y en septiembre otro con 25 empresas y 600.000 tarjetas. Por qué importa: el cuello de botella del ataque ya no es la habilidad, es el presupuesto de tokens y el tiempo de pared. 23 horas de autopilot a 50 $ es más barato que una hora de un pentester junior, y no se aburre en el intento 40 de la misma página de login. Para cualquier negocio con e-commerce o panel expuesto, el modelo de amenaza cambia de "alguien con skills" a "alguien con una API key y paciencia". Consecuencias: inventario de superficies expuestas (incluidos paneles de herramientas de agentes que se despliegan con auth por defecto), rate limiting y detección por comportamiento horario, y no dejar agentes propios sin sandbox ni límites de gasto — el mismo patrón que se usó contra estas webs es el que se puede usar contra tu infra. Enlaces: https://www.reuters.com/legal/government/how-one-hacker-used-ai-agents-few-thousand-dollars-break-into-scores-sites-2026-10-19/ · espejo accesible: https://www.bnnbloomberg.ca/business/artificial-intelligence/2026/10/19/how-one-hacker-used-ai-agents-and-a-few-thousand-dollars-to-break-into-scores-of-sites-reuters-exclusive/ (19-10-2026)

2. MiniMax M3.1 Flash: el modelo stealth "Space Bunny" era suyo, 200 billones de tokens de prueba y precios de 0,15 $/0,60 $ (lanzamiento, 19 oct) [N5/I5/A5/R5] Qué pasó: MiniMax confirmó el 19-oct que Space Bunny —el modelo anónimo que estuvo semanas nº1 en OpenRouter/OpenCode— era una versión temprana de M3.1 Flash. El post oficial habla de "salto generacional" en tareas agénticas, coding, computer use y ciberseguridad, con inferencia casi 3x más rápida (200+ TPS, P50 170+) y 70% menos coste de uso que su predecesor, gracias a sparsity más agresiva. Precio plano: 0,15 $ input / 0,60 $ output / 0,015 $ cached input por millón. Benchmarks de la casa: BankerToolBench 76,2; DeepSWE v1.1 73,7%; OSWorld V2 61,7; Agents' Last Exam 29,6; CyberGym 82%. En el tuit de lanzamiento añaden Automation-Bench 62%, ALE 30%, BabyVision 91%. Pesos el 23-oct (licencia aún sin anunciar). Disponible en API, M Plan y MiniMax Code; gratis unos días en Cline y OpenCode (OpenCode: "free for the next 3 days"). Por qué importa: (a) el precio no es de tier Flash occidental, es de commodity: con cache reads a 0,015 $ el coste real de un loop de agente lo dominan los output tokens; (b) la ruta de lanzamiento se ha convertido en el producto: un modelo anónimo acumuló 200T tokens de tráfico real y reputación en leaderboards antes de tener nombre — eso es un eval de uso pagado por otros, y es imposible de reproducir desde fuera; (c) la tabla es del fabricante y varios benchmarks son internos (BankerToolBench, DeepSWE v1.1, AutomationBench-AA), así que el número que importa es el tuyo, no el suyo. Consecuencias: ventana gratis para medirlo en una tarea real esta semana; si tu eval corrió contra "Space Bunny" en septiembre, ese modelo no es el M3.1 Flash de hoy (versión temprana, según MiniMax); y ojo con ALE 29,6: se presenta como liderazgo "entre modelos chinos", pero un 30% en examen de trabajo profesional real dice mucho de lo lejos que sigue estando el computer use de verdad. Enlaces: https://www.minimax.io/blog/minimax-m31f · https://x.com/MiniMax_AI/status/2112150867868541221 · https://x.com/opencode/status/2112156205938626954 · https://x.com/cline/status/2112220504258224605

3. OpenAI ataca el código legacy: GPT-6 Astra pasa del 26,8% al 87,4% en MultiLangBench y la migración COBOL llega al 97,9% (investigación, 19 oct) [N4/I5/A5/R4] Qué pasó: OpenAI publicó el 19-oct dos evaluaciones nuevas y los resultados de sus modelos. MultiLangBench pide construir desde cero un motor de base de datos compatible con SQLite en 20 lenguajes: GPT-6 Astra promedia 87,4% de tests pasados (26,8% en GPT-5.6 Sol), con COBOL como el más difícil (10,9% → 72,1%), Fortran 21,4% → 83,5% y Visual Basic 27,5% → 89,4%; Astra supera el 83% en 19 de los 20 lenguajes. La evaluación de migración COBOL mide traducir programas a C++/Java/Kotlin/Python/Rust preservando comportamiento: GPT-6.1 Sol 86,6% con reasoning bajo (5,4% en GPT-5.6 Sol, y 39% más barato), 97,9% con reasoning alto — casi saturación. No hay modelo nuevo: son mejoras de los existentes más los benchmarks. Por qué importa: el mercado de modernización legacy (banca, seguros, administración) lleva décadas atascado por dos motivos: nadie entiende el código y reescribirlo cambia el comportamiento en silencio. Un eval que exige paridad de comportamiento observable es exactamente la métrica que un cliente enterprise quiere ver antes de firmar, y aquí es donde una consultora de automatización puede vender un piloto acotado en vez de un proyecto de dos años. Consecuencias: si tienes un cliente con COBOL/Fortran, el entregable ya no es "una reescritura", es un arnés de paridad (golden files de entrada/salida del programa original + tests ocultos) y el modelo como traductor; sin ese arnés, el 97,9% no significa nada. Y tratándose de evals del propio fabricante, exige tu propio set de programas antes de prometer nada. Enlaces: https://openai.com/index/low-resource-programming-languages · https://x.com/OpenAI/status/2112310345863930168 (19-10-2026)

4. OSS Scanner, semana 1: 650 proyectos solicitados, 114 aceptados, 77 hallazgos críticos y el CVE del año en curl (seguimiento, 19 oct) [N3/I5/A4/R5] Qué pasó: Anthropic lanzó OSS Scanner el 8-oct (ya lo cubrimos el 12-oct); el 19-oct Punit Shah publicó los primeros números: ~650 proyectos aplicaron, 114 aceptados, 77 hallazgos críticos y 803 altos "model-rated" enviados a maintainers, sin triaje humano. El caso estrella: CVE-2026-92392, un use-after-free en la subida HTTP/2 de curl que puede llegar a RCE, severity HIGH, corregido en curl 8.23.0 (14-oct) — Daniel Stenberg lo describe como una de las peores vulnerabilidades de curl en mucho tiempo y adelantó el ciclo de release de 8 a 6 semanas. Aprendizajes operativos del hilo: la mayoría de los primeros informes rebotaron porque los filtros de correo trataban los PoC como malware; ya pilotan entrega vía GitHub Security Advisories y han clarificado criterios (rechazos típicos: licencia no OSS). Por qué importa: es la primera evidencia pública de que un pipeline de "modelo fuerte + sandbox sin red + Dockerfile reproducible" encuentra bugs reales en infraestructura crítica a un ritmo que los humanos no pueden triar. Y el detalle del email es la lección: el último kilómetro de un agente no es el hallazgo, es la entrega — un PoC que no llega al maintainer vale cero. Consecuencias: si mantienes OSS crítico, la inscripción es un PR con project.yaml + Dockerfile; si construyes agentes, copia el patrón (entorno reproducible, sin red durante el análisis, informe con reproducer + parche candidato). Y asume falsos positivos: 77+803 son "model-rated", no verificados. Enlaces: https://red.anthropic.com/oss-scanner · https://x.com/ClaudeDevs/status/2112299602510749992 · https://x.com/thepunit/status/2112267290096111896 · https://daniel.haxx.se/blog/2026/10/14/a-uaf-turned-rce/

🛠️ Herramientas

Timestral (Mistral) — modelos fundacionales de series temporales que corren en CPU Qué es: familia de cuatro modelos (5M, 28M, 123M, 209M parámetros) para forecasting probabilístico y multivariante, con covariates pasadas, futuras conocidas y categóricas; contexto de 32.768 pasos, 21 cuantiles por paso. El 209M se declara nº1 en GIFT-Eval, TIME y fev-bench entre modelos preentrenados zero-shot, con un solo checkpoint y sin ensembling. Problema que resuelve: predecir series (sensores, tráfico, capacidad, energía) sin GPU y sin entrenar desde cero por cliente; el 28M queda a 0,2% del score del 209M con 5x menos latencia. Diferencia: no es un LLM con números pegados: es un TSFM que se integra en el pipeline existente y se puede afinar con Mistral Forge. Código Apache 2.0, pesos modified MIT en Hugging Face, deploy on-prem/VPC/air-gapped. Ejemplo: pip install git+https://github.com/mistralai/timestral.git y TimestralForecaster.from_pretrained("mistralai/Timestral-209M"); 140 ms para un día de forecast con 8 hilos de CPU. Enlace: https://mistral.ai/news/timestral/ · https://github.com/mistralai/timestral · ficha HN (566 pts, 19-oct): https://news.ycombinator.com/item?id=50150434 Veredicto: probar — es el caso raro de "modelo nuevo, coste marginal cero" para una consultora: un piloto de mantenimiento predictivo se puede montar en una tarde.

Harness² (Google Research) — que el agente reescriba su propio arnés, con el modelo congelado Qué es: framework de "recursive agent harnessing" (arXiv 2610.14224, Google Cloud AI Research + Northwestern). Define el harness como 8 ficheros editables (system prompt, guardrails, memoria, skills, guía de tools, scripts, subagentes, plugin de middleware) y aplica un paso contrastivo Propose–Probe–Compose: propone dos ediciones, las ejecuta en la misma tarea y se queda solo con lo que el contraste de comportamiento sostiene — sin verifier ni ground truth. Una segunda recursión guarda un EXPERIENCE.md con las lecciones para tareas futuras. Problema que resuelve: el ajuste manual del harness no escala y no hay labels en tareas nuevas. Diferencia: no toca pesos ni hace RL; el coste es ~4 ejecuciones del agente por tarea (referencia, 2 probes, final). Ganancias reportadas: +11,5 en WorkBuddy-Bench, +4,5 en JobBench, +11,8 pp en LAB. Ejemplo: uv pip install -e '.[render]' + harness2-setup jb + harness2 --bench jb --k 1 --mode parallel (executors de OpenCode y Codex). Enlace: https://github.com/google-research/harness2 · https://arxiv.org/abs/2610.14224 · hilo que lo rescató: https://x.com/sydneyrunkle/status/2112043827553005651 Veredicto: seguir — es código de investigación (v0.1.0, aviso del propio repo: acceso de red sin restringir en los executors, sandbox de Codex desactivado), pero el patrón "edita, prueba, compara comportamiento, conserva lo que gana" es directamente portable a un harness propio.

Mercury 3 (Inception) — LLM de difusión a 1.068 tokens/s Qué es: el modelo de difusión de texto más capaz hasta la fecha según Inception, 1.068 tok/s en GPUs NVIDIA, contexto de 1M (antes 260K), API compatible con OpenAI, disponible en Inception, OpenRouter, Baseten y Vercel. Precio 0,20 $/0,70 $ por millón (50% off de lanzamiento: 0,10 $/0,35 $, cache 90% de descuento sobre input). Problema que resuelve: latencia en agentes que esperan al modelo en cada paso — browser use, tutores, soporte en tiempo real. Diferencia: no compite por techo de inteligencia sino por pasos por segundo; la casa dice que iguala o supera a GPT-6 Luna y Claude Haiku 5.5 (benchmarks del fabricante). Ejemplo: 100M tokens gratis en platform.inceptionlabs.ai; al ser OpenAI-compatible se cambia base_url y modelo sin tocar el código. Enlace: https://www.inceptionlabs.ai/blog/introducing-mercury-3 · HN: https://news.ycombinator.com/item?id=50155245 Veredicto: probar en un loop con muchos pasos cortos (navegación, clasificación, extracción), no en tareas de razonamiento largo.

Vercel Shop + Universal Commerce Protocol — tiendas pensadas para que las compre un agente Qué es: plantilla Next.js para Shopify en GA, construida sobre el Hydrogen SDK reconstruido; las páginas de producto se sirven también como contenido legible por máquina (precio, disponibilidad, opciones) y exponen MCP para buscar productos y montar carrito, usando el UCP (ucp.dev) que Shopify co-desarrolló. Incluye asistente (eve) y "skills" en la plantilla para que un coding agent la configure. Problema que resuelve: los agentes compradores hoy parsean webs hechas para humanos y para SEO, con fricción y errores. Diferencia: el mismo producto se sirve como página visual o como dato estructurado; el carrito es compartido entre humano y agente. Enlace: https://vercel.com/blog/vercel-and-shopify-make-agents-first-class-shoppers · https://vercel.shop Veredicto: seguir — hoy es nicho e-commerce, pero es la primera implementación de referencia de "agente como comprador de primera clase" con protocolo abierto.

💡 Tips aplicables hoy

1. Define la verificación antes de delegar (el problema real de los agentes ambiciosos) Problema: C. Jav (Anthropic) lo dijo el 19-oct: "la parte más difícil de construir un proyecto ambicioso es definir la verificación — dar al agente todo lo que necesita para verificar formalmente y poder iterar". Sin eso, el agente itera contra su propia opinión. Técnica: escribe el criterio de "hecho" como checks ejecutables antes de lanzar el agente, y ponlo en el fichero de instrucciones para que lo lea en cada turno. Implementación (esqueleto de verify.sh, adáptalo a tu repo):

#!/usr/bin/env bash
set -euo pipefail
pnpm -s typecheck        # compila
pnpm -s test -- --run    # tests existentes
pnpm -s lint             # estilo
git diff --stat | tail -1 # presupuesto de cambio visible

y en AGENTS.md: "Definition of done: ./verify.sh en verde + diff < 300 líneas + ningún test borrado. Si no puedes cumplirlo, para y explica por qué". Enlace: https://x.com/cjav_dev/status/2112158805551378823 (19-10-2026)

2. Watchdog barato para sesiones de agente colgadas (tmux + modelo gratis) Problema: los agentes se quedan esperando, sin avisar, y te enteras una hora después. Geoffrey Huntley publicó el 19-oct su truco: un modelo gratis en OpenCode que "scrapea" sesiones en su orquestador y las empuja si están colgadas. Técnica: tmux da las dos primitivas que necesitas — send-keys para escribir dentro de una sesión y capture-pane para leer la pantalla. Implementación:

tmux new-session -d -s api -c ~/code/api        # una sesión por repo
tmux send-keys -t api "claude --worktree --tmux=classic" Enter
tmux capture-pane -pt api | tail -40             # leer sin attach

Con eso, un cron cada 10 min busca el patrón de "esperando input" y manda Enter o un mensaje de desbloqueo; si no hay cambio de pantalla en N ciclos, avisa. (Detalle del guía: --tmux exige --worktree y en iTerm2 usa panes nativos, así que para scriptar hay que pedir --tmux=classic.) Enlaces: https://x.com/GeoffreyHuntley/status/2112222982844420286 · guía: https://crystl.dev/guides/tmux-for-ai-agents/

3. Ponte tu propio proxy de LLM o no sabrás por qué cambió el coste Problema: los paneles de los proveedores dan gráficos, no decisiones; cuando una sesión se encarece o el cache hit rate se hunde, no hay forma de saber qué llamada lo causó. Técnica: un proxy propio (LiteLLM, OpenRouter proxy, uno casero) delante de todos tus agentes — un endpoint, varias claves y proveedores, logs de qué clave llamó a qué modelo, con qué cliente, a qué hora y con qué estado. Implementación: enruta todas las tools por el proxy, usa virtual keys por proyecto/agente (deja de repartir tu clave principal) y registra tokens de entrada, de salida y cache reads por request; con eso un cache miss se diagnostica en segundos en lugar de especular. Enlace: https://jrdsgl.com/if-you-dont-run-your-own-llm-proxy-how-the-fuck-do-you-even-know-whats-going-on/ · HN (295 pts, 210 comentarios): https://news.ycombinator.com/item?id=50145507

4. Memoria en ficheros propios, no en el vendor Problema: Matt Pocock, tres meses después: su wiki personal se ha vuelto "infraestructura crítica" para su negocio y hace viable eso de "agentes que llevan mi negocio"; su conclusión es explícita — depender de un vendor para la memoria es receta de lock-in. Técnica: un repo de markdown con index.md (mapa), un fichero por tema, y una skill/instrucción que obligue al agente a leer el índice primero y escribir ahí lo aprendido. Implementación: ~/wiki/{index.md,clientes/,decisiones/,runbooks/} + en AGENTS.md: "antes de responder sobre el negocio, lee ~/wiki/index.md; después de una decisión, añade una entrada de 5 líneas con fecha y enlace". Portátil entre Claude Code, OpenCode, Codex y Hermes sin exportar nada. Enlace: https://x.com/mattpocockuk/status/2112131671097020895 (19-10-2026)

5. Diseña el prompt para el cache: 10x de diferencia en input Problema: en un loop de agente reenvías system prompt, tool schemas e historial en cada turno; si el prefijo cambia, pagas input completo otra vez. Técnica: prefijo estable y byte-idéntico (system prompt + esquemas de tools + instrucciones de proyecto) y todo lo variable al final; mide cache reads por request. En M3.1 Flash el cached input cuesta 0,015 $/M frente a 0,15 $/M — un 10x — y esa es la razón por la que el precio "plano" bajo es en realidad un precio para loops. Implementación: quita timestamps/IDs aleatorios del system prompt, ordena los esquemas de tools de forma determinista y comprueba cache_read_input_tokens (o el campo equivalente) en la respuesta; si es 0 en turnos 2+, tienes un fallo de prefijo. Enlace: https://www.minimax.io/blog/minimax-m31f

🧠 Qué hacen los mejores

• Harrison Chase / Sydney Runkle: "un agente = modelo + contexto + harness", y el ROI está en el contexto. El resumen del podcast con Chase (19-oct) es el mejor mapa mental de la semana: puedes mejorar un agente tocando cualquiera de las tres capas, pero empieza por contexto (ahí vive el conocimiento de dominio), luego harness, luego pesos; el ciclo de continual learning es "corre el agente, recoge trazas, agrega aprendizajes, arregla algo, mide el arreglo, repite". Y dos frenos honestos: la memoria sigue sin resolverse (lo difícil es destilar aprendizajes de trazas, muy dependiente del dominio) y todo agente se juega en accuracy, coste, latencia y seguridad. Enlace: https://x.com/sydneyrunkle/status/2112256862318194818
• Matt Pocock: wiki propia + agentes que dibujan. Tres meses de wiki personal como infraestructura, y su agente de TLDraw mejorando diagramas (autocrítica incluida: "muy cargado de flechas, pero buen uso del color"). El detalle más útil: un agente le desenterró una respuesta sin leer de Michael Feathers. La lección no es el dibujo, es que el agente vigila lo que tú no vas a volver a mirar. Enlaces: https://x.com/mattpocockuk/status/2112131671097020895 · https://x.com/mattpocockuk/status/2112184048248336654
• Zach Lloyd (Warp): "factory engineering" como segundo trabajo del ingeniero. Su ensayo del 19-oct rechaza la metáfora de la fábrica (assembly line o construir la línea que te sustituye) y la de "AI teammate" (manager de juniors ineptos y pelotas). Su versión: el equipo sigue siendo responsable del producto —qué construir, cómo encaja, qué es buen diseño— y además diseña y mide la fábrica: cuánto shipea cada agente y a qué coste, con mentalidad de ingeniería, no de vibes. "No ajustas tu fábrica por vibes; mides, testeas, benchmarks y mejoras." Enlace: https://x.com/zachlloydtweets/status/2112197085143674940 · charla: https://youtu.be/x-PK3yx_MJg
• Geoffrey Huntley: el harness como sistema de recursos y el doble check con otro modelo. Dos ideas del 19-oct: (1) su workflow es "quemo OpenAI para volumen y luego paso a Opus a revisar lo incompleto" — un patrón de productor barato + auditor caro que ya se ve en pipelines de datos; (2) "loop engineering" como problema de scheduling: o te sobran cores o te sobra inferencia, nunca las dos. Enlaces: https://x.com/GeoffreyHuntley/status/2112246468492869936 · https://x.com/GeoffreyHuntley/status/2112179629523968395
• swyx: "data engineers > AI engineers". Su tuit del 19-oct es una corrección de mercado: hay una diferencia enorme entre "chico de RAG" y alguien de Data-Intensive Applications, y nunca había visto tanta distancia de demanda. Está contratando para eso. Señal para quien venda formación o servicios: el diferencial no es prompt engineering, es saber montar sistemas de datos. Enlace: https://x.com/swyx/status/2112073533794971941
• cjav_dev (Anthropic): la verificación es el trabajo. Una línea que resume la semana mejor que cualquier benchmark: lo difícil no es que el agente escriba, es definir cómo comprueba que acertó. Enlace: https://x.com/cjav_dev/status/2112158805551378823

📈 Señales del futuro

1. El comercio agéntico empieza a tener protocolo (no solo scraping) Señales: Vercel Shop GA con Hydrogen reconstruido, páginas de producto legibles por máquina y MCP para búsqueda y carrito sobre el Universal Commerce Protocol de Shopify. Hechos vs hipótesis: GA, SDK y UCP son hechos verificables hoy; la hipótesis es que el tráfico de agentes se convierta en un canal de primera clase con su propia analítica y precios. Confianza: media. Por qué importa: si vendes automatización a e-commerce en España, "que tu tienda se deje comprar por un agente" pasa de experimento a requisito de RFP en 2-3 trimestres.

2. El lanzamiento stealth se consolida como go-to-market de modelos Señales: Space Bunny acumuló 200T tokens anónimos y 12 días nº1 en OpenCode antes de ser M3.1 Flash; DeepSeek cambió el checkpoint de deepseek-flash bajo el mismo alias sin avisar. Hechos vs hipótesis: los dos hechos están confirmados por los fabricantes; la hipótesis es que esto sustituya al benchmark de lanzamiento — el eval pasa a ser tráfico real pagado por otros. Confianza: alta en el patrón, media en que sea sostenible. Consecuencia práctica: fija versión/checkpoint en tus evals y no compares resultados de hace dos semanas con los de hoy.

3. La asimetría económica entre ataque y defensa se está abriendo Señales: ~50 $ por brecha con agentes autónomos (Reuters, 19-oct) frente a escaneos de vulnerabilidades gratis para OSS crítico (OSS Scanner, con un CVE de curl en la primera semana). Hechos: ambos verificables; hipótesis: el coste marginal del ataque cae más rápido que el de la defensa, porque la defensa necesita un humano que trie y parchee. Confianza: media-alta. Qué hacer: presupuestar remediación (parches, no solo hallazgos) y asumir que tu superficie expuesta se va a escanear con agentes — propios o ajenos.

🚀 3 cosas que probaría hoy

1. Medir MiniMax M3.1 Flash gratis en una tarea real tuya, con coste y latencia anotados Qué: correr una tarea de tu repo (un fix multi-fichero o una migración pequeña) en OpenCode o Cline con M3.1 Flash durante la ventana gratis, y comparar con tu modelo actual. Por qué: es la única forma de saber si el 73,7% de DeepSWE se traduce en tu código; los benchmarks son del fabricante. Esfuerzo: 30-45 min. Beneficio: decide si cambias el modelo por defecto del 80% de tus tareas y cuánto baja la factura. Enlace: https://x.com/opencode/status/2112156205938626954

2. Montar Timestral en CPU sobre una serie real (sensores, tráfico o ventas) Qué: pip install git+https://github.com/mistralai/timestral.git, cargar Timestral-28M o 209M y comparar contra tu baseline (media móvil/ARIMA) en las últimas 2 semanas de datos. Por qué: 140 ms de forecast en CPU y pesos modified MIT significan que un piloto de mantenimiento predictivo cabe en una mañana, sin GPU ni cloud. Esfuerzo: 1-2 h. Beneficio: capacidad nueva vendible (forecast probabilístico con cuantiles) y un artefacto de demo. Enlace: https://github.com/mistralai/timestral

3. Escribir el verify.sh de un agente que ya tengas en producción + watchdog en tmux Qué: convertir el criterio de "hecho" que hoy tienes en la cabeza en un script ejecutable, y añadir un cron que lea la sesión con capture-pane y avise si no hay progreso en 10 minutos. Por qué: ataca los dos fallos más caros de esta semana: agentes que iteran sin verificación (cjav) y sesiones colgadas que descubres tarde (Huntley). Esfuerzo: 1-2 h. Beneficio: menos revisiones manuales y menos horas perdidas en silencio. Enlace: https://crystl.dev/guides/tmux-for-ai-agents/

💬 Conversaciones a seguir

• Ask HN: "How to deal with shipping AI-written code you don't understand?" — 327 puntos y 476 comentarios en un día. Es el debate de fondo de todo lo demás: si el código funciona y no lo entiendes, ¿qué se hereda? Posiciones: exigen revisión línea a línea (no escala), tests de contrato y propiedad del comportamiento, o aceptar que el código pasa a ser un artefacto desechable con tests como especificación. Lectura obligada para cualquiera que venda "agentes que shipean". https://news.ycombinator.com/item?id=50151036
• HN sobre Timestral: el escéptico de las covariates — el hilo (566 pts) tiene la mejor crítica técnica del día: si el modelo solo ve una ventana de N muestras y las covariates futuras son "un extra", un sistema simple que sepa el calendario y el tiempo atmosférico le gana en casos como consumo eléctrico. La respuesta razonable del hilo: sirve para forecasting de sistemas con feedback (autoscaling, tráfico), no para decidir comprar acciones. https://news.ycombinator.com/item?id=50150434
• Zach Lloyd vs la metáfora de la fábrica — 166 likes, 23 respuestas, y una invitación abierta a hablar con quien no esté de acuerdo. La discusión útil: ¿"factory engineering" es una disciplina nueva o es SRE con otro nombre? https://x.com/zachlloydtweets/status/2112197085143674940
• "Data engineers > AI engineers" (swyx) — 70k vistas y una oferta de trabajo detrás. El debate implícito: si el valor está en los datos y no en el prompt, la ola de "AI engineer" fue una etiqueta transitoria. https://x.com/swyx/status/2112073533794971941
• Harness² y el continual learning sin labels — el hilo que lo trajo a la conversación (19-oct) conecta el paper con la práctica: "también se llama hill climbing". La objeción pendiente: sin ground truth, ¿cómo distingues una mejora de un cambio de estilo? https://x.com/sydneyrunkle/status/2112043827553005651

⚠️ Fallos de fuentes

• Reuters devuelve 403 al extractor (Keenable): usé la URL canónica de Reuters para el enlace y contrasté el contenido con dos espejos de la misma pieza (BNN Bloomberg y MarketScreener). Cifras y nombres coinciden en los tres.
• lmarena_ai y sst siguen devolviendo 0 resultados (segundo día). No los muteo todavía: puede ser fallo del endpoint user-posts, no cuenta muerta. Se reintenta mañana.
• Sin posts nuevos en ventana: karpathy (último 11-oct), simonw (15-oct), deepseek_ai (17-oct), cursor_ai (16-oct), GoogleDeepMind (16-oct), sama (16-oct), perplexity_ai (16-oct), bernhardsson (18-oct), lydiahallie (17-oct). steipete solo retuiteó. feed de X no se usó (sigue roto en 0.8.5); la ventana se aplicó sobre user-posts de 40 handles, sin errors.log.
• Duplicados gestionados: OSS Scanner se cubrió el 12-oct en su lanzamiento; hoy entra solo por los números de la primera semana y el CVE de curl. DeepSeek V4.1-Flash-1017 se cubrió ayer; hoy solo aparece como nota de disponibilidad en OpenCode, no como item.
• Fechas que no son de hoy: Harness² es del 9-oct (paper y repo) y resurge el 19-oct en el hilo de Chase; Timestral es del 15-oct y llega a portada de HN el 19-oct. Lo marco en cada entrada para no vender novedad donde no la hay.
• Datos contradictorios o sin confirmar: licencia de los pesos de M3.1 Flash sin anunciar (solo fecha, 23-oct); tamaño 428B/23B activos viene de la guía de developers, no del post de lanzamiento; benchmarks de MiniMax, Mercury 3 y OpenAI son del fabricante (varios internos); un medio secundario atribuye licencia CC BY 4.0 a Harness², pero el repo dice Apache 2.0 — uso el repo; los "77 críticos / 803 altos" de OSS Scanner son model-rated, sin triaje humano.
• Sin bloques de código copiados sin verificar: los comandos de tmux y de Timestral vienen de la guía y del README respectivamente; verify.sh es un esqueleto propio, no una cita.