El creador de Ruby on Rails dice que ha dejado de escribir código a mano: qué cambia con la IA

Una declaración sobre su trabajo y una predicción sobre el de todos

La conferencia inaugural de Rails World se celebró el 23 de septiembre en Austin. En el fragmento, Hansson recuerda unos 25 años escribiendo código manualmente y sostiene que esa etapa terminó para él meses antes. Su propuesta es adoptar una identidad centrada en crear productos, aunque la máquina redacte las instrucciones que los hacen funcionar.

El salto más discutible llega cuando generaliza. Afirma que escribir código a mano ya no resulta económicamente productivo para la gran mayoría de programadores y empresas, y pronostica que antes de terminar 2026 sucederá en prácticamente todos los ámbitos. Es una predicción suya sobre rentabilidad, no una medición del conjunto del sector.

En una publicación propia, DHH reafirma el mensaje: presenta la transición como una oportunidad para aplicar capacidad analítica y materializar ideas con mayor rapidez. Dejar de redactar código, en ese planteamiento, no equivale a dejar de construir software.

Fuentes: [1] Evolving AI · reel sobre la intervención de DHH · [2] David Heinemeier Hansson · explicación de su postura y enlace a la conferencia · [3] Ruby on Rails · conferencia inaugural de Rails World 2026 · [4] Rails Foundation · fecha y contexto de la conferencia

Escribir menos código no elimina todas las decisiones

El cambio puede entenderse con un ejemplo hipotético. Una empresa encarga una aplicación de reservas: alguien tiene que definir qué sucede cuando dos clientes solicitan la última plaza, quién puede cancelar y cómo se recupera el sistema si el cobro se completa pero la reserva falla. Una herramienta puede ayudar a implementar esas reglas; el producto seguirá necesitando que sean correctas.

Nuestra lectura es que la automatización desplaza parte del esfuerzo hacia la definición y comprobación del trabajo. Cuanto más fácil sea producir una primera versión, más importante puede resultar distinguir una demostración convincente de una solución mantenible. Eso no garantiza que todas las tareas de revisión permanezcan humanas: también pueden automatizarse parcialmente. La cuestión práctica es cómo se comprueba el resultado y quién responde por él.

Lo que los estudios permiten decir sobre productividad

METR ilustra por qué conviene evitar sentencias universales. Su experimento con herramientas de principios de 2025 encontró que desarrolladores experimentados tardaban un 19 % más con IA en las tareas estudiadas. Ese resultado describe unas condiciones y un periodo concretos; no es una evaluación de las herramientas de otoño de 2026.

En febrero de 2026, la organización explicó que su experimento posterior ofrecía una señal poco fiable: algunos desarrolladores no querían participar si debían trabajar sin IA y otros excluían tareas donde esperaban obtener más ayuda. También había cambiado la remuneración y resultaba difícil contabilizar el tiempo al usar agentes en paralelo. METR consideraba probable una mejora respecto a principios de 2025, pero advertía de que esos datos aportaban evidencia débil sobre su magnitud.

Fuentes: [5] METR · actualización del experimento de productividad, 24 de febrero de 2026

Ganar velocidad y generar valor son preguntas distintas

Una encuesta posterior de METR, publicada en mayo de 2026 y realizada entre febrero y abril a 349 trabajadores técnicos, encontró medianas de aumento declarado del valor del trabajo de entre 1,4 y 2 veces, según la pregunta. La muestra incluía ingenieros de software, investigadores, académicos y responsables de empresas. Los autores advierten de que las respuestas pueden exagerar el efecto real.

La distinción entre valor y velocidad importa. Terminar antes una tarea aporta una ventaja, pero hacer muchas tareas de escasa utilidad no mejora necesariamente el resultado del proyecto. Una encuesta sobre lo que las personas creen haber ganado tampoco equivale a una comparación experimental del rendimiento.

Para una empresa, proponemos medir el ciclo completo: definir el encargo, producir, revisar, integrar y corregir después de la entrega. Esa perspectiva evita que el ahorro visible al generar código oculte trabajo adicional en otras fases.

Fuentes: [6] METR · encuesta de productividad declarada, 11 de mayo de 2026

Cómo llevar el debate a una decisión concreta

En lugar de decidir por adhesión o rechazo al mensaje de DHH, un equipo puede comparar tareas representativas de su propio producto. La siguiente tabla es una propuesta editorial de evaluación, no un ensayo realizado por Pulso Diario. Conviene conservar las mismas exigencias de calidad y contabilizar también los errores posteriores.

Para quien aprende, el reto es conservar el criterio

La experiencia de un creador con décadas de práctica no describe automáticamente la de quien comienza. Como orientación editorial, aprender con IA debería incluir explicar una solución, detectar un fallo introducido a propósito y modificar un comportamiento sin perder de vista el conjunto. Un resultado que funciona una vez no demuestra que su autor comprenda por qué.

Los fundamentos pueden servir precisamente para supervisar mejor: representar datos, razonar sobre estados, entender permisos y comprobar que un cambio no rompe otro. La combinación de práctica manual y asistencia puede variar según la tarea y la persona; el reel no establece una proporción adecuada para aprender.

La aportación más útil del mensaje de Hansson es cuestionar que el valor profesional dependa del número de líneas escritas. La parte que queda por demostrar es su alcance universal y su calendario. Una profesión puede cambiar profundamente sin que una única forma de trabajar resulte superior en cualquier proyecto.