El código está solucionado. ¿Y ahora qué?

El código está solucionado.

Casi. No exactamente. Lo que se ha resuelto es una parte muy concreta del trabajo, la que se llevaba las tardes enteras, y lo que queda es lo que nadie había tenido que entrenar antes.

Durante años, mi trabajo fue este bucle: escribo código, compilo, ejecuto, no funciona, leo el mensaje de error, cambio una línea, vuelvo a empezar. Un error de una línea podía llevarse una tarde entera. Daba igual lo bien que hubiera pensado el diseño: si aquello no arrancaba, no había nada. Había días en los que no sacaba nada adelante, y lo desesperante nunca era el error. Era el bucle.

Ahora el código, simplemente, funciona. No siempre y no para todo, pero lo suficiente como para que el bucle haya dejado de ser mi trabajo. Y eso ha movido el ejercicio de sitio: antes lo primero era ejecutar bien; hoy, saber qué crear. Es la misma profesión con otro músculo, y llevo meses intentando averiguar cuál se entrena y cómo.

Lo que había detrás del bucle

Cuando cuento esto me preguntan siempre lo mismo: ¿y cómo sabes que está bien si no lo has leído? Buena pregunta. Durante toda mi carrera la respuesta era esa: lo he leído. Pero mirándolo de cerca, lo que yo hacía con el código no era comprenderlo. Era agarrarlo. Cuando algo se rompía, podía leerlo y arreglarlo antes de que se enterara nadie. Eso es una superficie de control¹, y explica lo que me cuesta aceptar un cambio que no he escrito: no es que no lo entienda, es que no tengo dónde agarrarlo.

El detalle incómodo es que tampoco entendía del todo el código que escribía yo. Nadie de mi generación sabía qué bytecode acababa ejecutando su Python. Ni qué plan iba a lanzar el planificador de la base de datos. Publicábamos igual, porque la ilusión funcionaba mientras la capa de debajo fuera estable, y no porque fuera verdad¹.

Lo que se ha movido, entonces, no es mi entendimiento. Es la superficie. Ahora escribo el script que mide, y lo que reviso es el script.

Y no es solo impresión mía

Fui a mirar los números por si acaso.

En marzo, el ranking de consumo de a16z soltó un dato que ya no sorprende a nadie y una frase que sí: ChatGPT en 900 millones de usuarios semanales, y una lista que ha dejado de separar los productos de IA de los productos con IA dentro². La edición anterior del mismo informe ya hablaba de la era del builder³.

Microsoft fue más lejos: abrió su blog de ingeniería diciendo que el ciclo de vida tradicional está roto. La revisión manual se cae bajo un caudal de peticiones para el que nadie la diseñó, el foco se ha movido de enviar código a orquestar sistemas, y cuando construir es barato el recurso escaso es el criterio para decidir qué merece la pena construir⁴.

Los números acabaron de convencerme. El código se escribe entre un 30 % y un 40 % más rápido, y si el resto del ciclo sigue siendo manual, la productividad del equipo sube menos del 10 %: el cuello de botella no desaparece, se muda⁵. Un análisis de más de diez mil desarrolladores encontró un 98 % más de cambios fusionados y un 91 % más de tiempo para revisarlos⁶. Escribir es rápido. Lo lento es tener con qué comprobarlo.

Desde entonces he cambiado cosas, en la parte que ahora importa: la de decidir.

Escribo la especificación antes, y no por papeleo. Funciona como contrato: el artefacto principal deja de ser el software funcionando y pasa a ser esa especificación⁷. Lo que me convenció fue la parte que mide el otro lado. Cuanto menos clara es, más rellena el agente por su cuenta, y hay un umbral, alrededor del 70 %, que separa la zona segura de la de invención⁷. La ambigüedad se acaba rellenando, y es culpa nuestra, en cierto modo.

Dejé de aceptar el «ya está, funciona». Ahora pido el paquete: qué ficheros han cambiado, en qué entorno, qué pruebas se han ejecutado, qué huecos quedan abiertos⁶. Y dejé de leer el diff entero para comprobar si algo funciona.

La firma sigue siendo mía. Los agentes sintetizan y verifican; la autoridad para fusionar y desplegar, no: alguien se responsabiliza después de la verificación⁷. Elegir herramienta es lo de menos.

El otro lado

Aquí mi propia apertura se me vuelve incómoda, porque el bucle que a mí me desesperaba era, para mucha gente, el oficio.

Clive Thompson entrevistó para la revista del New York Times a más de setenta desarrolladores, y el resumen que saca es una gradación: muchos escriben mucho menos código; algunos, nada⁸. En una startup de dos personas la IA escribe el cien por cien de las líneas y dicen ir veinte veces más rápido que hace dos años⁸.

La frase que me dejó pillado es de Pia Torain: después de cuatro meses escribiendo cientos de instrucciones al día, empezó a sentir que perdía su capacidad de codificar. Lo que hizo no fue dejar la herramienta, sino imponerse leer entera la arquitectura del programa antes de aceptar nada. Si no lo usas, lo pierdes⁸.

Lo noto en algo muy concreto: estoy aprendiendo Rust. Si dejo que el agente escriba lo que quiero aprender, dentro de un año no sabré escribirlo. Y lo que se pierde no es la sintaxis, es el criterio para mirar una salida y decir «eso no está bien, hazlo otra vez»⁸. El bucle que a mí me sobraba es exactamente donde se fabrica ese criterio, y es la parte de mi apertura que no tengo resuelta.

Y está la cuenta que cae cerca: en las ocupaciones más expuestas a la IA, el empleo de los que tienen entre 22 y 25 años ha caído un 16 % relativo⁹. La puerta no se le está cerrando a los que ya estamos dentro. Se deja de abrir para los que venían.

Del dato de productividad casi nadie cita el conjunto, así que lo pongo entero: en 2025, un ensayo aleatorizado de METR midió que dieciséis desarrolladores experimentados tardaban un 19 % más con IA, cuando creían ir mucho más rápido¹⁰. En 2026 el seguimiento cambió el signo, con un 18 % y un 4 % más rápido y con intervalos que no cierran en ninguno de los dos casos¹⁰. No sabemos cuánto es, y esa es exactamente mi trampa: que el código funcione no me dice si estoy aprendiendo algo.

Tampoco es todo lamento. La mayoría de los entrevistados estaba encantada de no escribir a mano, y Kent Beck dijo que los modelos le habían devuelto las ganas⁸. Las dos cosas son verdad, y caben en el mismo párrafo.

El gimnasio

Si antes el ejercicio era ejecutar bien y ahora es saber qué crear, la pregunta que me hago ya no es si la IA escribe buen código. Es qué hago con la capacidad que me libera. Y aquí dejo de improvisar, porque llevo semanas anotando en el gimnasio algo que alguien puso en palabras hace dos días: cada serie. Peso, repeticiones, cuántas me quedaban en el depósito. No es afición a los números. Si no mido, no sé si progreso, y el progreso es el único indicador que tengo de que estoy haciendo lo correcto. Con el código llevaba meses sin medir.

El argumento que yo no había sabido montar es de Eero Alvar, en un vídeo de ocho minutos. Cuando una máquina quita la necesidad de una capacidad, esa capacidad pasa a ser una elección, y en cuanto es voluntaria se puede optimizar. La Revolución Industrial se llevó el trabajo físico de la vida diaria: el cuerpo dejó de ser necesario para sobrevivir y apareció el gimnasio moderno, un sitio para imponerse a voluntad una carga que ya no venía impuesta. El desarrollo del músculo pasó a ser el objetivo, el entrenamiento se convirtió en ciencia, y el patrón se repitió en la lucha cuerpo a cuerpo (artes marciales), en cubrir distancias (atletismo) y en escribir a mano (caligrafía)¹¹.

El caso cerrado es el ajedrez: cuando los motores superaron a los humanos en cálculo no desaparecieron los jugadores, se convirtieron en su equipo de entrenamiento, y el nivel humano subió. Y el detalle que me hizo cerrar este texto es el press de banca: los levantadores de la Edad de Bronce tenían el pecho plano porque la máquina no se había inventado¹¹. No era falta de esfuerzo. Era falta de equipo.

Hay dos cosas que no pienso delegar: el bucle de las tres de la mañana (sistema caído, hipótesis, prueba, hipótesis siguiente, que es el oficio de verdad y no se aprende leyendo¹) y la firma del despliegue, que es donde la responsabilidad lleva mi nombre⁷. Y hay una que delego encantado: todo lo que no quiero aprender.

El gimnasio no es una metáfora para cerrar un texto. Es lo que hago desde hace años, y es lo único del cuadro que no depende de una predicción: cargar a propósito lo que ya nadie me obliga a cargar. Cuánto tardará el ciclo en estabilizarse, qué se llevará la siguiente capa de trabajo, si los números de productividad acabarán dándole la razón a alguien: eso se puede medir, o se puede dejar pasar. Saber qué crear, no.

Referencias