Entrevista extensa (**25 minutos de lectura**) con **David Heinemeier Hansson**, creador de **Ruby on Rails** y copropietario de **37signals**, realizada por **Vikas Shah** en *Thought Economics*, publicada el **28 de septiembre de 2026**, cinco días después del discurso de apertura de **Rails World** en Austin, donde anunció que 37signals dejaba *"los lápices quietos"* en el código escrito a mano. **(A)** El giro, con fecha: en el verano de 2025 le dijo a **Lex Fridman** que no dejaría que la IA escribiera su código; lo que le hizo cambiar de opinión fue la llegada de los agentes de codificación a finales de 2025, y *"el cambio se ha vuelto realmente vertical, en mi opinión, en los últimos tres o cuatro meses"*. **(B)** El argumento de fondo no es técnico sino político: los programadores se habían convertido en *"una clase clerical"* que mediaba el acceso a la máquina, y el agente desempeña el papel de Lutero — *"Agent Luther"* — al eliminar al intermediario. Extrae una consecuencia para sí mismo: sus habilidades de programación ya no son *"económicamente viables como palanca independiente"*. **(C)** La clasificación de los modelos de negocio: el lado cliente ya está *"liquidado"* (Adobe), el cliente-servidor aún resiste porque *"la gente no tiene ningún deseo de administrar sus propios servidores"*, los fosos de fontanería resisten (Shopify, *"sistemas de pago, envío e impuestos"*), y **Salesforce** y **SAP** están *"en serios problemas"* ya que *"ya no hay valor en el código, solo en las intuiciones de proceso"*. **(D)** **Omarchy**, su distribución de Linux con agentes integrados: la versión **Quattro**, escrita exclusivamente por agentes, **200.000 descargas en 18 días**, **4.000 plugins** en cuatro semanas, **21,7 millones de dólares** en promesas de donación. **(E)** El cierre prospectivo: la AGI alcanzada, *"bolsas de ASI"*, robots, y *"¿qué haces cuando ya no te queda nada por hacer?"*. Para leer junto con [[lecun-still-far-from-human-level-ai-llm-2026-09-25]] del mismo mes.
#fin del código escrito a mano#dejar los lápices#agentes de codificación
David Heinemeier Hansson · créateur de Ruby on Rails et copropriétaire de 37signals · interrogé par Vikas Shah dans *Thought Economics*.
El desarrollo de software como oficio, transparencia y confianza, código abierto auténtico, impacto de la IA en las competencias fundamentales - Gilles Chehade - Plakar - OpenSMTPD
#desarrollo de software#artesanía del software#código abierto
**Mathieu Eveillard** publica en su blog personal el **7 de diciembre de 2022** (última actualización el 17 de marzo de 2025) una **contraargumentación punto por punto** al célebre ensayo de **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Artículo categorizado **craft / best-of**, una postura de **artesano del software** que defiende el **Test-Driven Development** sin dogmatismo. **Distinción crucial** que a DHH se le escapa según Eveillard: ***"Test-first"*** (escribir todos los tests antes de cualquier código) frente a ***"Test-Driven Development"*** (los tests me **guían** en la escritura del código, de modo que cada vez escribo un fragmento de código *"en reacción"* a un nuevo test). DHH en realidad critica el *Test-first* llamándolo TDD — una confusión que **oculta una forma de programar completamente distinta**. **Respuestas punto por punto**: (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concede el punto deontológico pero redefine el *"buen código"*: no solo la ausencia de bugs sino **tests unitarios de grano fino** que documentan el comportamiento en el nivel más bajo, ubicados junto al código, una **red de seguridad**; (2) *"Rebalance from unit to system"* — TDD **no dice nada** sobre los tests de sistema y **no dice** que no haya nada fuera de TDD; los tests de sistema **no sustituyen** a los tests unitarios (una declaración de la renta probada de extremo a extremo no tiene sentido); **pirámide de tests** — cada tipo aporta su parte, los tests unitarios para un feedback de **milisegundos** + detección temprana de bugs; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard responde que **no observa estos efectos en programación funcional**, por lo que el efecto probablemente se deba a la **POO**, no al TDD; pero concede que una inyección de dependencias excesiva puede acoplar test e implementación. **Conclusión equilibrada**: *"TDD is not a religion, it's a tool"*. TDD es especialmente adecuado para el **código de dominio** (el núcleo funcional de un *bounded context*, el *core del hexágono*) — motores de cálculo, reglas de negocio de grano fino, casos límite por doquier — ***"30% del código base como máximo"***. Menciona la **Law of the Instrument** (si la herramienta no ayuda, es porque has caído en ella). **Relevancia para el corpus**: un **artículo de craft ajeno al corpus de IA** pero que vale la pena archivar para situar los debates actuales sobre agentes de codificación (*Augmented Coding Beyond Vibes* de Beck, 2025-06-25, Vibe Coding vs TDD, la *atrofia del músculo de la escritura* de Frizzo) dentro del linaje histórico de los debates de craft en torno al TDD. Para usar como **base de biblioteca** para sesiones de formación.
#Mathieu Eveillard#TDD#Test-driven development
**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD · du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).