Lunes. 09:04. Manolo ha metido un teclado en una vitrina. Debajo, una cartela: «OFICIO EXTINGUIDO».
—¿Se ha estropeado? —pregunto.
—Lo he jubilado. Ayer vi la conferencia de DHH. Lápices abajo, Jose. Ahora se habla con los agentes y aparece el software.
En la pantalla del despacho sigue pausada la charla inaugural de Rails World 2026. David Heinemeier Hansson, el creador de Ruby on Rails, cuenta que en 37signals han dejado de escribir código a mano como forma habitual de trabajar. Enseña lo que están construyendo con agentes y habla de rehacer partes de HEY con aplicaciones nativas y un servidor en Rust.
—¿Y qué vas a hacer tú con el teclado? —pregunto.
—Abrir con él mi conferencia del jueves. Vienen sesenta clientes y varios desarrolladores que construyen sobre nuestra plataforma de reservas. Voy a anunciar que yo también me retiro de programar.
—¿Qué les prometiste que contarías?
Manolo abre la invitación: «Novedades de la plataforma, próximas funciones y hoja de ruta».
—Todo eso cabe después —dice—. Primero hay que inspirarlos.
Ensaya de pie, con el teclado bajo el brazo.
—«Amigos, el futuro ya está aquí. Hemos hecho doce prototipos en un fin de semana. Nuestra nueva aplicación será nativa. El servidor quizá vaya en otro lenguaje. Es el momento de abandonar las viejas maneras».
—¿Y la plataforma que usan esos sesenta clientes?
—Sigue ahí.
—¿Qué versión sale después? ¿Qué API mantenéis? ¿Cuánto tiempo tendrán para adaptarse si cambias algo?
—Eres incapaz de emocionarte.
Llega Lucía, que mantiene la integración de una cadena de clínicas. Lleva tres años haciendo que las reservas de Manolo lleguen al sistema de citas de treinta centros.
—He visto el borrador de la charla —dice—. ¿Vas a anunciar que vuestro producto nuevo ya no usará la plataforma?
—Estoy anunciando una posibilidad. Tenemos la libertad de elegir la mejor herramienta.
—Por supuesto. Yo también la quiero. Lo que necesito saber es qué pasa con la herramienta en la que mis clientes han invertido tres años.
Manolo le enseña los doce prototipos. Uno permite reservar una cita hablando. Otro crea un calendario con un dibujo de cada médico. Un tercero convierte la espera en un videojuego. Lucía se detiene en el quinto.
—Este abre en mi móvil —dice.
—¿Ves? Ya estamos avanzando.
—He dicho que abre. ¿Puede cancelar una cita y avisar al centro? ¿Conserva la configuración de los treinta centros? ¿Quién atiende al cliente si el recordatorio llega a la hora equivocada?
Manolo pasa al sexto prototipo.
—Ese tiene mejores colores.
Lo curioso de la conferencia de DHH es que hay algo valioso en ella. Un creador no está obligado a escribir cada línea de código con sus dedos. Puede cambiar de herramienta, probar otra arquitectura y descubrir que ahora es capaz de construir cosas que antes no podía. Manolo debería escuchar esa parte.
También debería escuchar la pregunta que dejó en la sala. El programa oficial presentaba la apertura como una charla sobre las novedades y el futuro de Rails. En la discusión posterior, varios asistentes y usuarios se quejaron de que dedicara mucho espacio a sus experimentos y a HEY, y menos a una dirección concreta para el framework. Otros defendieron la charla. No hubo una sola reacción.
—Entonces, ¿DHH no puede rehacer HEY como quiera? —pregunta Manolo.
—Puede. Y puede decirlo. HEY es su producto; Rails es además una herramienta sobre la que mucha gente construye el suyo. En el congreso de Rails, esas personas quieren entender las dos cosas y la relación entre ellas.
—Yo también voy a hablar de mi producto.
—Vas a hablar de doce productos que aún no tienes. Lucía te está preguntando por el que sí tiene delante.
Manolo mira la vitrina. El teclado parece un fósil bastante reciente.
—Pero si los agentes hacen el trabajo más rápido, ¿por qué no iba a cambiarlo todo?
—Porque «hace más código» y «tenemos un producto mejor» son frases distintas. También lo sabe la propia comunidad de Rails. La Rails Foundation publicó este mes una prueba con veinte tareas de producto sobre una aplicación real: el mejor agente completó el 35 % de las ejecuciones según sus comprobaciones. Era una prueba concreta, con límites concretos; no mide el trabajo de DHH ni predice el futuro de todos los agentes. Sí recuerda que una demo que funciona y una función terminada son cosas distintas.
Lucía señala el calendario del quinto prototipo.
—A mí me vendría fenomenal una ayuda que escribiera la integración más deprisa —dice—. Tengo cambios repetitivos que delegaría mañana. Pero alguien tendrá que decidir qué significa «cancelar» en treinta centros diferentes. Y hacerse cargo cuando esa decisión afecte a una persona con cita.
—Eso ya no es escribir código —responde Manolo.
—Llámalo como quieras. Sigue siendo parte de construir software.
Manolo vuelve a leer su primera diapositiva: «SE ACABÓ PROGRAMAR». Debajo tiene otra con el número de líneas que han generado sus agentes esta semana. La quita.
—¿Y qué pongo? —pregunta.
Lucía coge un rotulador y divide la pizarra en tres columnas: «Lo que funciona», «Lo que estamos probando» y «Lo que todavía no sabemos».
—En la primera, la plataforma que usamos. En la segunda, esos prototipos y lo que vais a medir antes de prometerlos. En la tercera, las decisiones de arquitectura que aún no habéis tomado. Yo puedo trabajar con esa incertidumbre. Con un discurso triunfal y ninguna fecha, no.
Manolo abre la vitrina. Saca el teclado.
—¿Lo devuelvo a Ingeniería?
—Sí. Si quieren escribir una línea a mano, que puedan. Si un agente les ayuda, también. Tu trabajo del jueves es explicar qué van a poder construir los demás sobre lo que tú mantienes.
Se lleva el teclado y deja la cartela sobre la mesa. Alguien ha escrito detrás, con rotulador: «FUTURO PENDIENTE DE CONFIRMACIÓN».
Hay una diferencia enorme entre contar lo que ahora puedes hacer y anunciar que el oficio de los demás ya no hace falta. Más aún cuando esas personas están sentadas delante, esperando noticias del producto que les ayudaste a construir.
Gracias por leerme.
Todos conocemos a un Manolo. A veces somos un Manolo. Cada semana uno nuevo.