- Durante más de 50 años se han repetido los intentos de simplificar el desarrollo de software para reducir la dependencia de los desarrolladores
- Desde COBOL en los años 60 hasta las herramientas CASE, Visual Basic, el low-code/no-code y, más recientemente, los asistentes de código con IA, se repite el mismo patrón
- Cada tecnología ha mejorado la productividad, pero el proceso de pensamiento necesario para manejar la complejidad sigue recayendo en las personas
- La IA potencia las capacidades de los desarrolladores, pero no reemplaza la comprensión de los problemas de negocio ni el criterio
- Estos intentos repetidos revelan no los límites de las herramientas, sino la complejidad del problema y, al final, que lo clave es invertir en la capacidad de pensamiento de las personas
El inicio de un patrón recurrente
- Cada 10 años aparece la promesa de que “esta vez desarrollar será más fácil”
- Después del programa Apolo en 1969, el software pasó a verse como una tecnología clave
- Pero quedó claro que el desarrollo requiere conocimiento especializado, concentración e inversión de tiempo
- Desde entonces comenzó el sueño persistente de “simplificar el desarrollo para reducir personal”
COBOL: la creencia de que el personal de negocio podría programar directamente
- COBOL, como indica su nombre Common Business-Oriented Language, fue diseñado para que las personas del área de negocio pudieran escribir código como si fueran frases en inglés
- Pero en la práctica, la complejidad de la lógica, las estructuras de datos y el diseño de sistemas siguió presente, y al final surgió una nueva capa de desarrolladores especializados en COBOL
- La visión de que “cualquiera puede programar” no llegó a cumplirse
Década de 1980: la promesa de generación automática con herramientas CASE
- Las herramientas CASE (Computer-Aided Software Engineering) surgieron con la promesa de generar código automáticamente a partir de diagramas
- Las empresas hicieron grandes inversiones esperando multiplicar por 10 la productividad
- Pero el código generado fracasó por problemas de rendimiento, dificultad de mantenimiento y desajustes con los modelos
- Como seguía siendo necesario entender la complejidad lógica, el problema no se resolvió
Década de 1990: el enfoque de Visual Basic y Delphi
- Permitieron crear interfaces con facilidad mediante arrastrar y soltar, reduciendo la barrera de entrada al desarrollo
- Las aplicaciones simples eran posibles, pero para sistemas complejos que requerían integración, seguridad, rendimiento y mantenimiento, seguían siendo necesarios desarrolladores experimentados
- Como resultado, la demanda de desarrolladores no disminuyó; más bien se amplió
Desde los 2000: frameworks web, low-code y no-code
- Ruby on Rails impulsó la idea de “convención sobre configuración”, y las plataformas low-code/no-code promovieron el “desarrollo sin código”
- En ciertos ámbitos lograron más velocidad y una participación más amplia, pero la necesidad de desarrolladores profesionales siguió creciendo
- La pregunta recurrente: “¿por qué este patrón sigue repitiéndose?”
La naturaleza de la complejidad
- El software puede parecer simple a primera vista, pero en realidad la complejidad explota en los detalles y el manejo de excepciones
- Ejemplo: conflictos en la reserva de inventario, fallas de pago, interrupciones del servicio de correo electrónico
- Ese juicio sobre los detalles es precisamente la esencia del desarrollo, y ninguna herramienta puede eliminarlo
Un nuevo capítulo en la era de la IA
- Los asistentes de programación con IA generan código en lenguaje natural y también ofrecen explicaciones, depuración y sugerencias de mejora
- Esto representa un avance real, pero aun así la definición del problema, la seguridad, la integración y las decisiones de mantenimiento siguen siendo tareas humanas
- La IA amplifica la productividad de los desarrolladores, pero no reemplaza el criterio ni la comprensión del contexto
Una capacidad de desarrollo que sigue siendo escasa
- Aunque la tecnología ha avanzado a pasos agigantados, la demanda de software supera a la oferta
- Las empresas buscan “formas de crear más, más rápido” y depositan sus expectativas en herramientas para simplificar el desarrollo
- Pero el cuello de botella no está en la velocidad de escritura ni la sintaxis, sino en la capacidad de pensar la complejidad
La pregunta que deben hacerse los líderes
- La cuestión no es “¿esta herramienta reemplazará a los desarrolladores?”, sino
- “¿ayuda a resolver problemas complejos?”
- “¿reduce el trabajo repetitivo para enfocarse en problemas creativos?”
- “¿requiere aprender nuevas habilidades?”
- Estas preguntas permiten reconocer los límites de las herramientas y la inevitabilidad del pensamiento humano
La lección de 50 años: el problema no es mecánico, sino intelectual
- COBOL simplificó la sintaxis, CASE eliminó el tipeo, y la IA genera funciones completas, pero la dificultad esencial sigue intacta
- El desarrollo de software es el acto de concretar el pensamiento, y eso no puede ser sustituido por herramientas
- Igual que en el diseño arquitectónico o el diagnóstico médico, el proceso de pensamiento en sí es el valor central
La dirección a seguir
- Seguirán apareciendo nuevas herramientas, pero lo más importante es invertir en la capacidad de pensamiento de las personas
- Hay que experimentar con IA, low-code y nuevos frameworks, pero también convertir la capacidad de entender la complejidad en una competencia central de la organización
- Como en el programa Apolo, la precisión del pensamiento más que la herramienta es el factor decisivo del éxito
Por qué el sueño continúa
- El “sueño de reemplazar a los desarrolladores” no es un fracaso, sino un optimismo que impulsa la innovación en herramientas
- Cada intento ha fracasado en el reemplazo total, pero ha creado una nueva generación de herramientas útiles
- COBOL expandió el desarrollo de sistemas de negocio
- CASE impulsó el modelado visual
- Visual Basic amplió la accesibilidad al desarrollo
- La IA está impulsando cambios en la forma de desarrollar
- Al final, la limitación no está en las herramientas, sino en la complejidad de los problemas que intentamos resolver
- No hace falta rechazar las nuevas herramientas; hay que reconocer la importancia de tener expectativas realistas y del juicio humano
5 comentarios
Opiniones de Hacker News
Al ver esta ola de innovación en IA, uno se da cuenta de que gran parte de la programación no es complejidad esencial, sino complejidad accidental
Es un fenómeno donde lo que para los humanos es trabajo conceptual se convierte en trabajo procedimental para la IA
Por ejemplo, antes había que aprender varios conceptos para escribir
public static void main(String[] args), pero para una IA basta con darle el prompt “escribe el método de entrada de la clase” para que genere ese código casi con total certezaMientras que el trabajo procedimental difícil para los humanos es fácil para la IA, la sociedad está estructurada en torno a ese tipo de trabajo procedimental, así que cuando la innovación se expande alguien sube y alguien sufre
La idea de que “el no-code va a reemplazar a los desarrolladores” se repite cada cierto tiempo, pero en la práctica siempre ha terminado creando más empleos para desarrolladores
COBOL, VB, Squarespace y ahora la IA: cuando las herramientas bajan la barrera de entrada, más gente intenta construir algo y, cuando llega al límite, termina necesitando a un desarrollador de verdad
El trabajo simple y repetitivo desaparece, pero definir qué construir y depurar sigue siendo necesario
Si la IA puede programar por sí sola proyectos complejos, la demanda de desarrolladores podría bajar porque los humanos ya no tendrían que preocuparse por los detalles
Antes hubo grandes tendencias como internet, la nube, lo móvil y el machine learning, pero no está claro que en el futuro sigan apareciendo “grandes problemas” de ese tipo
En los últimos 20 años, en administración de sistemas se ha visto el mismo patrón
Se repite la promesa de que “una abstracción más alta democratiza el trabajo del experto”, pero en la práctica lo que ocurre es una reinvención costosa
Se dice que herramientas como Kubernetes ocultaron la complejidad, pero al final los desarrolladores vuelven a aprender los mismos problemas de una forma más cara sin conocer los conceptos básicos
Excel es el ejemplo típico: produjo errores terribles, pero triunfó gracias a su accesibilidad
Al final queremos “la accesibilidad de Excel y la confiabilidad de la ingeniería” al mismo tiempo, pero no podemos tener ambas
En realidad, al crecer la escala, también subió el nivel de complejidad del trabajo
La razón por la que este patrón se repite son los incentivos del mercado
Las empresas tienen que vender la IA como una solución total para que suba el precio de sus acciones, así que el sistema termina vendiendo creencia más que rendimiento real
Cuando finalmente se vea la realidad, el mercado se volverá caótico
En realidad sí se podría haber reducido la cantidad de desarrolladores
Si las empresas hubieran sido más selectivas al contratar e invertir en capacitación
Pero la realidad fue la contraria, y los frameworks web se crearon más para reducir costos de formación y ampliar el pool de talento que para mejorar la productividad
La gerencia media y los ejecutivos ven a los departamentos técnicos solo como centros de costo
Por eso mencionan la IA en todos los comunicados de prensa mientras hablan de recortar costos laborales
En realidad, no están reduciendo costos por la IA, sino por el reemplazo con personal offshore
Los equipos onshore que quedan están cargando con más trabajo y elevando la productividad
La causa no es la reducción de costos laborales, sino una contracción general de la inversión
Al final, la IA estaría absorbiendo capital en inversión de centros de datos y eso reduce empleos
El objetivo de la IA no es reemplazar a los desarrolladores, sino elevar el nivel de abstracción para abordar problemas más complejos
Desde la programación por cableado en las primeras computadoras, pasando por ensamblador, C, Python y los frameworks, los desarrolladores han ido trabajando cada vez en problemas de más alto nivel
Pero hay una diferencia: todas las etapas anteriores eran transformaciones deterministas y verificables, mientras que la IA generativa es no determinista
Como lectura relacionada, vale la pena revisar The Story of Mel
En un LLM no puedes ver tokens, AST, IR, etc. como sí en un compilador, así que es opaco
Un sistema no determinista basado en lenguaje natural no es lo mismo que las abstracciones de generaciones anteriores
Por eso la analogía de “pasar de ensamblador a C” no es adecuada
Como decía Dijkstra, la ciencia es odiada porque es difícil, y también se odia a los científicos que tienen ese poder
Enlace al texto original EWD1041
En sentido contrario, los desarrolladores siempre han soñado con automatizar los trabajos no técnicos
La IA es la versión más reciente de ese sueño
A inicios de los 2000, en la universidad Rational Rose UML era una materia obligatoria
En ese tiempo, el CEO de una startup decía que “ahora basta con dibujar diagramas y el código se genera solo, así que ya no hacen falta desarrolladores”
Pero al final esa predicción no se cumplió
Las máquinas crean código para las máquinas.
El castillo de arena que los humanos construyeron sobre el lenguaje de máquina está destinado a derrumbarse al final.
...aunque también se puede decir eso jajaja