"X reemplazara a los programadores" desde 1959

Sabes que tienen en comun la frase "X reemplazara a los programadores" y la muneca Barbie? Las dos aparecieron en 1959.

Si, leiste bien. Los intentos de sustituir a los programadores con una "herramienta simple y accesible" son apenas unos anos mas jovenes que mi padre.

Y todo empezo, creelo o no, con... COBOL. Incluso su nombre significa Common Business-Oriented Language. El lenguaje prometia simplificar tanto el desarrollo de software para negocios que managers y analistas podrian escribir soluciones por su cuenta.

Eso no ocurrio. COBOL se hizo popular muy rapido: desato una ola de soluciones sencillas y esas soluciones se transformaron enseguida en sistemas complejos. Entonces aparecio lo obvio: hacian falta personas preparadas especificamente para trabajar con eso. Asi crecio la siguiente generacion de desarrolladores: la barrera de entrada bajo, pero la demanda de negocio exploto.

Despues llegaron otras olas parecidas. Lenguajes orientados al dominio. Herramientas CASE. Entornos visuales. Generadores de codigo. Plataformas low-code y no-code. Cada vez reaparecia la misma promesa: ahora si, esta vez si, los programadores ya no haran falta.

La historia siempre termina de una forma menos dramatica y mucho mas interesante. Las herramientas cambian el tipo de trabajo. No eliminan la necesidad de ingenieria.

Lo que realmente cambia cuando aparece una herramienta nueva

Cada gran salto en tooling mueve el trabajo humano a otro nivel de abstraccion. Se escribe menos de una cosa y mas de otra. Baja el coste de entrar, pero sube el valor de entender sistemas.

Con COBOL se prometia acercar programacion al negocio. Con CASE se prometia modelar y generar. Con no-code se prometia arrastrar bloques. Con LLMs se promete describir y obtener software.

Pero en todos los casos reaparece el mismo nucleo:

• alguien tiene que entender requisitos ambiguos;
• alguien tiene que resolver contradicciones;
• alguien tiene que decidir arquitectura;
• alguien tiene que asumir responsabilidad cuando el sistema falla.

Ese alguien sigue siendo una persona con criterio tecnico.

La ingenuidad de pensar que escribir menos equivale a entender mas

Mucha gente confunde "producir codigo" con "resolver problemas". Son cosas relacionadas, pero no son lo mismo.

Una herramienta puede generar lineas. Puede incluso generar bastante codigo util. Lo que no hace automaticamente es entender contexto organizacional, deuda heredada, limites del producto, tensiones del negocio y tradeoffs operativos reales.

Por eso cada vez que alguien dice que una nueva capa de abstraccion eliminara a los programadores, conviene hacer una pausa. La abstraccion no elimina complejidad. Muy a menudo la desplaza.

Lo que Serhii Babich acierta en esta lectura historica

La fuerza del argumento no esta en negar el impacto de las herramientas. Al contrario. Las herramientas si cambian profesiones, redistribuyen tareas y alteran el mercado.

Lo que no hacen es cancelar la necesidad de profesionales cuando el sistema empieza a importar de verdad.

Cuanto mas valioso se vuelve el software para negocio, mas caro resulta improvisar. Y cuanto mas poderosa es la herramienta, mas peligroso es usarla sin gente que entienda lo que esta pasando debajo.

LLMs no rompen el patron historico, lo repiten

Con los modelos actuales estamos viendo otra vez el mismo guion. Mucha gente interpreta la capacidad de generar codigo como si fuera equivalente a reemplazar ingenieria. No lo es.

Los LLMs aceleran borradores, explicaciones, pruebas, refactors pequenos, exploracion y documentacion. Eso es real.

Pero tambien introducen ruido, seguridad falsa, soluciones plausibles pero incorrectas y una tentacion constante de saltarse el razonamiento porque "ya lo escribio la maquina".

Es decir: son herramientas potentes. Y precisamente por eso necesitan aun mas criterio alrededor.

La conclusion util

Cada vez que la industria vuelve a decir "ahora si van a desaparecer los programadores", conviene mirar atras. La historia no muestra desaparicion. Muestra transformacion.

Las herramientas reducen unas tareas y crean otras. Abren la puerta a mas gente y al mismo tiempo elevan el valor de quienes entienden mejor los sistemas.

No se trata de defender romanticamente la profesion. Se trata de leer la evidencia sin hype.

Los programadores no sobreviven porque escriban cada llave a mano. Sobreviven porque el trabajo real nunca fue solo escribir.

Y eso sigue siendo cierto hoy, igual que en 1959.