El cuello de botella no estaba en escribir código: la tesis de DHH sobre la IA, revisada
DHH sostiene que los LLM han hundido el coste de escribir código y que por eso llegan las apps nativas con Rust. Quien le responde señala que el cuello de botella solo se ha movido de sitio.
El keynote de DHH en el Rails World venía a decir que el coste de desarrollar software se ha ido casi a cero y que por eso las aplicaciones web van a convertirse en nativas, con Rust detrás. El motivo no es tecnológico, es de coste: si escribir código ya casi no cuesta dinero, deja de tener sentido organizar la arquitectura alrededor de ahorrarlo.
No es el único que sostiene algo parecido. En agosto, Dan Luu publicó There's no reason for software to be slow anymore, donde argumenta que el trabajo especializado de rendimiento se ha abaratado lo suficiente como para que casi cualquiera pueda permitírselo. Varun Gandhi le respondió con There continue to be reasons for software to be slow, y ahí está el matiz que al keynote se le escapa.
Gandhi acepta la premisa y discute el alcance. El coste ha bajado para alguien como Luu: un experto trabajando en su propio proyecto, sin nadie que le apriete el presupuesto. Es el mejor caso posible, y DHH lo generaliza a prácticamente todos los programadores y todas las empresas para diciembre. DHH encaja justo en ese perfil: experto, producto propio, empresa que controla.
El coste nunca estuvo en teclear
El argumento central de Gandhi es que escribir el código nunca fue el gasto dominante. Faltan el despliegue, el mantenimiento y evitar regresiones. Hey Next tiene una semana de vida y no es un sistema en producción; el propio DHH lo enseñó así. La arquitectura de queso suizo de Basecamp 5 nació de que el código salía barato pero la coordinación no.
El ejemplo que mejor lo ilustra es el fork de Zig que Bun generó con ayuda de un LLM: compila cuatro veces más rápido y no se puede enviar al proyecto original, porque nadie quiere un compilador no determinista (hilo en ziggit). Quitar un cuello de botella no elimina la cola: enseña dónde está el siguiente. Con los LLM, el cuello se mueve de escribir código a todo lo que pasa después.
DHH lo resuelve saltándoselo. Reconoce que lenguajes como Rust le parecen verbosos e incómodos de leer para un humano, así que no los lee y deja que el agente escriba más de lo necesario, algo que no toleraría en su código Ruby. Entrega la tarea como se la daría a un compañero y revisa cuando hay algo listo, donde revisar no es leer el diff sino comprobar que el botón hace lo que debe. Para un proyecto personal de una semana puede valer. Su tolerancia no sube la de los demás: a él le da igual qué hay dentro de la caja de Hey Next, pero a mucha gente le importa qué hay dentro de la caja de Rails.
Ideas, no tokens
Queda la pregunta que planteó José Valim: si tienes el instrumento más potente que has tenido nunca, si eres un creador 1000x, ¿no se te ocurre nada para mejorar tu propio framework? La respuesta del texto es que el problema nunca fue el presupuesto. Más velocidad no cambia las prioridades. Todo lo que DHH construyó este año lo quería para él, y nada de eso necesita que Rails mejore.
Con tokens infinitos, la lista es un editor de vídeo, una calculadora, software de presentaciones, otra distribución de Linux y una reescritura de su propio producto. Ni una idea nueva. Los LLM son extraordinarios fabricando lo que ya existe; una calculadora es una petición segura. En 2004, Rails no lo era.
