Hace poco vi el vídeo de una charla que se me ha quedado en la cabeza más tiempo de lo habitual. Era la charla que Kent Beck dio en Prodacity 2026. Beck es el creador de Extreme Programming y quien popularizó el TDD en todo el mundo. Se titulaba «Software Engineering in the Age of AI». En ella se preguntaba qué significa hacer buen software ahora que la IA escribe gran parte del código. De los poco más de 52 minutos que dura, lo que más me llegó fueron dos palabras y una breve anécdota sobre un violonchelista.
Kent Beck planteaba el desarrollo de software sobre dos ejes. Features y futures. Uno es el de las funcionalidades que implementamos; el otro, el de las opciones que tenemos para cambiar este software en el futuro, es decir, su margen de cambio (optionality). Según explicaba, un proyecto arranca sin ninguna funcionalidad pero con posibilidades infinitas, y cada vez que se implementa una funcionalidad, los futures se reducen. Venía a decir que, si solo se siguen acumulando funcionalidades, al final se llega a un software muerto, con los futures a 0, en el que cuesta tocar cualquier cosa.
En cierto modo, es algo que como ingeniero ya había comprobado en mi propia piel en el día a día del trabajo: la importancia de refactorizar. Si mientras implementaba una funcionalidad veía algo que se podía mejorar, lo refactorizaba sobre la marcha, y si antes de empezar la siguiente me quedaba un rato libre, también lo aprovechaba para refactorizar. Pero en algún momento empecé a encargarle a la IA el código entero, de principio a fin, y tuve la sensación de que, desde entonces, se me había ido escapando «el tiempo de refactorizar». Al implementar una funcionalidad cuento con varios harnesses (mecanismos que corrigen el trabajo de la IA, como los tests, el linter, los hooks, los prompts con restricciones y los agentes de verificación), pero me di cuenta de que no estaba sacando «un rato solo para refactorizar».
También me sentí muy identificado con lo que vino a decir Kent Beck a continuación: que antes hacían falta 100 personas y 10 años para que los futures llegaran a 0, y que ahora, gracias a la IA, una sola persona puede dejarlo todo hecho un desastre en una semana. No puedo contar aquí todo lo que pasó, pero durante toda la charla los tropiezos que había dado por el camino se iban superponiendo, uno tras otro, al dibujo de Kent Beck. Mirando atrás, creo que se me había olvidado por completo lo importante que es el cool down entre una funcionalidad y la siguiente.
Para explicar la alternativa, Kent Beck recurrió a una anécdota del violonchelista Pablo Casals. Contó que la había oído de joven, cuando estudiaba guitarra clásica en la facultad de música. El violonchelo es un instrumento que exige mucho físicamente, y al parecer en una de las piezas que tocaba Casals había un pasaje de semicorcheas que no se acababa nunca. Cuando alguien le preguntó si no se cansaba de tocar tantas semicorcheas, Casals respondió: «No, descanso entre las notas». En realidad, por lo visto, Casals nunca dijo tal cosa y la historia es inventada. Aun así, Kent Beck añadió que era una historia tan buena que no le quedaba más remedio que contarla.
Aunque sea inventada, al escuchar lo del descanso entre las notas volví a pensar que incluso en el trabajo con IA, que avanza a un tempo rápido, haría falta «el tiempo de preparar las manos y la respiración para dar con precisión la siguiente nota»; dicho de otro modo, «el tiempo de poner orden». El «tiempo de refactorizar» del que hablaba más arriba era justo ese espacio entre las notas. Cualquier desarrollador sabe lo básico: que para hacer un software flexible y extensible hay que ir poniendo orden entre funcionalidad y funcionalidad. Pero me parece que precisamente ahora, cuando no paran de salir funcionalidades, es el momento de volver a lo básico. Igual que Casals descansaba incluso entre aquellas semicorcheas interminables, ¿no debería haber también, entre las features que se desarrollan a toda velocidad, un rato para poner orden, con la refactorización y los casos de prueba incluidos? También me llegó enseguida la comparación que hizo Kent Beck: «No se puede limpiar el cuchillo mientras se corta, pero el cuchillo hay que limpiarlo».
El rastro de tanto correr sin poner orden no estaba solo en el código. También seguía ahí, tal cual, dentro de mi MacBook. Cuando terminó una temporada de trabajo a destajo y me quedó un poco de tiempo muerto, aparecieron cosas que solo se ven al parar. Tenía worktrees de git y contenedores de bases de datos que no había llegado a ordenar, amontonados aquí y allá, y el espacio libre en disco iba camino de agotarse. Si me hubiera lanzado así a la siguiente tarea, a lo mejor en algún momento el espacio habría llegado a 0 y todo se habría parado. Fui borrando una a una las cosas acumuladas, y solo entonces el MacBook recuperó margen para la siguiente tarea. Digamos que así también volvieron un poco los futures de mi MacBook.
No hace mucho fuimos en familia a la isla de Jeju. Lo que más se me ha quedado del viaje es el amanecer en Seogwipo. Me gustó mucho ese rato: levantarse temprano y ver cómo salía el sol. Las nubes aborregadas que cubrían todo el cielo se iban tiñendo de naranja desde abajo, y por detrás de las siluetas de las palmeras el sol asomaba poco a poco.
Curiosamente, desde que volvimos del viaje, el ambiente de las mañanas en casa ha cambiado de golpe. Levantarnos temprano para empezar el día se ha convertido, casi sin darnos cuenta, en el ritmo de la casa, y siento que, gracias a eso, poco a poco también estamos más sanos. Aquel viaje vino a ser, para nuestra familia, el momento de poner orden entre las notas. Pensándolo bien, diría que nuestra vida tampoco es muy distinta del software. Ya sea en el trabajo o en la crianza, los días se suceden a toda prisa camino de la siguiente feature, y si entre medias no se pone orden, ¿no se irán quemando poco a poco también los futures de nuestra vida?