37signals convierte escribir código a mano en la excepción, no en la norma
David Heinemeier Hansson presentó en Rails World la política "pencils down" de 37signals: el código escrito a mano pasa a ser la excepción. Sus benchmarks de agentes sobre Rails se quedan en el 53%.
En su charla en Rails World, David Heinemeier Hansson presentó la política interna que 37signals llama "pencils down", lápices abajo: escribir código a mano deja de ser el flujo normal y pasa a ser la excepción. Si un agente no resuelve una tarea, el equipo la hace a mano y después retoca el flujo de trabajo. No es una prohibición, pero invierte la norma.
Un diff razonable no es una arquitectura coherente
El caso de Basecamp 5 es el que peor se digiere. Los diseñadores llevaron docenas de pull requests generados por agentes que, vistos uno a uno, parecían razonables; juntos dejaron la arquitectura llena de agujeros. El equipo volvió entonces a un trabajo más guiado por programadores. DHH sostiene ahora que mejores agentes y mejores flujos son el camino, pero no enseña una reparación de ese problema concreto hecha por un agente. Tampoco fue un funeral para Rails: describió una dirección en curso para HEY con cliente nativo y backend en Rust, y defendió que la web sigue importando y que las convenciones del framework ayudan a los agentes.
Los números piden matices. La comparación de 100 a 1.000 veces que cita DHH se refiere al mejor programador asistido frente al peor sin asistir: es una conjetura, no una medición de velocidad para un equipo medio. Su predicción de que casi todos los dominios irán por ahí a finales de 2026 es una apuesta económica, no una fecha medida.
En pruebas con agentes sobre Rails, una evaluación anterior y más simple rondaba el 95% de éxito. El conjunto de tickets de funcionalidad más difícil de la presentación se queda en el 35% con el esfuerzo mostrado, y en una evaluación a máximo esfuerzo el mejor modelo superó el 53% de las ejecuciones sobre 20 tickets, con más tiempo y coste. Es progreso real, no una tasa de fiabilidad en producción.
Un test en verde no lo dice todo
El ejemplo que pone el autor es una migración de Sidekiq a Solid Queue. Cambiar el adaptador se describe en una línea; drenar los trabajos encolados, programados y en reintento mientras ambos sistemas conviven es el trabajo de verdad, y una suite que pasa no avisa de que Redis sigue lleno. Con un CLI de aplicación que un agente pueda manejar, la tentación es darle una clave de API de producción para ir más rápido. La respuesta razonable es otra: comandos con alcance limitado y auditables, sin credenciales amplias en el prompt ni en el entorno, y decisión humana para lo irreversible.
Lo que cambia para quien mantiene sistemas es que una colección de diffs plausibles no equivale a un sistema coherente, y que la experiencia sigue sirviendo para reconocer cuándo un cambio simple deja de serlo. La política de 37signals es una decisión de una empresa, no un plan que nadie tenga que seguir mañana. Queda por ver si los flujos mejorados cierran la distancia entre ese 53% y algo que se pueda desplegar sin revisión.
