La, la, la

Últimamente oigo la misma conversación en todas partes. En grupos de WhatsApp de antiguos compañeros, en cafés con gente con la que he hecho producto, al final de cenas que empezaron hablando de otra cosa. Alguien comparte una demo, alguien contesta que todo es humo y alguien dice, medio en broma, que dentro de cinco años no nos quedará nada que hacer. Nadie se ríe demasiado.

Quienes lo dicen casi nunca son novatos. Son veteranos: gente que lleva veinte años manteniendo sistemas en pie y que conoce el material mejor que casi nadie. Por eso se me queda el tono. Cuando quien conoce tan bien el oficio nota que el suelo se mueve, esa sensación merece algo más que un eslogan por respuesta.

También merece algo más de historia de la que está recibiendo.

Dos maneras de taparse los oídos

En julio, en un largo hilo de las listas del kernel sobre cómo integrar una herramienta de revisión con IA en el flujo de parches, Linus Torvalds perdió la paciencia con quienes todavía dudaban de que estas herramientas sirvieran:

"There are other questions around AI (like what the economy of it will actually look like in the end), but 'is it useful' is no longer one of those questions. Anybody who doubts that clearly hasn't actually used it."

— Linus Torvalds, lista de correo del kernel de Linux, julio de 2026

En el mismo correo reconocía los costes: las herramientas aumentan la carga de los mantenedores y no paran de encontrar bugs vergonzosos. Pero la respuesta, escribía, no es esconder la cabeza en la arena y cantar "La La La, I can't hear you" a pleno pulmón, como parece que hacen algunos.

Esa es la primera manera de taparse los oídos, y es la que oigo en los cafés. Es responder que la demo está escogida a dedo, que los sistemas de verdad son otra cosa, que ya se pasará. Algo de eso es cierto. Nada de eso aguanta una semana de usar las herramientas de verdad.

Hay una segunda manera, y hace más ruido. Terence Tao la describió la semana pasada en una entrevista con Numberphile, días después de que OpenAI publicara de golpe unos trescientos artículos matemáticos generados por máquina. El ambiente dominante, decía, es "no one understands anything, let's just keep accelerating": nadie entiende nada, sigamos acelerando. También canta para no oír. Lo que se niega a oír es la pregunta de si alguien sigue sabiendo qué está pasando.

El título de este texto va por los dos coros.

Dos ejes

Tao ha pensado en esto más tiempo y con más calma que casi nadie, y su planteamiento es el más útil que he encontrado. Ve dos ejes por los que pueden avanzar las matemáticas.

Uno es la comprensión: si las personas entienden lo que está pasando. El otro es la tecnología: si el trabajo se hace con lápiz y papel o con herramientas.

Durante miles de años se avanzó por el primer eje, porque las herramientas no resolvían problemas. Ahora sí, y la pregunta es si las adoptamos "while holding on to our understanding", sin soltar la comprensión, o si sacrificamos la comprensión para poder usarlas.

Durante casi toda la historia, el progreso subió por el eje de la comprensión. A partir de aquí, las herramientas pueden llevarnos muy lejos por el otro, con comprensión o sin ella.

Su analogía es el coche. Cuando llega el automóvil, puedes dejar de caminar del todo o encontrar un equilibrio en el que a veces conduces y a veces caminas. Un camino, dice, es disfuncional; el otro, apasionante.

Aquí debo declarar un conflicto de intereses. Voy en bici al trabajo todos los días desde que tengo memoria, así que la analogía me toca más de cerca de lo que Tao podría imaginar. La bici nunca me ha hecho desconfiar de los coches. Me ha enseñado cosas que un coche no enseña: dónde están de verdad las cuestas, cuánto se tarda realmente en cruzar la ciudad, qué calles tiene mal el mapa. El coche te lleva más lejos; la bici te dice dónde estás.

La bici, aparcada en la oficina de Dcycle. Una hora de ida por la mañana y una de vuelta por la tarde, todos los días laborables: dos horas al día sabiendo exactamente dónde están las cuestas.

La costumbre se me ha colado en la forma de trabajar. Con la gente de mi equipo prefiero un walk and talk a un one-to-one: salimos de la oficina y hablamos mientras caminamos y tomamos el aire. Nadie presenta nada y nadie comparte pantalla. La conversación va derivando hacia lo que de verdad está pasando, al ritmo al que se puede entender. Es el formato de reunión más lento que conozco, y el que más me enseña.

Lo que me gusta del planteamiento de Tao es que rechaza los dos coros a la vez. No te pide elegir entre la herramienta y el oficio. Te pregunta para qué servía el oficio.

En matemáticas, la respuesta nunca fue la demostración en sí. La demostración era el residuo visible de la comprensión, y la comprensión era lo que hacía crecer el campo. Tao llama al momento actual el paso de la escasez a la abundancia de demostraciones, y lo que le preocupa no es la abundancia. Es que "we're drowning in proofs, but we're not getting all the understanding that we used to get": nos ahogamos en demostraciones, pero no obtenemos toda la comprensión que obteníamos antes.

No lo dice con nostalgia. Admite que la era heroica era lenta, ineficiente y llena de ganadores y perdedores. Su pregunta es más sencilla: "what can we keep that's valuable and what can we let go of?" Qué merece la pena conservar y qué podemos dejar ir.

La palabra computer era un empleo

La gente del software debería reconocer esa pregunta, porque ya la hemos respondido antes, varias veces, normalmente mal al principio. Torvalds la planteó en su forma más afilada la semana pasada. Un mantenedor del kernel había propuesto exigir mensajes de commit escritos a mano, para dejar fuera los escritos por máquinas. Torvalds respondió con una regla de su cosecha:

"Here's a new rule just for you: don't use compilers for any of your kernel submissions.

Because if you can't show that you really understand what the machine is actually doing by writing your code in assembler, then I don't want to see your code contribution. You clearly aren't competent if you can't write it that way.

And btw, you had better not use an editor to write that commit message either.

Because I need you to show me that you can actually write a good commit message without using tools that make it easy to backspace and hide the mistakes you made while typing.

Ok?

Because otherwise those tool-assisted commits of yours clearly aren't showing that you know what you are doing.

Do you not see how UTTERLY STUPID those kinds of rules would be?"

— Linus Torvalds, lista de correo del kernel de Linux, octubre de 2026

La broma funciona porque es una lección de historia. Cada generación propone alguna regla del tipo «no uses la herramienta nueva para X», y a la siguiente le parece tan extraña como prohibir los compiladores. El compilador también fue la herramienta nueva. Y antes de él, hasta el ordenador era una persona.

Hasta los años cincuenta, eso era literalmente así: en inglés, computer era el nombre de un puesto de trabajo. El organismo que precedió a la NASA tenía salas enteras de ellas, mujeres en su mayoría, que hacían a mano los cálculos que necesitaba la investigación aeronáutica. Cuando llegaron las máquinas electrónicas, el nombre del puesto pasó a la máquina. Algunas de esas personas pasaron a otra parte. Dorothy Vaughan, que había dirigido a las West Area Computers en Langley, "became an expert FORTRAN programmer", en palabras de la propia NASA: se convirtió en experta programadora de FORTRAN. El trabajo no desapareció. Subió un piso.

Calculadoras humanas en NACA Langley, 1951, probando un manual de métodos para sus calculadoras Monroe. El nombre del puesto pronto pasaría a una máquina. Foto: NACA / NASA Langley Research Center (Bill Taub), dominio público.

Grace Hopper tenía un compilador funcionando en 1952. "Nobody believed that", recordaba décadas después. "I had a running compiler and nobody would touch it. They told me computers could only do arithmetic." Nadie se lo creía; nadie quería tocarlo; le decían que los ordenadores solo sabían hacer aritmética. A los compiladores todavía no se les llamaba compiladores. Se les llamaba programación automática, y la promesa era exactamente lo que sonaba. El informe de 1954 que anunciaba FORTRAN decía que "should virtually eliminate coding and debugging": que eliminaría prácticamente la codificación y la depuración.

Grace Hopper en el UNIVAC I con compañeros del Automatic Programming Department de Remington Rand, 1957. El nombre del departamento ya era la promesa. Foto: Smithsonian Institution (SI Neg. 83-14878), CC BY 2.0, vía Wikimedia Commons.

John Backus, que dirigió aquel proyecto, volvió sobre el informe en 1978 con una honestidad que ojalá fuera más frecuente en nuestro oficio. Citó la frase sobre eliminar la depuración y añadió, sin más, "[!]". También describió lo que pensaban entonces los programadores: que "rightly regarded their work as a complex, creative art that required human inventiveness", que veían su trabajo, con razón, como un arte complejo y creativo, y que estaban convencidos de que "efficient programming was something that could not be automated".

Tenían razón sobre el arte y se equivocaban sobre la automatización, y las dos cosas acabaron importando. FORTRAN automatizó una capa. El arte se mudó a la capa de arriba.

Un IBM 704 en NACA Langley, 1957: la máquina para la que se escribió FORTRAN, en el mismo laboratorio que había tenido salas enteras de calculadoras humanas. Foto: NASA, dominio público.

El patrón se repitió con cada generación de herramientas.

En 1982 James Martin publicó un libro cuyo título encajaría sin esfuerzo en cualquiera de aquellas conversaciones: Application Development Without Programmers. El prefacio anticipaba que "many DP professionals and, not surprisingly, programmers will instinctively resist" sus métodos. Cuatro años después, Fred Brooks, citando a David Parnas, ofreció el resumen que lo desinfla todo: "automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer". La programación automática siempre fue un eufemismo de programar en un lenguaje de más alto nivel que el que se tenía a mano.

La portada del libro de Martin de 1982. Cada ladrillo del muro entre usuario y programador tiene nombre: congelación de especificaciones, backlog de aplicaciones de varios años, programación lenta en COBOL. Las herramientas cambiaron; el muro sigue describiendo bastante bien la mayoría de los backlogs.

Mientras tanto, la profesión no encogió. El censo de Estados Unidos contaba unos 450.000 trabajadores informáticos en 1970 y 4,6 millones en 2014. La cifra incluye todas las ocupaciones informáticas, no solo programadores, y yo no me fiaría mucho de su precisión. Con la dirección basta.

Los que llegan

En el Open Source Summit de Praga de este mes, Torvalds añadió al correo de julio algo que no le había oído antes. Empezó a programar hacia 1981, le contó a Dirk Hohndel, cuando los ordenadores eran lo bastante sencillos como para entenderlos y los programas con los que comparabas los tuyos también lo eran. "The bar in software engineering has grown so high that it's hard to see your own small efforts as worth anything": el listón está tan alto que cuesta ver que tus pequeños esfuerzos valgan algo. Para quien empieza ahora, dijo, el vibe coding es "a wonderful way to find joy in programming", una forma maravillosa de encontrar la alegría de programar, y le gusta la idea de la IA como puerta de entrada.

Esa es la mitad de la historia que se les escapa a las conversaciones de café. Quienes notan que el suelo se mueve son los que están de pie sobre el suelo actual. Quienes reciben con gusto una capa nueva suelen ser aquellos para quienes la capa anterior era un muro. Sospecho que siempre ha sido así: una abstracción parece una amenaza vista desde arriba y una puerta vista desde abajo.

La misma charla contiene la otra mitad. Torvalds contó que había usado IA en un proyecto propio de juguete, un pedal de guitarra cuya interfaz, escrita en C, parecía "like something from the '80s", sacada de los ochenta. Le dio al modelo el prompt que todo el mundo da después de ver los vídeos, y el resultado "was horrendous". Lo que funcionó fue el paso siguiente: "Hey, look! I already did this in C. I did it the right way. It's just ugly." Él puso la comprensión; la herramienta puso la parte que a él se le daba mal. "I think that you need to be very careful using AI when you're doing something real and important", añadió: hay que tener mucho cuidado al usar IA en algo real e importante. Puerta de entrada y cautela en la misma conversación, en boca de la misma persona. Es el equilibrio de Tao contado por un ingeniero.

Lo que la historia no promete

Sería fácil parar aquí y decirles a mis amigos que se tranquilicen. Sería otra vez el primer coro, en un tono más erudito.

La historia de la programación automática muestra que el trabajo subió. No muestra que subiera solo. Cada capa de abstracción dejó debajo una capa que alguien seguía teniendo que entender. Los compiladores no abolieron la necesidad de saber qué hacía la máquina; la concentraron en menos personas, las que escribían los compiladores, afinaban los kernels y perseguían los bugs que nadie más conseguía reproducir.

Edsger Dijkstra lo vio a finales de los setenta, en una nota contra el sueño de dar instrucciones a los ordenadores en lenguaje natural:

"In order to make machines significantly easier to use, it has been proposed (to try) to design machines that we could instruct in our native tongues. this would, admittedly, make the machines much more complicated, but, it was argued, by letting the machine carry a larger share of the burden, life would become easier for us.

It sounds sensible provided you blame the obligation to use a formal symbolism as the source of your difficulties. But is the argument valid? I doubt. We know in the meantime that the choice of an interface is not just a division of (a fixed amount of) labour, because the work involved in co-operating and communicating across the interface has to be added.

We know in the meantime —from sobering experience, I may add— that a change of interface can easily increase at both sides of the fence the amount of work to be done (even drastically so)."

— Edsger W. Dijkstra, On the foolishness of "natural language programming" (EWD667)

Alguien tiene que estar en la interfaz y entender los dos lados.

El criterio correcto está en el mismo correo de Torvalds: "I expect people to understand what they are doing. But that understanding has very little to do with what tools they use." Espera que la gente entienda lo que hace, y esa comprensión tiene muy poco que ver con las herramientas que use.

Estoy de acuerdo con cada palabra. La dificultad es que la comprensión tampoco se mantiene sola. La entrevista de Tao es, entre otras cosas, un inventario de las formas en que se erosiona. Las empresas optimizan "speed and output and performance… above everything else": velocidad, volumen y rendimiento por encima de todo.

El coste de revisar el resultado recae en quien no lo pidió: de trescientos artículos, Tao había leído unos diez, algunos brillantes, muchos "still incomprehensible", un par ya retirados, y nadie de la empresa echando una mano. "We have this pile of stuff to go through", dijo, "which we didn't ask for": tenemos que revisar un montón de cosas que no pedimos. Cualquier mantenedor del kernel reconocería la frase. Y cualquiera que se gane la vida revisando pull requests.

Caminar

El ejemplo más interesante de la semana vino de un físico. Emre Onur Kahya, catedrático en la Universidad Técnica de Estambul, pidió a un modelo de IA que rehiciera, paso a paso, un cálculo de gravedad cuántica que había publicado con Richard Woodard en 2007. Era el trabajo de su doctorado.

El modelo encontró un error de signo y un término que faltaba, y confirmó que la conclusión física se sostenía. Kahya lo publicó todo en un repositorio abierto, con un método que enmarcaría y colgaría en cualquier equipo de ingeniería: las ecuaciones impresas se usaron como "inputs, not targets", como punto de partida y no como objetivo, y solo se compararon cuando la derivación estaba terminada. El repositorio incluso tiene una sección sobre lo que un experto humano todavía debería revisar.

Así es caminar con un coche aparcado en la puerta. Kahya no rechazó la herramienta ni le entregó su comprensión. La usó para poner a prueba lo que entendía, y dejó por escrito dónde termina esa prueba. Su propia pregunta en redes fue qué significará a partir de ahora la palabra esfuerzo en la academia. Sospecho que irá desplazándose hacia esto: menos las horas dedicadas a producir un resultado y más el cuidado puesto en saber si es verdad.

Hay una parte de la entrevista de Tao que debería preocupar a la industria del software más que cualquier benchmark. En matemáticas, explica, se reservaba cierto tipo de problemas para los estudiantes: de dificultad media, resolubles por alguien veterano, pero que se dejaban sin tocar para que la siguiente generación aprendiera con ellos. Son justo los problemas que las máquinas se llevan primero.

Nuestro oficio tiene la misma reserva. Se llama el ticket de junior: la funcionalidad pequeña, el bug modesto, la migración que ningún senior quiere. Es donde la gente aprende cómo se comportan de verdad los sistemas. Si automatizamos esa capa sin diseñar otro camino de entrada al oficio, no nos quedaremos sin trabajo. Nos quedaremos sin gente que entienda la capa de abajo.

La respuesta de Tao para la educación es anticuada y correcta. A los niños les enseñamos a calcular a mano antes de darles la calculadora. Calcular a mano no es como deberían calcular los adultos. Es como llegan a entender lo que hace la calculadora. Cada organización de software va a necesitar su propia versión de esa regla, y muy pocas la han escrito.

Vuelta al café

La próxima vez que salga la conversación, no les diré a mis amigos que todo va a ir bien, porque no lo sé y nadie lo sabe. Tampoco les diré que las herramientas son humo, porque no lo son.

Les haré una pregunta más cercana a la de Tao. No si habrá trabajo para nosotros dentro de cinco años, sino qué parte de lo que hacemos entendemos de verdad y qué parte solo sabíamos teclear. La primera viaja con nosotros a la siguiente capa, sea cual sea. La segunda siempre iba a acabar automatizándola alguien.

Y como probablemente habré llegado en bici, les daré el único consejo práctico que tengo, que es de transporte.

Coged el coche cuando la distancia es larga y el camino se conoce bien. Id andando cuando necesitéis ver la calle. Y de vez en cuando, los días en que cueste un poco, pedalead: cuesta arriba por donde podríais haberos ahorrado la cuesta, a través del problema que podríais haber delegado, solo para seguir sabiendo dónde están las cuestas.

Hopper, Backus y Martin reconocerían la conversación. Sesenta años después, ya es un poco tarde para cantar por encima.