El mito del ‘1000x maker’ de DHH: por qué se equivoca

El keynote que sacudió Rails World 2026

En septiembre de 2026, David Heinemeier Hansson (DHH), creador de Ruby on Rails, subió al escenario de Rails World y soltó una bomba: la próxima versión de Hey, su cliente de correo, no usará Ruby ni Rails en el backend. Será Rust, «agénticamente codificado», según sus palabras. El frontend tampoco será una web app: serán clientes nativos para todos los sistemas operativos relevantes. «Ya no es un problema, solo una cuestión de cuántos tokens se necesitan», justificó ante los aproximadamente mil desarrolladores presentes, según reportó heise.de.

En una votación espontánea, solo cinco personas en la sala levantaron la mano cuando DHH preguntó quién seguía programando a mano. El resto de su empresa ya solo trabaja con agentes de IA. La nueva arquitectura de Hey reduce los servidores a diez, e incluso eso por redundancia: un cálculo de DHH sugiere que una Raspberry Pi podría soportar la carga completa del backend.

Hasta ahí, el pitch. Lo que pasó después en X fue lo que el periodista de heise describió como un terremoto: las notificaciones de su teléfono colapsaron por la cantidad de reacciones. El creador de un framework, en el escenario de su conferencia más importante, delante de los mil programadores que lo usan cada día, les dijo que su framework ya no jugaba un papel en uno de sus dos productos principales.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Pero la afirmación más repetida, y la más criticada, no fue técnica. Fue filosófica: todos los programadores se han convertido en «makers 1000x» gracias a los agentes de IA. Y si tienes tokens infinitos, ¿por qué no encuentras nada que valga la pena construir para Rails?

La pregunta de Valim que DHH no respondió

José Valim, creador de Elixir y del framework Phoenix, lanzó la pregunta que resume el debate: tienes la herramienta más poderosa que has tenido, te has convertido en un maker 1000x, ¿y no se te ocurre cómo hacer tu stack 10x mejor? DHH intentó responder. La respuesta, según el análisis de jardo.dev, es más débil de lo que parece.

El ecosistema Elixir/Phoenix lleva meses anticipándose. Cada nuevo proyecto de Phoenix incluye por defecto un archivo agents.md optimizado para esa tecnología, y herramientas como Tidewave están diseñadas explícitamente para combinar el framework con coding agents, según el mismo reporte de heise. Phoenix, un competidor directo de Rails, no esperó a que los agentes maduraran: se adaptó a ellos primero. DHH, paradójicamente, dedicó su keynote a dejar Rails atrás en su propio producto.

El cuello de botella se movió, no desapareció

DHH no es el primero en defender que el costo de desarrollar software se ha desplomado por los LLMs. En agosto de 2025, Dan Luu publicó There’s no reason for software to be slow anymore, donde argumentó que el trabajo de optimización especializada, antes reservado a expertos con habilidades raras, ahora lo puede hacer cualquiera con «unas pocas frases» de prompt, según el texto original en danluu.com.

Luu puso números: construyó un motor de regex con un agente iterando durante un mes sobre un benchmark, vio mejoras de 2x a 4x en queries largas, y documentó que su IA para el juego de mesa Azul terminó siendo la más fuerte del mundo a pesar de haber invertido «dos órdenes de magnitud» menos tiempo que el segundo mejor proyecto, trabajando «principalmente en su laptop» en lugar de un cluster. Jamie Brandon, un ingeniero de performance con oferta de Anthropic, fue superado por Claude en un problema de optimización acotado. Luu estima una reducción de costo humano de 1000x a 1.000.000x para este tipo de tareas, dependiendo del caso.

Pero el propio Luu es cuidadoso. Advierte que los agentes sobreajustan benchmarks (su propio motor de regex estaba sobreajustado al suite rebar hasta que le advirtieron del holdout), son malos en diseño experimental sin asistencia humana, y «el tiempo para obtener un resultado riguroso no ha bajado, solo el tiempo para obtener un resultado interesante».

Varun Gandhi respondió con There continue to be reasons for software to be slow. Su argumento central: la forma «X costaba demasiado, los LLMs dividen ese costo por un número grande, así que la gente ahora hará X» se cumple para expertos trabajando en sus propios proyectos. Esos casos son raros. La arquitectura «Swiss cheese» de Basecamp 5 nació de la realidad de que el código era barato pero la coordinación no. El fork de Zig asistido por LLM de Bun compila 4x más rápido pero no puede subirse upstream porque nadie quiere un compilador no determinista. La conclusión: quitar un cuello de botella no elimina la cola, solo te muestra dónde está el siguiente. Con LLMs, el cuello de botella se mueve un paso a la derecha: de escribir código a todo lo que viene después.

DHH resolvió eso en Hey Next con un atajo: ya no mira el código, no le importa que Rust sea feo, delega «como si fuera a un compañero» y «revisa si el botón hace lo que tiene que hacer». Quizás funciona en su proyecto personal de un solo autor. Pero su tolerancia subiendo no sube la de nadie más.

La tolerancia sube, la calidad baja

Cuando el trabajo es asíncrono y dirigido por agentes, ya no estás cara a cara con git lento, autocompletado con lag y builds más largas. No hay un humano esperando. Si todavía te importan esas cosas, probablemente odies este nuevo modelo. DHH admite que no mira el código de Rust porque le parece «super feo»; antes despotricaba contra ese lenguaje en talks y en el podcast de Lex Fridman. Tú, fundador con un equipo distribuido, probablemente tengas que mirar el tuyo, y tus clientes también miran el resultado final. La tolerancia por lo crudo escala muy distinto cuando no eres dueño del producto.

La verdadera escasez: ideas, no código

He aquí la grieta más profunda del keynote. DHH recibió tokens ilimitados. ¿Qué construyó? Una calculadora. Un editor de video. Software de presentaciones. Otra distribución de Linux. Un rewrite de su propio producto. En la lista no hay una sola idea nueva. «Escasez de ideas», como resume jardo.dev.

Los LLMs son excepcionales haciendo cosas que ya existen. Luu lo admite: modelos anteriores sobreajustaban benchmarks hasta el absurdo. Una calculadora es un pedido seguro. En 2004, Rails no lo era. Era nuevo y se celebraba por eso. La keynote de DHH tiene esto al revés: la era del código escrito a mano no era una reliquia encantadora de la que hayamos salido. Antes de los LLMs, ejecutar una idea requería mucho más trabajo de piernas. Pero necesitabas una chispa primero. Y la sigues necesitando.

Qué significa esto para tu startup

El «1000x maker» es un caso límite, no una norma. Funciona cuando eres experto, trabajas en tu propio proyecto, en una empresa que controlas, sin manager que ajuste el presupuesto. Para la mayoría de founders y equipos hispanohablantes, la nueva productividad no se traduce en «ahora todo es posible»: se traduce en «ahora el código se genera más rápido y la deuda se acumula más rápido».

Tres acciones concretas que puedes tomar esta semana:

Mide dónde se rompe tu pipeline, no solo dónde se acelera. Si tus merges tardan, si tu code review es el cuello de botella, o si tu equipo de QA está saturado, los agentes no van a arreglar eso por arte de magia. Identifica tu siguiente restricción antes de añadir más agentes.
Reserva presupuesto humano para diseño experimental. Dan Luu lo dice explícitamente: los agentes son malos en eso. Si tu ventaja competitiva depende de elegir bien qué medir, qué optimizar, qué descartar, esa parte sigue siendo tuya.
No confundas velocidad de producción con velocidad de iteración real. Como la arquitectura «Swiss cheese» de Basecamp 5, muchos stacks modernos se acumulan por parches. Audita cada dos semanas qué se generó, qué se mergeó y qué está huérfano en producción.

Conclusión

DHH no está equivocado en que el costo del código bajó. Está equivocado en que eso nos convierte a todos en constructores de nuevas eras. El código era un medio, no el cuello de botella final. Y la velocidad sin nuevas ideas solo te lleva más rápido al mismo lugar. Para founders hispanohablantes, la lección no es «aprende a usar agentes» (eso ya es tabla rasa): es «decide qué quieres construir que nadie más haya construido». Ahí sigue sin haber tokens que alcancen.