He pasado la mayor parte de mi carrera metido hasta los codos en código legado. Sistemas que ya nadie entiende por completo, escritos por personas que dejaron la empresa hace una década, sostenidos por comentarios como: “no toques esto, funciona”. Así que créanme cuando digo que no me entusiasma fácilmente la próxima gran novedad en el desarrollo de software.
Pero hace unos meses me ocurrió algo que no puedo dejar de pensar.
Necesitaba construir un módulo. Normalmente habría abierto el editor y empezado a escribir código, resolviendo los detalles sobre la marcha, como hacemos todos. Esta vez probé algo diferente. Primero escribí una especificación. No una especialmente elegante, solo un documento de texto plano describiendo lo que debía hacer el sistema. Luego se la di a una IA y le hice una sola pregunta: ¿dónde es ambigua, incompleta o contradictoria esta especificación?
Encontró problemas. Muchos.
Casos que no había considerado, dos párrafos que se contradecían silenciosamente entre sí, una regla de negocio que se desmoronaba en los casos límite. Corregí el documento y volví a preguntar. Y otra vez. Y otra más.
Después de varias rondas tenía algo que nunca había tenido en más de veinte años construyendo software: una especificación sin agujeros.
Entonces vino la segunda parte. Le entregué a la IA tres cosas: la especificación final, un patrón para las pruebas de validación y un breve texto describiendo el objetivo final, el propósito real de todo aquello.
Lo que recibí de vuelta fue el producto completo. Con pruebas. Con una verificación de que el objetivo se había cumplido.
Yo no escribí el código.
Escribí la verdad sobre lo que el código necesitaba ser.
Y aquí viene la parte que debería incomodarnos un poco a todos. El trabajo difícil en ese proceso no fue técnico en el sentido tradicional. No hubo algoritmos ingeniosos, ni magia con frameworks, ni conocimientos de sintaxis involucrados.
El trabajo difícil fue pensar con claridad.
Decir exactamente lo que uno quiere decir.
Detectar las propias contradicciones antes de que la realidad las detecte por uno.
Esa es una habilidad distinta de aquella para la que la mayoría de nosotros fuimos contratados.
Durante décadas, el cuello de botella del software fue la traducción. Alguien tenía una idea y un programador la traducía a algo que una máquina pudiera ejecutar. Construimos una industria entera, carreras enteras e identidades enteras alrededor de ser buenos traductores. Cuanto mejor conocías el lenguaje de la máquina, más valioso eras.
Ese cuello de botella está desapareciendo.
Y no lentamente.
Creo que dentro de unos pocos años el flujo de trabajo con el que me topé será simplemente la forma en que se construya software: refinar una especificación hasta que no tenga inconsistencias, definir cómo se validará el éxito, establecer el objetivo y dejar que la máquina haga la traducción.
El artefacto importante ya no será el código.
Será el documento.
Entonces, ¿qué ocurre con los programadores?
La respuesta sincera es que los programadores, tal como los conocemos, van a desaparecer.
Sé cómo suena eso. La gente dijo lo mismo de los desarrolladores COBOL, y algunos de ellos todavía facturan excelentes tarifas por hora. Pero esto no es un cambio de lenguaje ni de framework. Es la propia capa de traducción la que se está volviendo automática.
Cuando eso sucede, saber escribir código deja de ser una profesión y pasa a ser lo que fue saber operar una central telefónica manual: una curiosidad histórica.
Lo que sobrevive —y se vuelve enormemente más valioso— es otra cosa.
La capacidad de especificar.
Tomar una intención humana difusa y convertirla en una descripción precisa, completa y coherente del comportamiento esperado.
Anticipar casos límite.
Definir qué significan realmente “terminado” y “correcto”, por escrito, antes de que exista nada.
Diseñar validaciones que no puedan ser manipuladas.
Si lo pensamos bien, los mejores ingenieros siempre hicieron esto. Escribir código nunca fue el verdadero trabajo. El trabajo era pensar, y escribir código era simplemente la forma de demostrar que se había pensado.
La IA no elimina el pensamiento.
Elimina la prueba de trabajo.
Mi consejo para cualquiera en esta industria, especialmente para los más jóvenes, es este:
Dejen de medirse por la velocidad con la que programan.
Empiecen a medirse por la claridad con la que pueden describir un sistema que todavía no existe.
Practiquen escribir especificaciones y luego atacarlas como si fueran revisores hostiles.
Aprendan a definir criterios de aceptación tan precisos que una máquina, o un desconocido, pueda verificarlos sin tener que hacerles una sola pregunta.
Los programadores que hagan esa transición no perderán sus empleos.
Perderán sus títulos de trabajo y obtendrán otros mejores.
A los que sigan insistiendo en que el trabajo real es teclear código…
Bueno.
He mantenido su código durante veinte años.
No lo voy a extrañar.