Hoy probé Kimi K3.1 Pro en generación 3D y la mejora se nota mucho: escenas, juegos y modelado, con pocos errores. Moonshot apuntó justo ahí: trabaja con Blender, Unreal, Godot y CAD. También mejoró en código y finanzas, y según su prueba interna alucina 65% menos que K3. Y ya no es tan lento: va a unos 73 tokens por segundo, el doble que K3 (y hay una versión Highspeed 2-3x más rápida). En precio: $2/$10 por millón de tokens, 5 veces más barato que Astra ($10/$50) y la mitad que Opus 5.5 ($4/$20). Ojo: es el mismo precio que GPT-6.1 Sol. En benchmarks ya está ahí arriba: en Terminal-Bench 4.0 saca 65.7%, por encima de Astra (58.2%) y casi igual que Opus 5.5 (66.4%). Artificial Analysis lo midió por su cuenta y le dio 67%, y en su índice general queda por encima de Astra y solo detrás de Opus 5.5. Pero tiene sus límites: • En 3D, Astra y Opus siguen un poco adelante: en BenchCAD saca 92.7% vs 95.9% de Astra y 96.2% de Opus 5.5. • En tareas científicas en terminal se queda atrás: 38.1% vs 68.1% de Astra en Terminal-Bench Science. • En mis pruebas lo sentí menos verboso, pero en el índice de Artificial Analysis todavía gasta muchos más tokens que la mediana (150M vs 87M). Así que el ahorro real es menor que la diferencia de precio. En lo que probé, lo sigo poniendo un poco por detrás de Astra, pero no tan lejos. Lo impresionante es que va a ser un modelo abierto: Moonshot promete publicar los pesos antes del 4 de noviembre, así que vas a poder alojarlo tú mismo (eso sí, con hardware de datacenter). Al menos mientras Anthropic y OpenAI no lancen sus próximos modelos, Kimi K3.1 Pro está muy cerca de la frontera.

Una de las razones por las que ciertos programadores aún no se adaptan a la IA es que creían que su trabajo era escribir código. Pero lo más difícil de programar nunca fue la sintaxis. Fue entender sistemas que no se ven: cómo viaja un request, cómo se referencia la memoria, dónde vive el estado de una parte de la interfaz, cómo pasa un dato de un sistema a otro y cómo se divide y normaliza en el camino. Eso siempre fue el trabajo real de un programador. La sintaxis era solo el medio para llevarlo a cabo. Y esa parte, entender cómo funcionan las cosas, sigue igual de vigente. La diferencia es que ahora ya no lo escribes todo tú: tienes algo que lo escribe por ti. Así que si pensabas que programar era escribir mucho en el teclado, se entiende por qué la IA te molesta tanto.

Los programadores de COBOL cobraban bien porque nadie más lo sabía. Ahora la IA lo sabe. OpenAI con sus nuevos modelos ya migran código COBOL con un 86 % de acierto. Su versión anterior apenas llegaba al 5 %.

¿Por qué hoy todo el mundo cripto está hablando de oro? Me llamó la atención ver a tantos cripto bros compartiendo la misma noticia, así que me puse a ver de qué iba esto. Y la verdad, me pareció muy interesante. Marathon Fusion, una startup de San Francisco, dice que logró convertir mercurio en oro real y estable. Y no, no es magia, es física nuclear. Básicamente bombardean mercurio con neutrones, eso cambia el núcleo de sus átomos y, en unos días, se convierten en oro real, el mismo que se saca de las minas. Y según la empresa, lo hicieron a una tasa 10 veces mayor que el récord del CERN de 2025. Aunque en realidad no publicaron cuánto oro produjeron, y el récord del CERN fue de apenas 29 picogramos. O sea, hoy esto es un experimento de laboratorio, no una fábrica de lingotes. Fabricar oro así cuesta muchísimo más de lo que vale. Aun así, me igual te hace pensar en algo. Durante siglos, el argumento a favor del oro fue que es escaso porque la naturaleza no lo regala fácil. Pero si algún día la tecnología logra producirlo de forma barata, esa escasez dejaría de ser absoluta. El oro seguiría valiendo, pero su escasez pasaría a depender del costo de fabricarlo. Y aquí es donde Bitcoin se pone interesante. Su escasez no depende de la materia ni de ninguna tecnología. El protocolo fija un máximo de 21 millones de monedas, y ese límite solo cambia si toda la red lo acepta. No hay mina, reactor ni laboratorio que pueda crear más. Y es por esto que los cripto bros celebran porque esta noticia les da un argumento nuevo. Pero la pregunta de fondo es otra: ¿qué pasa con un activo cuando su escasez depende de que la tecnología no avance? Ahí está lo interesante. El oro apuesta a que fabricarlo siga siendo caro, y Bitcoin apuesta a que sus reglas no cambien. Son dos tipos de escasez muy distintos, y esta noticia nos obliga a mirarlos de frente.

Qué será de ese Dev que tenía su app de backend en PHP y frontend ejecutandose con Node, un backend con LiteLLM , desarrollada con OpenCode, con su codigo guardado en GitLab Self-Hosted y desplegada en Railway con certificados de eMudhra.

Al parecer, el día de hoy todo internet se está cayendo a pedazos. Y es que en Railway también: esta mañana detectaron que un tercero no autorizado pudo acceder a variables de entorno cifradas de clientes y, en algunos casos, descifrarlas. Así que han obtenidos claves como API keys y credenciales. Recomiendan rotarlas ya y revisar logs, ademas mientras investigan, han pausados los despliegues.

🚨 Si tienes un servidor con PHP, actualízalo hoy. Ya salió el parche y ya hay ataques reportados. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Todo lo anterior a esas versiones está afectado. Ayer habia mucha especulacion pero ahora sí es oficial: son 2 fallos en el núcleo de PHP (CVE-2026-109618 y CVE-2026-109619), conocidos como PHP2Shell, con gravedad 9.2 de 10, que permiten a un atacante ejecutar código de forma remota en servidores web sin iniciar sesión. Ambos son errores de memoria, en simple: PHP a veces no limpia bien la memoria entre una petición y otra, y un atacante puede aprovechar esos restos para meter su propio código. Y esto afecta a toda instalación de PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Los más expuestos son los que usan mod_php. Los ataques ya lo estan reportan empresas de seguridad: watchTowr detectó explotación real en su red de honeypots, Cloudflare dice que los ataques empezaron y Patchstack confirmó varios incidentes. PHP todavía no lo ha confirmado y CISA aún no los agregó a su catálogo de vulnerabilidades explotadas. Asi que si estás en versiones viejas: PHP ya no da soporte a 8.1 y anteriores, pero por la gravedad publicó parches mínimos para 7.4, 8.0 y 8.1, pensados para quien compila desde el código fuente. Las distros y proveedores con soporte largo recibieron los parches antes de la publicación, así que si tu PHP viene de Ubuntu, Debian o RHEL, revisa sus paquetes. Si estás en algo más viejo y sin proveedor, toca migrar. Lo que tienes que hacer hoy: ☑️ Actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 ☑️ Reinicia PHP-FPM o Apache para que todos los procesos usen la versión nueva ☑️ Si usas Docker, reconstruye tus imágenes ☑️ En Debian/Ubuntu, confirma con apt changelog: php -v puede mostrar el número viejo aunque ya esté parchado ☑️ Si usas el repositorio de Remi, hoy no tendrá actualizaciones: cambia a los paquetes de tu distro o compila PHP desde el código fuente ☑️ Si no puedes actualizar ya: pon session.upload_progress.enabled=0 y reinicia todos los procesos. Eso bloquea el ataque demostrado por esa vía, pero no los demás caminos. Actualizar es la única protección confiable. ☑️ Si estás detrás de Cloudflare, ya hay reglas de firewall contra los vectores conocidos, disponibles para todos los clientes, incluso el plan gratis. Ayuda, pero no reemplaza el parche. WordPress, Laravel, WooCommerce, Magento… todo corre sobre PHP. El fallo está debajo de todos ellos: no se arregla actualizando plugins ni tu código, sino la versión de PHP del servidor.

Antes, saltar de una tarea a otra (el famoso context switching) era el enemigo del foco. Hoy, con agentes y tanta orquestación, es la descripción del puesto.

Tu agente instaló Vite, Vitest, ESLint, Prettier… y probablemente no sabes qué hace cada uno, pero ahora todo eso puede ser una sola herramienta. Se llama Vite+ y es de los mismos creadores de Vite: un solo comando (vp) que reúne todo lo que necesitas para tu proyecto web. ✅ Funciona con cualquier framework que use Vite: React, Vue, Svelte, Solid y más de 20 otros ✅ Dev y build con Vite y Rolldown, un bundler escrito en Rust ✅ Tests con Vitest, ya integrado ✅ Lint con Oxlint (Rust), entre 50 y 100 veces más rápido que Eslint ✅ Formato con Oxfmt (Rust), hasta 30 veces más rápido que Prettier ✅ Empaquetado de librerías con tsdown ✅ Tareas del proyecto con Vite Task ✅ También maneja tu runtime y tu gestor de paquetes ✅ Una sola config en vite.config.ts ✅ Gratis y open source (MIT) ¿Cómo migras? Con un solo comando: vp migrate viteplus.dev

Esta semana OpenCode sufrió un ataque de destilación muy importante que afectó a usuarios de Console que tenían vinculadas claves de OpenAI, Anthropic y Google. Es decir, los atacantes usaron esas claves para quemar créditos y a varios les llegaron facturas de cientos o miles de dólares sin que ellos hubieran hecho nada. Pero lo más interesante de todo esto es que Dax, cofundador de OpenCode, contó que llevaban 48 horas seguidas intentando atacar sus sistemas sin parar. Los atacantes usan agentes que no duermen, así que ellos también necesitan agentes para poder defenderse 24/7. Además, como dato interesante, cuando intentaron investigar el incidente con modelos de frontera, estos se negaron a ayudar porque se activaban sus restricciones de seguridad. O sea, tampoco servían para defenderse. Después consiguieron acceso a Daybreak Blue, un modelo de OpenAI con menos restricciones para seguridad defensiva, y ahí pudieron avanzar mucho mejor. Creo que esto es de esas cosas que van a pasar cada vez más seguido. Los atacantes pueden tirar agentes automatizados las 24 horas sin ningún problema ético ni restricción de seguridad, y el defensor tiene que pelear no solo contra el ataque, sino también contra las limitaciones de los modelos que usa para defenderse. El escenario de ciberseguridad con agentes ya no es teórico.

Primero escribieron TypeScript en TypeScript. 
Después lo reescribieron en Go “para que fuera más rápido”. 
Luego alguien lo portó a Rust con IA (porque había tokens de sobra). 
Y ahora lo volvieron a escribir en TypeScript… y dicen que es más rápido que el de Go. Están dando vueltas en círculos. Ya los desarrolladores no saben qué hacer con sus tokens.

Cuando le dejas al desarrollador que haga el marketing:

Un programador (Cheng Lou, que trabajó en React) acaba de hacer algo rarísimo: convertir un programa normal en una inteligencia artificial… sin entrenarla. Para entenderlo: • Un programa normal sigue reglas fijas: "si pasa esto, haz aquello". • Una IA es un montón gigante de números que aprende a partir de ejemplos. Su herramienta, Handwired, traduce esas reglas directamente a números. No hay entrenamiento: los números salen del propio código, y el resultado hace exactamente lo mismo que el programa original. ¿Lo interesante? Como ahora está en "formato IA", después puedes seguir enseñándole cosas como a cualquier IA. El código y la IA dejan de ser dos mundos separados. Su demo: un mini escritorio con ventanas, scroll y arrastrar, que por dentro funciona entero como una red neuronal. Es un experimento, no algo para usar mañana, pero es una pista interesante de hacia dónde puede ir el software. chenglou.me/handwired

Los mismos que clonaron con IA la suite de Adobe y Microsoft Office ahora van por otros programas populares: ya tienen su versión de AutoCAD y la más reciente es la de Figma. Ya son 13 apps, todas open source y escritas en Rust. Eso sí, no sirven para un trabajo real aun, pero quizás algún día lo hagan. getartcraft.com/apps

Lovable, Replit, v0 o Base44 son el no-code de esta época. Pasó lo mismo con Wix o WordPress en su momento. Pero hoy, si al menos sabes instalar un programa, crear tu propia app con Claude Code o Codex te da más control y no dependes de ninguna plataforma. Aun así, mucha gente prefiere la simplicidad de tenerlo todo en un solo lugar, y no tiene nada de malo. No es una estafa, es pagar por comodidad.

Si le pides a la IA que te cree un skill, te va a dar un archivo enorme que no vas a poder mantener. Estos son 7 consejos para crear los tuyos: 1. Hazlos simples. Pídele que lo reduzca a los pasos que le pediste, sin explicar lo obvio, y asegúrate de entenderlo. 2. Un skill para cada cosa. Mejor varios pequeños que uno que lo hace todo. Para el flujo completo, crea otro skill que los orqueste. 3. Automatiza lo que repites. Enséñale tus pasos uno a uno y al final pídele que los guarde como skill. 4. Dales herramientas. FFmpeg, yt-dlp o un MCP le permiten hacer lo que por sí solo no puede. Eso sí, con permisos controlados. 5. Incluye plantillas. Guárdalas en la carpeta assets/ y el resultado saldrá igual cada vez. 6. Ponles límites. Escribe lo que no debe hacer: "nunca hagas push a main". 7. Versiónalos. Guárdalos en tus dotfiles con Git y mejóralos con el uso: cuando fallen, corrige solo esa parte. Un skill es solo una carpeta con un archivo Markdown y funciona en Claude Code, Codex, Cursor, Gemini CLI y más. ¿Qué tarea de tu día a día convertirías en un skill?