1019 | Código, micrones y algoritmos: la semana en tecnología

Clara Vega: ¡Hola y bienvenidos! Yo soy Clara Vega.

Mateo Ruiz: Y yo Mateo Ruiz, y sí, bienvenidos a este recorrido por las conversaciones más sustanciosas de las últimas veinticuatro horas. Hay de todo hoy, pero si tuviera que decirte un hilo que lo conecta todo, sería este: quién razona, quién decide y quién paga la factura cuando el software y las plataformas envejecen.

Clara Vega: Sí, porque hoy vamos a hablar de agentes que razonan y gastan menos, del canon de las matemáticas en manos de los LLM, del código que no entendemos, de ingeniería inversa del Intel 8087, de APIs que se rompen, de hardware abierto a escala micrométrica, de Meta y Cloudflare, de dominios incautados, de asociaciones de propietarios en Florida y hasta de la línea temporal de Zelda.

Mateo Ruiz: Es decir, un día normal en internet. Empecemos por lo que más se está discutiendo: los agentes de IA y cómo razonan.

Clara Vega: Vamos allá. La historia principal es HybridAgent, un trabajo que mezcla dos formas de razonar en agentes: razonamiento latente y razonamiento textual.

Mateo Ruiz: Explico la distinción porque importa. El razonamiento textual es el de siempre: el modelo escribe su cadena de pensamiento en tokens, lo lees, consumes ancho de banda de contexto y también es la parte visible. El razonamiento latente es distinto: el modelo piensa dentro de sus representaciones internas, sin traducir cada paso a texto.

Clara Vega: Y la apuesta de HybridAgent es que no hace falta elegir uno solo: se combinan según lo que pida la tarea. Los resultados son llamativos: un aumento del diez coma cuatro por ciento en rendimiento, entre un treinta y cinco y un cincuenta y cinco por ciento menos de tokens, y una inferencia entre uno coma ocho y dos coma seis veces más rápida frente a agentes de frontera.

Mateo Ruiz: Y fíjate en qué dirección se mueve la discusión alrededor de esto. Nadie está cuestionando tanto el número en sí como lo que significa: si puedes razonar igual o mejor con la mitad de tokens y el doble de velocidad, has abaratado el razonamiento. Y abaratar el razonamiento cambia qué tareas salen a cuenta automatizar.

Clara Vega: Hay también una pregunta económica de fondo en los comentarios: los agentes de frontera son caros precisamente porque escriben mucho. Cada paso de un plan, cada verificación, cada reintento son tokens. Si parte de ese pensamiento se puede mover al espacio latente, el costo por tarea cae de forma no lineal, no solo un poco.

Mateo Ruiz: Pero ojo, porque hay escepticismo legítimo también. Algunos señalan que el razonamiento latente es opaco: cuando el agente piensa en texto, al menos puedes auditar el proceso, ver dónde se equivocó. Si piensa dentro de sus vectores, pierdes esa visibilidad. Para depurar agentes, eso es una pérdida real.

Clara Vega: Y la pregunta que queda abierta, y que a mí me parece la más interesante, es si esta mezcla latente/texto escala a dominios difíciles. Porque los benchmarks donde se ha medido no son, digamos, matemáticas de nivel investigación.

Mateo Ruiz: Y ahí es donde enlaza la segunda historia grande, que es casi una respuesta a esa pregunta. Terence Tao, uno de los mejores matemáticos vivos, publicó en su blog un artículo invitado que plantea una dicotomía inquietante sobre los LLM y las matemáticas.

Clara Vega: La dicotomía es esta: si los LLM acaban siendo capaces de hacer matemáticas de forma independiente, podríamos entrar en una edad de oro de la disciplina, con más teoremas, más verificación, más descubrimiento. Pero si no son independientes, si son herramientas que producen conocimiento que nadie entiende del todo, podríamos entrar en una era oscura: conocimiento que existe, que está escrito, pero que es ajeno a los humanos.

Mateo Ruiz: Esa segunda rama es la que más ha dado que hablar. Porque no es el escenario de ciencia ficción de la máquina que nos supera y ya está; es algo más sutil: un acopio de resultados generados, quizá correctos, quizá no, que nadie ha verificado humanamente. ¿De qué sirve un teorema que nadie puede asumir como propio?

Clara Vega: Y la conexión con HybridAgent es directa, ¿verdad? Si las máquinas razonan cada vez más dentro de representaciones que no leemos, ese escenario de "conocimiento ajeno" deja de ser una fantasía lejana. Es la misma dirección: pensar sin texto.

Mateo Ruiz: Aunque también hay quien en la discusión enlaza con la rama optimista: si el razonamiento se abarata, más personas pueden tener un asistente que verifica, que explora casos, que comprueba corolarios. La edad de oro y la era oscura podrían ser la misma tecnología según cómo se gestione la verificación humana.

Clara Vega: Y creo que ahí es donde la discusión sigue sin resolverse. Nadie sabe cuál de las dos ramas se va a dar, ni siquiera si son excluyentes. Lo que sí comparten casi todos los participantes es que el momento de decidir cómo vamos a verificar es ahora, no cuando ya haya montañas de resultados autogenerados.

Mateo Ruiz: Y justamente de verificación humana vamos a pasar a otra historia que lo toca de frente: el código que escribes con IA, ¿lo entiendes de verdad?

Clara Vega: Hablemos de Sphinx. Es un hook de Git, gratuito y de código abierto, con una idea muy simple y muy picante: antes de dejarte subir código escrito por IA, te hace un examen.

Mateo Ruiz: Literalmente un examen. El hook intercepta tu push, genera preguntas sobre el código que intentas subir y si no respondes bien, no pasa. Y el detalle técnico que mencionan: funciona gastando muy pocos tokens.

Clara Vega: Las reacciones alrededor de esto están divididas de una forma muy interesante. Un grupo lo celebra como una herramienta de criterio: en un mundo donde el autocompletado genera funciones enteras, el examen te obliga a mantener el entendimiento. Es decir, devolver el criterio humano al flujo de trabajo.

Mateo Ruiz: El otro grupo ve fricción pura. Argumentan que en un equipo con presión de plazos, un examen por cada push es lo que hace que la gente desactive el hook a la semana. Y hay una objeción más fina: ¿qué demuestra responder preguntas sobre el código? Puedes responder bien y aun así no entender el diseño, por qué se eligió una aproximación y no otra.

Clara Vega: Y quien defiende la herramienta responde a eso: el examen no es una certificación, es uncheckpoint. Te frena justo en el momento en que copiarías sin leer. Que te f once segundos por push ya cambia el comportamiento.

Mateo Ruiz: Y Sphinx enlaza con la otra historia de este bloque, que es más filosófica. Karri Saarinen, cofundador de Linear, advirtió sobre algo que llama la pérdida del alma de los productos.

Clara Vega: Su argumento: cuando aparecen las fábricas de software dirigidas por agentes, capaces de añadir funciones sin parar, los productos empiezan a acumular capacidades sin un punto de vista unificado. Y un producto sin punto de vista es una lista de funciones, no un producto.

Mateo Ruiz: Lo que más se ha discutido ahí es si esto es culpa de los agentes o de siempre. Hay quien dice: esto pasaba antes también, equipos grandes añadiendo cosas por miedo a quedarse atrás. Los agentes solo aceleran el proceso a velocidad industrial.

Clara Vega: Pero la réplica es que los agentes cambian la naturaleza del problema: antes, la fricción de diseñar e implementar era un freno natural que obligaba a priorizar. Si ese freno desaparece porque añadir una función cuesta casi nada, lo único que protege la coherencia del producto es una voluntad explícita de decir que no. Y decir que no no se automatiza fácil.

Mateo Ruiz: Y uniendo las dos historias del bloque: Sphinx ataca exactamente ese problema desde el lado del desarrollador. Saarinen lo ataca desde el lado del producto. Los dos dicen lo mismo en el fondo: sin criterio humano activo, la generación automática produce acumulación, no construcción.

Clara Vega: Y la pregunta abierta es si estas prácticas se adoptan de forma generalizada. Un hook de examen es genial para quien ya quiere ser cuidadoso. ¿Sirve para quien no? Esa discusión sigue.

Mateo Ruiz: Bueno, y si estamos hablando de entender el código, también hay que entender el lenguaje y las herramientas. Que nos lleva a un bloque de puro deleite técnico: la ingeniería inversa del Intel 8087.

Clara Vega: Esto me encanta. Ken Shirriff, que es una referencia en esto, hizo ingeniería inversa del microcódigo del coprocesador matemático Intel 8087 para explicar cómo suma y resta en coma flotante.

Mateo Ruiz: Contexto para quien no lo conozca: el 8087 era el coprocesador que añadía operaciones de coma flotante a los PC originales, y Shirriff logró extraer y descifrar su microcódigo completo: mil seiscientas cuarenta y ocho microinstrucciones.

Clara Vega: Mil seiscientas cuarenta y ocho. Y con eso puede contar exactamente, paso a paso, cómo una máquina de finales de los setenta decide cómo alinear exponentes, cómo manejar casos especiales, cómo hace la resta.

Mateo Ruiz: La reacción mayoritaria es de pura admiración: es arqueología computacional de primera. Pero también hay una lectura de fondo que me gusta: ese microcódigo es comprensible. Alguien con paciencia puede sentarse y entenderlo por completo, instrucción por instrucción. Es lo contrario del razonamiento latente del que hablábamos al principio.

Clara Vega: Exacto, es la tesis opuesta: mil seiscientas cuarenta y ocho instrucciones que cualquier persona motivada puede llegar a dominar frente a millones de parámetros que nadie puede inspeccionar. Y quien ha comentado el trabajo de Shirriff lo señala: la comprensión profunda sigue siendo posible y sigue importando.

Mateo Ruiz: Y frente a ese arte histórico, la otra historia del bloque es la de un herramienta que lleva veinte años madurando: Free Pascal y Lazarus acaban de estrenar soporte completo de paquetes dinámicos.

Clara Vega: Tras veinte años. Y qué significa: hasta ahora, instalar un componente en el IDE de Lazarus obligaba a recompilar el IDE entero. Con los paquetes dinámicos, los componentes se instalan en segundos, sin recompilar.

Mateo Ruiz: La discusión ahí mezcla nostalgia y respeto. Hay quienes recuerdan que Pascal era su lenguaje de entrada a la programación y se alegran de que el proyecto siga vivo. Y hay quienes señalan lo más relevante: veinte años de mantenimiento continuado, y de pronto una mejora de experiencia de desarrollo que muchos IDEs modernos dan por sentada.

Clara Vega: Es la lección del bloque: la comprensión profunda y el mantenimiento a largo plazo siguen importando. Shirriff descifrando un chip de los setenta, y un equipo Pascal añadiendo paquetes dinámicos en el año veinticinco del proyecto. Dos formas de decir que el software y el hardware envejecen según cómo se cuiden.

Mateo Ruiz: Y hablando de envejecer mal, justo el bloque siguiente es sobre eso: APIs y lenguajes que se rompen. Concretamente, un problema silencioso de versionado en Java.

Clara Vega: Sí, y es de esos que te dejan mal cuerpo. Java tiene clases selladas, sealed classes, que le dicen al compilador exactamente qué subtipos pueden existir. Y cuando haces un switch exhaustivo sobre una clase sellada, el compilador garantiza que cubres todos los casos.

Mateo Ruiz: Suena perfecto. ¿Dónde está la trampa?

Clara Vega: La trampa es el versionado. Si alguien añade un subtipo nuevo a la clase sellada y tú no recompilas tu código consumidor, ese switch exhaustivo que era seguro en tiempo de compilación se convierte en una bomba en tiempo de ejecución: falla con una MatchException.

Mateo Ruiz: Es decir, la garantía de exhaustividad cruza la frontera de compilación a compilación, pero en ejecución no hay red. Y lo que más se discute en torno a esto es si es un defecto de diseño o una decisión aceptable.

Clara Vega: Un grupo argumenta que es coherente: la clase sellada es un contrato, y si el contrato cambia, es razonable que los consumidores no actualizados fallen. Al menos fallan de forma visible con una excepción clara, no con un comportamiento silencioso e incorrecto.

Mateo Ruiz: El otro grupo replica que la MatchException en producción es exactamente lo que no quieres: es un error de versionado de librerías convirtiéndose en caída de servicio. Y pregunta que queda sin resolver: ¿debería la ejecución tener una política más suave, algún mecanismo de compatibilidad cuando aparece un subtipo nuevo? Esa discusión sigue abierta.

Clara Vega: Y en la misma familia de "diseño que decide si el software envejece bien", el tutorial de parser combinators. Es una explicación didáctica de una técnica elegante: en vez de luchar con regex para analizar texto, construyes analizadores compuestos.

Mateo Ruiz: La idea central que explica el tutorial: un Parser de T es, literalmente, una función que devuelve dos cosas: el valor parseado y la cadena restante. Con esa pieza tan simple, puedes componer analizadores: combinarlos en secuencia, en alternativa, repetirlos. Cada pieza es comprensible y testeable por separado.

Clara Vega: Y la comparación con regex es la que más ha dado que hablar: regex funciona para casos simples, pero en cuanto el análisis se complica, se convierte en una línea ilegible que nadie se atreve a tocar. Los parser combinators, en cambio, escalan en legibilidad: la complejidad se reparte entre piezas pequeñas.

Mateo Ruiz: Y si lo conectamos con el switch de Java: las dos historias tratan lo mismo desde ángulos opuestos. El diseño de lenguajes y APIs decide si el software envejece bien. Los parser combinators envejecen bien porque cada pieza es local. El switch exhaustivo sin recompilación envejece mal porque la garantía no cruza versiones.

Clara Vega: Y justo de envejecer mal a lo grande: macOS. La actualización quince coma ocho coma dos rompió OpenGL en Mac.

Mateo Ruiz: Contexto breve: Apple lleva años deprecando OpenGL en favor de Metal, y esta actualización aparentemente rompió lo que quedaba. Y en los comentarios, hay un debate en tres frentes.

Clara Vega: Primer frente: los arreglos. Hay quien propone shims de Metal, es decir, capas de traducción que hagan pasar llamadas OpenGL por Metal. Otros hablan de Vulkan vía MoltenVK, que ya es una capa de ese tipo. O sea, la comunidad construyendo puentes sobre una plataforma que no los quiere.

Mateo Ruiz: Segundo frente, y es el más filosófico: ¿debería Apple gastar esfuerzo en arreglarlo? Y aquí la discusión se pone cruda. Hay quien dice que OpenGL en Mac está muerto desde hace años y que mantenerlo es tirar recursos. Otros replican que hay software científico, herramientas y aplicaciones que dependen de OpenGL y que no hay presupuesto para portarlas a Metal.

Clara Vega: Y el tercer frente es el de la deuda técnica en plataforma: cuando el dueño de la plataforma decide retirar una tecnología, el coste no lo paga la plataforma, lo pagan los desarrolladores y usuarios. Es la misma lección del switch de Java: una decisión de diseño en un lado se convierte en ruptura en el otro.

Mateo Ruiz: Y de plataformas que rompen a plataformas que deciden sobre tus datos. Hablemos de Meta y Cloudflare, que encajan perfectamente aquí.

Clara Vega: Empecemos por Meta, porque es reciente. Ha revisado sus términos de uso y ha quitado la palabra "entrenar". Suena a concesión: ya no dicen que van a entrenar con tu contenido.

Mateo Ruiz: Pero ojo, porque según los expertos que han comentado la revisión, la eliminación de esa palabra no reduce el alcance. Los términos siguen permitiendo un rastreo amplio de sitios vinculados a cuentas comerciales, y los cambios entran en vigor el treinta de octubre.

Clara Vega: Y esa es la parte que más ha generado desconfianza: el rastreo de sitios enlazados. Es decir, no solo tu publicación, sino páginas web que de alguna manera están conectadas a tu cuenta de negocio. ¿Qué consentimiento tienen esos sitios? Esa es la pregunta abierta y no hay respuesta clara.

Mateo Ruiz: Y la eliminación de la palabra "entrenar" la lee casi todo el mundo como un cambio cosmético: quitas un término concreto, mantienes el derecho amplio. La sustancia no cambia, solo la etiqueta.

Clara Vega: Y de Meta a Cloudflare, porque la historia del CEO Matthew Prince encaja como contexto histórico de exactamente este fenómeno. En dos mil dieciséis, Prince dio cinco razones por las que Cloudflare ofrecía su nivel gratuito sin límites.

Mateo Ruiz: Las cinco: datos, referidos, contratación, aseguramiento de calidad, y economía de escala del ancho de banda. Vamos una por una, porque es una lección de por qué lo gratis nunca es gratis.

Clara Vega: Datos: los clientes gratuitos generan información sobre amenazas y patrones de tráfico que mejora el producto para todos. Referidos: los usuarios gratis acaban recomendando el servicio, y algunos se convierten en clientes de pago. Contratación: la base de usuarios gratuita es un embudo de talento. Aseguramiento de calidad: con tráfico de todo tipo, detectas problemas antes.

Clara Vega: Y la quinta, la económica: mover tanto ancho de banda te da poder de negociación que abarata el ancho de banda para todo el mundo, incluidos los clientes de pago.

Mateo Ruiz: Y lo interesante de releer esto hoy, en el contexto de Meta: es la misma moneda, el intercambio en especie. Cloudflare lo decía abiertamente hace casi una década, Meta lo ejecuta con términos legales. Y en ambos casos, la pregunta es la misma: ¿qué consentimiento real hay detrás?

Clara Vega: Y de plataformas que deciden sobre tus datos a plataformas que deciden sobre tu propiedad. Este caso es de los que dejan a la gente inquieta: Namecheap incautó y desactivó los dominios de un cliente.

Mateo Ruiz: Incautó. No suspendió por una reclamación de marca en particular que se conociera, sino que se incautó de los dominios de un cliente, según relata el propio afectado. Y aquí vienen los comentarios, que es lo más valioso de la discusión.

Clara Vega: Varios comentaristas relatan experiencias parecidas: dominios retenidos, en espera, sin proceso claro. Y la recomendación que se repite: migrar a otros registradores como Porkbun, Cloudflare o Internet.bs.

Mateo Ruiz: Pero fíjate en la ironía que señalan algunos: recomendar Cloudflare como registrador "seguro" justo después de que Cloudflare apareciera en la conversación por sus términos de datos. La lección de fondo que casi todos comparten es más incómoda: la propiedad de dominios es frágil, está en manos de un tercero que puede decidir retenérselos.

Clara Vega: Y esa fragilidad enlaza con la otra historia de poder contractual, que es una locura estadística: las asociaciones de propietarios de Florida, las HOA.

Mateo Ruiz: Los números: diez mil doscientas noventa y seis demandas de ejecución hipotecaria contra miembros, cuatrocientas sesenta mil cuatrocientos doce gravámenes, cuarenta y ocho mil novecientos noventa y nueve expedientes judiciales, y seis mil seiscientas sesenta y una asociaciones fuera de vigor.

Clara Vega: Cuatrocientos sesenta mil gravámenes, escúchalo otra vez. Y lo que más discuten quienes comentan esto es la asimetría del poder: la asociación puede poner un gravamen sobre tu casa por una cuota impagada, puede demandarte, y tú estás dentro de un contrato que aceptaste al comprar. Es el poder contractual en la vida cotidiana.

Mateo Ruiz: Y hay quien compara con el caso de los dominios: en ambos, la propiedad parece tuya pero está sujeta a una capa de control que puede activarse contra ti. Un registrador puede retenerte un dominio; una asociación puede gravarte una casa.

Clara Vega: Y con seis mil seiscientas sesenta y una asociaciones fuera de vigor, la pregunta abierta es qué pasa con todas esas estructuras disueltas: sus gravámenes, sus obligaciones, su historial. Esa parte no está clara en la discusión.

Mateo Ruiz: Y justo de poder que define estructuras a poder que define relatos. Cerremos con algo ligero, pero que encaja más de lo que parece: la línea temporal de Zelda.

Clara Vega: Un sitio ha visualizado la cronología oficial de Nintendo de la saga, y lo curioso es que la historia se ramifica en tres eras distintas después de Ocarina of Time. O sea, el canon oficial no es una línea, es un árbol.

Mateo Ruiz: Tres ramas tras Ocarina: y Nintendo lo mantiene como continuidad oficial. Y el dato que ha creado expectación: faltan diecisiete días para el anuncio del remake.

Clara Vega: Y por qué esto encaja con todo lo demás: porque las franquicias también gestionan su propia continuidad y sus expectativas, igual que las plataformas gestionan sus términos y los proyectos de software gestionan sus versiones. Todo es canon, todo es versionado, todo es qué historia cuenta el que tiene el poder.

Mateo Ruiz: Muy bien, cerremos entonces. Hoy hemos visto máquinas que razonan sin texto y matemáticas en la balanza, código que no entendemos y productos que pierden alma, ingeniería inversa y herramientas con veinte años de cuidado, APIs que envejecen mal, precisión de laboratorio en hardware abierto, el precio oculto de lo gratis, dominios y casas sujetas a terceros, y un canon de videojuegos que se ramifica.

Clara Vega: La pregunta con la que nos quedamos: ¿cuánto de lo que producimos vamos a poder seguir entendiendo? Gracias por acompañarnos, yo soy Clara Vega.

Mateo Ruiz: Y yo Mateo Ruiz. Nos oímos mañana.