1109 | Burbuja de IA, píxeles al límite y coches hackeados

Clara Vega: Bienvenidos de nuevo a Hackers en Debate, el programa donde recorremos lo que más se está discutiendo hoy. Soy Clara Vega.

Mateo Ruiz: Y yo Mateo Ruiz. Y hoy hay un hilo que conecta casi todo lo que vamos a contar: la pregunta de qué está construyendo la industria de verdad y qué está inflando. Empezamos por la gran discusión del día, que es literalmente si existe o no la burbuja de la IA.

Clara Vega: Sí, y este post es interesante porque el autor va contra la narrativa dominante con números concretos. Su argumento es doble. Primero, ese gasto gigantesco que todos citan, alrededor de cinco billones de dólares, no es gasto recurrente: es capex único de centros de datos. Una vez construido el edificio, la inversión no se repite cada año al mismo ritmo.

Mateo Ruiz: Y segundo, y esto es lo que generó más debate en los comentarios: según el autor, Anthropic genera dos dólares y ocho centavos por cada dólar de cómputo. O sea, margen real. No es la típica startup quemando dinero a pérdida para conquistar mercado.

Clara Vega: Los comentaristas se dividieron bastante. Los que apoyan la tesis dicen que la definición clásica de burbuja es pagar precios por encima del valor fundamental, y si hay márgenes así, no hay burbuja en el sentido técnico. La sobreinversión en infraestructura, dicen, se corrige sola: alguien se queda con centros de datos baratos y la capacidad se usa después, como pasó con las fibra oscura de los noventa.

Mateo Ruiz: Y ¿los escépticos?

Clara Vega: Los escépticos atacan justo el punto más débil del argumento, que es la sostenibilidad de esos márgenes. El número de Anthropic mide el margen actual sobre el cómputo, no dice nada sobre si la demanda de inferencia seguirá creciendo a precios capaces de sostenerlo. Varios comentarios señalan que si el coste de inferencia sigue bajando, o si la demanda se aplana, ese margen de dos a uno se erosiona rápido.

Clara Vega: Es la pregunta que queda abierta en la discusión: ¿la demanda de inferencia sostiene esos números, o estamos midiendo un pico?

Mateo Ruiz: Y hay un dato del hilo que los escépticos usan como pista de hacia dónde va la eficiencia. Alguien compartió un proyecto llamado llama-modchip, que logra ejecutar DeepSeek-V4-Flash, un modelo de doscientos ochenta y cuatro mil millones de parámetros, en una máquina con sesenta y cuatro gigas de RAM, solo CPU, con contexto de doscientas cincuenta y seis mil tokens. Nada de GPU.

Clara Vega: Suena mágico, y ahí está la trampa que señalaron los comentaristas escépticos: lo más probable es que el modelo esté corriendo con cuantización extrema, en el rango de uno o dos bits por peso. Con eso pierdes mucha calidad de razonamiento, y algunos dijeron que el benchmark no significa lo que parece a primera vista.

Clara Vega: Pero otros replicaban que eso es exactamente el punto: la ingeniería está bajando el coste de ejecutar modelos grandes tan rápido que cualquier presupuesto de ingresos calculado hoy puede quedar obsoleto mañana.

Mateo Ruiz: O sea, el dato se puede leer en las dos direcciones, y la discusión lo deja claro: es evidencia de eficiencia y a la vez evidencia de que los márgenes pueden comprimirse.

Clara Vega: Exacto. Y encima del debate financiero, el hilo recogió un par de señales del lado de la industria que dan contexto de que no todo es tranquilo ahí dentro. Jensen Huang pidió disculpas al personal de Nvidia por un affair, y la junta directiva inició una investigación independiente con preocupaciones de seguridad nacional de por medio.

Mateo Ruiz: Que es un tipo de noticia que en otra época sería una cosa de prensa rosa, pero en una empresa que vende literalmente la infraestructura de la industria, la junta tratando eso como asunto de seguridad nacional dice algo del nivel de sensibilidad del sector.

Clara Vega: Y hay otra señal más cínica. Goldman Sachs restringió el acceso a Claude Code solo para sus ingenieros, cortando a traders y banqueros, semanas antes de suscribir la salida a bolsa de Anthropic. Varias personas comentaron que el momento no puede ser casualidad: gestionas el riesgo reputacional antes de poner tu firma en el folleto de la IPO.

Mateo Ruiz: Es gracioso porque esa restricción también puede leerse como señal de demanda: si los banqueros lo estaban usando, es que funciona. O como señal de miedo legal. Los comentarios no se pusieron de acuerdo, y tampoco debería sorprendernos.

Clara Vega: Bueno, pasemos del dinero a la práctica, porque hay otro hilo de hoy que responde casi directamente a la pregunta: si de verdad vamos a trabajar con estas cosas todos los días, ¿cómo se hace sin perder la cabeza?

Mateo Ruiz: Este es el hilo de lo que el autor llama el cerebro frito. Su experiencia es la que describen muchos: cada vez que vuelves a una sesión con agentes, tienes que reconstruir todo el contexto mental, y entre eso y la cantidad de cosas simultáneas, terminas agotado y tomando peores decisiones.

Clara Vega: Su solución es deliberadamente baja tecnología: una cola de prioridades basada en git. Las tareas viven como fichas en un repositorio, y la regla es una decisión a la vez. No miras diez hilos de agentes abiertos; sacas el siguiente elemento de la cola, lo resuelves, y ya.

Mateo Ruiz: Y la segunda regla, que para muchos comentaristas fue la más importante: los agentes nunca despliegan a producción. Nunca. El humano revisa, aprueba y despliega. Los comentarios con experiencia firsthand coincidieron mayormente ahí; varios contaron episodios donde un agente hizo cambios que en apariencia eran correctos y en producción rompían cosas sutiles.

Mateo Ruiz: La lección que sacaron es que el agente puede generar y puede proponer, pero la frontera entre entorno de desarrollo y producción tiene que seguir siendo humana.

Clara Vega: Hubo cierto debate sobre el tamaño de la cola, eso sí. Algunos decían que la cola de git funciona bien porque te obliga a externalizar el estado mental, y otros replicaban que en equipos grandes una cola individual se rompe: pierde el contexto compartido, y lo que queda pendiente es cómo escala esto más allá del desarrollador solo. Eso sigue sin resolverse en el hilo.

Mateo Ruiz: Y hay una pieza conceptual en la discusión que eleva el hilo por encima de trucos de productividad. Otro autor aporta la idea de la escritura como herramienta de pensamiento. Su frase es memorable: sin papel, eres un autómata finito. Sin escribir, tu capacidad de razonar está limitada por lo que cabe en tu cabeza de una vez.

Clara Vega: Y de ahí saca una conclusión que a los comentaristas les pareció incómoda y correcta a la vez: los LLM no pueden hacer tu pensamiento por ti. Pueden redactar, pueden borrar, pueden acelerar la expresión, pero el trabajo de decidir qué se quiere decir es tuyo. Y si la escritura es ventaja comparativa en la era de los modelos que escriben, entonces delegarla entera es renunciar a la única parte que sigue siendo tuya.

Mateo Ruiz: Encaja muy bien con el hilo del git: la cola de prioridades es, en el fondo, escribir. Estás convirtiendo decisiones difusas en texto con orden. Los dos autores están diciendo lo mismo desde ángulos distintos: no confíes la parte difícil a la máquina.

Clara Vega: Y eso nos lleva de cabeza al siguiente tema, porque si hablamos de herramientas que amplifican el pensamiento en vez de sustituirlo, hay alguien que lleva años haciendo esa defensa en otro terreno: Paul Ford y el navegador.

Mateo Ruiz: Ford sostiene que el navegador es la plataforma de aplicaciones más potente y más barata que existe hoy. Su ejemplo personal: tiene aplicaciones alojadas en CloudFlare y le cuesta cero dólares. Y los tres pilares maduraron: Wasm para cómputo serio, WebGL para gráficos, WebCrypto para seguridad. Argumenta que ninguna otra plataforma te da esa distribución, ese coste y ese alcance a la vez.

Clara Vega: Los comentarios mayormente asentían, pero la discusión interesante fue sobre los contraejemplos, porque claro, decir el navegador está maduro es fácil; demostrarlo con software serio es otra cosa.

Mateo Ruiz: Y ahí entra Chimera, que fue compartida en el hilo y es una demostración espectacular. Es un sintetizador de voz construido completamente en el navegador, con modelado físico: cada sonido que produces en la interfaz proviene de una vía aérea simulada, incluida la nariz. A quien conozca Pink Trombone le va a sonar inmediatamente familiar: es ese linaje de instrumentos donde puedes pellizcar, literalmente, la garganta virtual.

Clara Vega: Y es el mejor argumento posible a favor de la tesis de Ford, porque un sintetizador de voz por modelado físico es exactamente el tipo de software que hace una década era imposible de imaginar corriendo en una página web sin instalación.

Mateo Ruiz: Pero los contraejemplos son reveladores. Uno es KetchUp, una alternativa libre y de código abierto a SketchUp, escrita en Rust con WebGPU, orientada a carpintería. Es gratis, es técnicamente ambiciosa, y los comentarios la celebran. Pero también señalan pegas de UX que duelen, y mi favorita: tienes que nombrar los rectángulos.

Clara Vega: Sí, el detalle de que para trabajar con ciertas geometrías el usuario tiene que bautizar cada rectángulo con un nombre. Es un ejemplo perfecto de la diferencia entre hacer que la tecnología funcione y hacer que el software funcione para un humano. SketchUp gana precisamente en esa capa, no en la renderización.

Mateo Ruiz: Y el otro contraejemplo es de mercado, no técnico: Harvest. Después de que Bending Spoons comprara la empresa, el precio de suscripción pasó de trece dólares al mes a ciento treinta y cuatro. El autor del post sobre Harvest dice que era software sencillo, fiable, de pequeño negocio, y de repente el precio se multiplica por diez.

Clara Vega: Y ahí la conexión con Ford se hace automática: cuando la plataforma es abierta y barata, tu proveedor no te puede cobrar esa renta, porque la alternativa de escribir tu propio software tiene un coste de entrada razonable. El caso de Harvest es el argumento económico para la tesis de Ford, más allá de lo técnica.

Mateo Ruiz: Bueno, pero ahora seamos justos con el otro lado. Todo lo que hemos dicho del navegador asume que las abstracciones web son suficientemente rápidas. Cuando sales de ahí y bajas al escritorio nativo, la situación es mucho menos resuelta de lo que parece. Hay un post técnico de hoy que documenta eso.

Clara Vega: El contexto: hay un interés real en la comunidad Rust por construir interfaces de escritorio propias, fuera del navegador. GPUI, el framework de Zed, y egui son dos de los proyectos más visibles. Y el autor del post los ha probado para una aplicación compleja, y su conclusión es dura: son callejones sin salida para apps de escritorio complejas.

Mateo Ruiz: Con un benchmark para respaldarlo: ocho coma cuatro milisegundos por cada cambio disperso en una tabla de tres mil filas. Para quien no está en el tema: un cambio disperso es cuando modificas pocas celdas repartidas por la tabla, no un cambio en bloque. Y que eso tarde ocho milisegundos significa que cada interacción pequeña te come gran parte del presupuesto de un frame de sesenta hercios.

Clara Vega: Los comentaristas entraron con matices, y fue una discusión técnica de las buenas. Unos defienden que el problema no es el framework sino el modelo de datos de la aplicación, y que si estructuras bien el estado, el coste baja. Otros replican que ahí está justamente la trampa: te obligan a construir tu propia capa de gestión de estado encima, con lo cual el framework deja de resolver el problema que decía resolver.

Mateo Ruiz: Y el post aporta el contrapunto perfecto desde el otro extremo del espectro. Raph Levien, que es una de las personas más serias en gráficos por software, está compilando renderizado de glifos bitmap a código ARM, a medida, para el renderizador race-the-beam del RP2350, que es un microcontrolador.

Clara Vega: Race-the-beam significa que el chip no tiene buffer de imagen: cuando el haz recorre la pantalla, el software tiene que calcular el color de ese pixel en ese momento exacto. El presupuesto es de unos seis ciclos por pixel. Seis. Por comparar, el benchmark de GPUI gastaba miles de veces eso en actualizar una celda de tabla.

Mateo Ruiz: Y la lectura que hizo la discusión es que el espectro completo, de egui con su modelo de estado a Levien jiteando glifos para seis ciclos, muestra que no existe todavía un modelo de estado de UI que escale bien de apps complejas de escritorio hacia abajo. En el microcontrolador sabes exactamente qué tienes que hacer, porque el hardware manda. En el escritorio, el problema sigue abierto: si surgirá un modelo que resuelva esto es la pregunta que queda en el aire.

Clara Vega: Y KetchUp volvió a aparecer en este hilo, esta vez como ilustración del coste de construir una herramienta CAD completa en Rust con WebGPU. Cada pieza técnica funciona; el conjunto es lo caro.

Mateo Ruiz: Bueno, y mientras unos discuten frameworks y presupuestos de ciclos, hay otro rincón de la comunidad que sigue construyendo a su ritmo, con otra escala temporal completamente distinta. El hilo Ask HN de noviembre de 2026, preguntando qué está haciendo la gente, sacó un puñado de proyectos larguísimos.

Clara Vega: El que más impresionó en los comentarios es Bonsai, un motor de voxels que lleva diez años de desarrollo. Diez. Un solo proyecto, mantenido todo ese tiempo. Después apareció Orpheum, un servidor multimedia autohospedado, para la gente que quiere su propia biblioteca sin depender de servicios de terceros. Y OneBusAway, software de transporte público que lleva años en producción real moviendo datos de buses.

Mateo Ruiz: Lo que muchos comentaristas señalaron es el patrón común: estos proyectos no responden a una ronda de inversión ni a una ventana de mercado. Responden a la dedicación de una persona o de un grupo pequeño durante años. Es software sostenido por interés, no por capital.

Clara Vega: Y en escritorio Linux, la misma filosofía con otra cara: Dux, un shell de escritorio para Wayland, libre y de código abierto, construido sobre Quickshell y QML. Incluye gestor de archivos, sistema de temas, y funciona con los compositores populares: niri, Hyprland y Sway.

Mateo Ruiz: La discusión ahí fue más práctica: gente preguntando si es estable para uso diario, cómo se compara con shells existentes, qué tan fácil es de personalizar con QML si no conoces el lenguaje. Es el tipo de proyecto que crece despacio y necesita esa clase de preguntas para madurar.

Clara Vega: Y la pregunta que quedó al final del hilo, y que me parece la más honesta de todas: ¿cuánto de esto sobrevive? Diez años en un motor de voxels es una promesa de longevidad, pero también un costo personal enorme, y no hay garantía de que la próxima década lo mantenga. Nadie sabe la respuesta.

Mateo Ruiz: Y de la construcción desinteresada pasamos, con transición un tanto amarga, a lo que pasa cuando el software que se construye rápido sin revisar supuestos toca infraestructura crítica. Dos historias de seguridad de hoy, ambas del mismo patrón.

Clara Vega: La primera es de las que te dejan helado. Investigadores lograron desbloquear cualquier coche de un gran fabricante en todo el mundo. No un modelo, no una región: cualquier coche del fabricante, a distancia.

Mateo Ruiz: ¿Y cómo lo hicieron?

Clara Vega: No explotaron un fallo en un endpoint aislado. La cadena era estructural: por un lado, herramientas de administración con APIs sin autenticación, o sea, interfaces pensadas para uso interno que cualquiera podía alcanzar. Y por otro, una cadena de confianza en la plataforma de identidad que permitía suplantar la autoridad correcta. El fallo estaba en el diseño del sistema, no en una línea de código concreta.

Mateo Ruiz: Los comentarios de seguridad insistieron en esa distinción, y con razón. Cuando el problema es de diseño, parchear el endpoint concreto no soluciona nada; cualquier otra herramienta de administración con el mismo supuesto vuelve a ser vulnerable. La pregunta que quedó abierta en la discusión es qué obligaciones regulatorias o de divulgación se imponen en casos así. Por ahora, nadie lo sabe.

Clara Vega: Y la segunda historia es de otro tipo de infraestructura crítica, el correo, y de un cambio que llegó sin aviso. Desde el cinco de noviembre de 2026, Outlook.com está rechazando correo de dominios sin DMARC. Sin anuncio previo, sin campaña de notificación. Si envías desde un dominio sin DMARC, parte de tu correo simplemente desaparece para los destinatarios de Outlook.

Mateo Ruiz: La solución, eso sí, es trivial: un registro TXT en tu DNS. Diez minutos de trabajo. El problema no es técnico, es de información: muchísimos remitentes legítimos todavía no saben que les está pasando, y descubren el fallo porque alguien les dice que su correo no llegó.

Clara Vega: Los comentaristas discutieron si Microsoft tiene obligación de avisar mejor, y hubo de todo: los que dicen que DMARC lleva años recomendado y que es hora de que la gente lo configure, y los que replican que rechazar correo silenciosamente castiga sobre todo a los pequeños remitentes, justo los que menos siguen los cambios de política de los grandes proveedores.

Mateo Ruiz: Y fíjate cómo cierra el círculo del programa: el coche y el correo, igual que la cola de git y la investigación de la junta de Nvidia, son historias de supuestos que nadie verificó. El automaker asumió que sus APIs internas estaban aisladas; los remitentes asumieron que su correo llegaría; los optimistas de la IA asumen que los márgenes de hoy son los de mañana.

Clara Vega: Eso es todo por hoy. Gracias por acompañarnos, soy Clara Vega.

Mateo Ruiz: Y yo Mateo Ruiz. Nos vemos mañana con más de lo que la comunidad está discutiendo.