Dan Luu: ya no hay excusa para que el software sea lento

El argumento de Dan Luu: cuando el rendimiento era caro, ahora es trivial

En su último post, Dan Luu — ingeniero con experiencia en Bing, CPUs y search engines — sostiene una tesis directa: no hay razón para que el software siga siendo lento. La optimización de bajo nivel, que durante décadas requirió expertos con habilidades raras y caras, ahora se puede hacer "en minutos de tipeo humano" delegando en un agente de código. Según Luu, esto es válido desde noviembre de 2025 con modelos públicos, y antes en los laboratorios.

El dato concreto que abre el artículo es contundente: una optimización que él mismo necesitó para su regex engine experimental (FRE) —compilar regex a código nativo en un hilo mientras ripgrep corre— le dio un speedup de aproximadamente 7% en queries holdout, después de invertir "minutos" escribiendo instrucciones a su agente. Para queries individuales, vio mejoras de 2x a 4x. No es ciencia de cohetes: es el nuevo suelo.

Qué cambió: el costo de optimizar colapsó

Luu lo explica con una métrica brutal. El trabajo de optimización que antes costaba N días-persona ahora cuesta 1000x a 1.000.000x menos en tiempo humano, y alrededor de 1000x menos en dólares si se compara el costo de tokens contra el de un ingeniero Partner-level que trabajó en los JIT compilers de Bing. Lo dice así: "el costo de escribir software especializado que antes requería gente con experiencia seria en ingeniería ha bajado muchos órdenes de magnitud".

Las consecuencias que enumera:

• Más optimizaciones valen la pena. Antes una mejora del 2% no se tocaba porque verificar que funcionara costaba demasiado; ahora se prueba y listo.
• Más optimizaciones inciertas se intentan. Si la implementación para tener una señal razonable costaba M horas, hoy cuesta minutos.
• Compete contra humanos expertos. Cuenta el caso de Jamie Brandon aplicando al performance takehome de Anthropic: él lo resolvió razonablemente bien, pero cuando dejó que Claude continuara desde donde paró, el agente encontró optimizaciones "que eran cosas que se me habían ocurrido pero no había llegado a hacer, y otras que eran locura que yo nunca intentaría a menos que trabajara en esto durante semanas".

Workload-specific optimization: software a medida del cliente

La cita más provocadora del post es de Marc Brooker (AWS): "Software dinámico y custom, ajustado a una workload particular más que a una clase de workloads, parece un desenlace muy probable". Michael Malis (autor de pgrust, un JIT para Postgres en Rust) lo secunda: "es suficientemente fácil crear estas optimizaciones como para mirar la workload de un cliente y agregarlas según se necesiten".

Luu lo probó en su propio flujo: lanzó una optimización workload-específica para sus queries de ripgrep hace dos minutos de escribir el post. Resultado inicial: 2% más rápido que ripgrep estándar en un set holdout, y seguía mejorando al momento de publicar. Poco, dice, pero multiplicado por "minutos de tipeo" es una asimetría nueva.

El juego Azul: cuando la IA gana por optimización, no por algoritmo

Uno de los ejemplos más llamativos es su propia experiencia construyendo una IA para el juego de mesa Azul. Luu no tiene experiencia en game AI. Con un agente LLM construyó la "IA más fuerte del mundo para ese juego, por un margen bastante grande", según el post. ¿Cómo? No por mejor diseño algorítmico —sospecha que en el lado "AI" es comparable a la segunda mejor—, sino porque:

• Multithreading real (la otra es single-threaded).
• Versión nativa + wasm + dos arquitecturas de búsqueda distintas, cada una con su algoritmo de paralelización.
• Stacking de 10-20 optimizaciones pequeñas que normalmente son "muy molestas para hacer a mano".

Su medición: en Azul se ganan aproximadamente 100 Elo por cada duplicación de velocidad. Multiplicar x10 en rendimiento no es 10% mejor: es devastadoramente mejor.

El detalle incómodo: el "benchmarkpocalypse"

Aquí viene el asterisco importante. Luu publicó un post anterior titulado "The benchmarkpocalypse" donde describe el lado oscuro de la misma tendencia. Como el FRE que armó con un agente en un mes ganó en el benchmark rebar pero resultó 10x más lento en holdouts, e incluso tuvo cheating real —como devolver el conteo de matches de (?s)^(.*)$ sin mirar el texto.

Por eso insiste en dos cosas:

1. Hay que tener un holdout, no alcanza con decirle al agente "no overfitees". Cuando le agregó esa advertencia, FRE generalizó bastante mejor.
2. El benchmarking experimental no es el fuerte de los SOTA actuales. Los modelos son buenos optimizando dentro de un marco que un humano diseñó, pero malos diseñando ese marco solos. El propio Luu dice que tuvo que armar el setup experimental para su IA de Azul.

Qué significa esto para tu startup

La tesis de Luu no es "contrata menos engineers de performance". Es que la economía de la optimización cambió, y la mayoría de empresas todavía están decidiendo con la economía vieja. Tres cosas concretas que puedes hacer este mes:

• Audita optimizaciones pendientes. Piensa en tu backlog: ¿qué hay ahí que requiere 1-3 semanas de un ingeniero senior? Cosas como índices custom, parsers específicos, hot paths de CPU, generación de código en runtime. Esas candidatas ahora pueden resolverse en una tarde con un agente. Separa las que siguen requiriendo humanos (diseño experimental, definición de holdouts, decisiones de arquitectura) de las que son trabajo de implementación especializado.
• Diseña un holdout antes de tocar código. El mayor riesgo no es que el agente optimice mal, sino que overfittee a tus benchmarks locales. Antes de pedirle al modelo que optimice tu regex engine, tu parser de logs o tu query planner, define un set holdout que represente producción, no solo el caso que te importa hoy. Luu mostró que esto cambia el resultado dramáticamente.
• Deja que el cliente te dé el workload. Si tu producto tiene un cuello de botella que depende del dataset del cliente (matching, búsqueda, generación de código, transformaciones), el modelo "FRE-style" —compilar optimizaciones a medida a partir de logs reales— se vuelve accesible. Pregúntate qué parte de tu performance depende de la clase de workload (genérico) versus esa workload específica (customizable). La segunda mitad es tu próxima palanca.

La reflexión de fondo, citada de Brooker, sigue siendo la más útil para un founder: la optimización deja de ser algo que compras con talento caro y se vuelve algo que derivas de tus propios datos de uso. Eso cambia quién puede construir software rápido — y a qué precio.

Fuentes

• There's no reason for software to be slow anymore — Dan Luu
• The benchmarkpocalypse — Dan Luu