- Desde NoCode hasta la IA, aparecen repetidamente tecnologías que prometen reemplazar a los desarrolladores, pero en la práctica lo que ocurre es una transformación del rol según cambia la tecnología
- NoCode no eliminó a los desarrolladores; creó especialistas en NoCode e integradores, y la nube dio origen al puesto avanzado de ingeniero DevOps
- Las herramientas actuales de desarrollo con IA están siguiendo un camino parecido, y la capacidad de diseñar la arquitectura de sistemas sigue siendo clave incluso en una era en la que la IA escribe código
- La IA es buena para la optimización local, pero débil en el diseño del sistema completo, y su velocidad de generación puede fijar rápidamente errores estructurales
- Al final, el reemplazo de desarrolladores no es más que una evolución y sofisticación derivadas del cambio en el stack tecnológico; el rol esencial sigue siendo necesario
From NoCode to AI-Assisted
- Cada ciertos años aparece una nueva tecnología que asegura que reemplazará a los desarrolladores de software
- Se repiten títulos similares cargados de expectativas exageradas, como "el fin de la programación", "ahora cualquiera puede crear una app" o "hasta un niño programa"
- Ejecutivos y consultores ponen atención a esta tendencia, y se empieza a mover el presupuesto
- Pero la realidad siempre ha sido no el “reemplazo”, sino la transformación
- Una y otra vez han surgido nuevos roles y profesiones más especializadas para manejar tecnologías más complejas, con una tendencia también al aumento salarial
- NoCode creó la expectativa de que se podrían construir aplicaciones sin especialistas, pero al final seguían existiendo problemas complejos como modelado de datos, integraciones y mantenimiento, y eso dio lugar a nuevos perfiles profesionales que los resolvieran
- La nube dio la impresión de que sería posible operar sin administradores de sistemas, pero en realidad terminó exigiendo la alta especialización de los ingenieros DevOps, y los salarios también subieron
- Con la IA pasa lo mismo: parece que “la IA escribirá el código”, pero en la práctica crece aún más la importancia de desarrolladores experimentados capaces de gestionar y orquestar la IA
El carrusel interminable de las promesas de reemplazo (The Endless Carousel of Replacement Promises)
Revolución NoCode/LowCode
- Surgió la revolución NoCode/LowCode, prometiendo que cualquier usuario podría crear aplicaciones con interfaces intuitivas
- Pero en el trabajo real aparecieron nuevos problemas: diseño del modelo de datos, integración con sistemas y bases de datos existentes, manejo de excepciones y mantenimiento
- Por eso empezó a ser necesario no un simple desarrollador, sino un especialista en NoCode que entendiera tanto el negocio como las limitaciones técnicas
- Estos profesionales reciben salarios más altos que los desarrolladores tradicionales
Revolución de la nube
- Hubo una gran expectativa de que al migrar a la nube ya no harían falta administradores de sistemas
- Pero la especialización en gestión de nube y la complejidad en realidad aumentaron
- Los administradores de sistemas tradicionales se transformaron en ingenieros DevOps, con mejores salarios y un nivel de trabajo más avanzado en automatización de infraestructura, pipelines de despliegue y gestión de sistemas distribuidos
- El trabajo no desapareció; evolucionó hacia nuevas formas
- Incluso en la transición a microservicios, la complejidad aumentó, y quedó claro que seguía siendo fundamental el papel de expertos capaces de gestionar sistemas en su base
Auge del desarrollo offshore
- Nació la idea de que el outsourcing internacional reduciría costos, pero aparecieron dificultades por problemas de comunicación, baja de calidad y falta de conocimiento del dominio
- Al final, la estrategia cambió hacia estructuras de equipos distribuidos, propiedad clara y arquitectura sólida, y eso llevó a que el costo total terminara siendo mayor de lo esperado al inicio
Revolución de los asistentes de programación con IA
- Ahora la gran promesa es que la IA generará código automáticamente
- En la realidad inicial, el código producido por la IA a menudo contiene errores sutiles y problemas de consistencia
- Los ingenieros senior dedican mucho tiempo a revisar y corregir los resultados de la IA, y mientras más experiencia tiene un desarrollador, más valor puede aportar
- Los sistemas construidos solo con ayuda de IA suelen carecer de una arquitectura sistemática
- Es decir, la tecnología no reemplaza al especialista; eleva su experiencia a un nivel de abstracción más alto
Por qué este ciclo es distinto
- El punto clave que mucha gente pasa por alto: el código no es un activo, es una deuda
- Cuanto más rápido y fácil se genera código, mayor es también la carga de mantenimiento, seguridad y refactorización
- La IA puede optimizar a nivel de función, pero carece de capacidad para diseñar el sistema completo
- Cuanto más se acelera la implementación, mayor es el riesgo de fijar rápidamente errores estructurales
- Al final, el verdadero activo incluso en la era de la IA es la capacidad de diseñar la arquitectura de sistemas, y eso no es algo a reemplazar, sino a potenciar
- La afirmación de que “la IA reemplazará a los desarrolladores” nace de los siguientes malentendidos fundamentales
- El hecho de que el código no es un activo, sino una deuda
- El código requiere mantenimiento continuo, validación, gestión de seguridad y reemplazo, y la deuda crece en proporción a la cantidad de líneas
- Que la IA pueda producir código rápidamente solo significa que puede generar deuda igual de rápido
- Es decir, la IA es buena para la optimización local (funciones, partes del sistema), pero es débil en diseño global y decisiones de arquitectura
- Cuanto más rápida sea la implementación, mayor es el riesgo de que un mal diseño se “solidifique” en todo el sistema
- Puede no ser un problema para crear sitios rápidos y de una sola vez, pero es crítico para sistemas que evolucionan a largo plazo
- El patrón de la innovación tecnológica sigue siendo el mismo
- Los administradores de sistemas se convierten en ingenieros DevOps, y los desarrolladores backend en arquitectos cloud
- Pero la IA acelera todo. La habilidad que sobrevive y evoluciona no es escribir código
- Es diseñar sistemas (Architecting systems). Y eso es precisamente lo único que la IA no puede hacer
19 comentarios
Soy una persona que trabaja de forma bastante conservadora, así que nunca he llegado a incorporar herramientas de IA en tareas importantes; más bien, lo único que cambié fue buscar en Google o en Stack Overflow por preguntarles a Gemini o a ChatGPT. Sí las uso, pero...
Cuando le pido a la IA que haga algo, creo que podría estar bien usarla de esta manera: pedirle funciones a nivel de una sola función, del tipo “si le das este input, que te devuelva esto”, y luego yo mismo escribir por mi cuenta la lógica para verificar si el valor de retorno que dio la función creada por la IA salió correctamente.
Soy escéptico ante la pregunta de si realmente es posible organizar todo el contexto en un formato que la IA pueda comprender bien. Las personas no solo tienen el contexto que superficialmente se necesita para el desarrollo que están haciendo en ese momento, sino también contexto latente, y desarrollan teniendo en cuenta esas partes; todavía no creo que una persona pueda plasmar ese contexto en expresiones bien depuradas. Pienso que no es tanto un problema de la IA como una limitación humana. Además, también creo que la capacidad de escritura de la gente hoy en día no es particularmente buena.
Lo que da miedo no es este instante, sino la tendencia, me parece..
Ahora es completamente distinto.
El futuro en el que todos los trabajos serán reemplazados está a la vuelta de la esquina, y los desarrolladores solo son uno de ellos.
Esto nunca ha sido una moda.
No habrá exactamente el mismo cambio.
Pero es una transformación por la que ya pasaron muchos oficios hace mucho tiempo, en la era moderna. Por ejemplo, la que vivieron los artistas con la aparición de la fotografía, o los artesanos con las fábricas automatizadas. La programación no parece ser diferente.
Yo espero que, cuando la innovación se vuelva algo cotidiano, al final se necesiten más ingenieros que ahora. Las expectativas de los usuarios van a subir y habrá que construir cosas más grandes y complejas. Tal como plantea la hipótesis de la Reina Roja.
Por supuesto, es muy probable que cambie el tipo de trabajo o que desaparezcan ciertas tareas específicas. Igual que en algún momento desapareció el oficio de cajista tipográfico. En ese contexto, diseñar sistemas probablemente sea una metáfora o un ejemplo de una abstracción que se ha elevado aún más.
Creo que es porque todos quieren reemplazar a los desarrolladores con algo.
Parece que hay bastantes personas que piensan que no hacen nada y aun así ganan mucho dinero.
Creo que, independientemente de si de verdad se reemplaza o no, la razón por la que ese tipo de contenido sigue circulando es porque resulta sensacionalista.
En la mayoría de los casos en que sacan titulares así de llamativos, desde el principio no parece que sean el resultado de una reflexión profunda sobre cuál es la realidad o cómo siquiera podría definirse eso de “reemplazo”.
Los análisis hechos con seriedad más bien terminan tratando hasta dónde puede llegar hoy la IA u otras herramientas y hacia dónde están evolucionando. Y, claro, la gente común no va a hacer clic en títulos tan poco emocionantes.
Hay muchos titulares sensacionalistas..
"Zuckerberg, que despide al 10% cada año: 'El próximo año la IA reemplazará a la mitad de los desarrolladores' [Silicon Valley View de Yoon Min-hyuk]"
https://m.sedaily.com/NewsView/2GRQ1RKIYC
"'Lo que mejor hace la IA es programar'… el primer objetivo de la reestructuración de MS son los desarrolladores"
https://n.news.naver.com/mnews/article/009/0005494133
"'¿Y si hasta perdemos el trabajo?' Esa preocupación se vuelve 'realidad'?… una industria que vive con ansiedad"
https://econmingle.com/economy/…
"[La elección de Yumi] 'No estamos contratando desarrolladores de software junior'… empresas que ya probaron el 'AI coding' comienzan a 'optimizar' sus organizaciones"
https://v.daum.net/v/20250522162617091
"'La IA hace análisis, diseño y programación'… LG CNS usará un 'programador de IA' en lugar de desarrolladores"
https://zdnet.co.kr/view/?no=20250528092405
Creo que hay que verlo como un reemplazo gradual.
Es cierto que está disminuyendo la cantidad de personas que se necesita incorporar para obtener el mismo resultado en una tarea.
Incluso en cuanto a "diseñar el sistema", si algo que antes hacían 10 personas ahora se resuelve con 8 personas + soporte de IA,
es una situación en la que 2 personas ya fueron reemplazadas.
También desde la perspectiva del diseño de sistemas
¿no será porque se mete en el prompting sin que normalmente se lo tome en cuenta?
El problema parece ser que no se maneja bien todo lo que viene después del vibe coding.
Estoy de acuerdo por experiencia personal. Al final, la IA también es una herramienta, así que del 1 al 99 es realmente rápida y buena, pero siempre da la sensación de que falta ese 1 restante.
Estoy de acuerdo, pero creo que el punto clave no es tanto el "diseño de sistemas" como la "resolución de problemas complejos mediante el diseño de sistemas".
Creo que las tareas fáciles se vuelven más fáciles y las difíciles siguen volviéndose más difíciles.
jajaja
Opiniones de Hacker News
A partir de una experiencia reciente corrigiendo como freelancer cosas como una "landing page de marketing desechable", se plantea que los clientes muy controladores siempre terminan agregando requisitos raros que la IA no puede manejar bien, y al final uno acaba arreglando el desastre; por más inteligente que se vuelva la IA, el problema del software no es técnico, sino que las personas siguen creando una y otra vez una “complejidad innecesaria”; al final, el arma más grande del desarrollador es decir “no”, aunque preocupa que, si compiten entre sí, las IA siempre terminen encontrando alguna que diga que sí
El software puede implementarse perfectamente, pero si los requisitos en sí no reflejan la realidad técnica, al final solo se genera caos: la clásica idea del “bug de requisitos”; la IA ya puede responder a limitaciones reales de formato o compatibilidad (por ejemplo, que gif no soporta transparencia), pero se piensa que los humanos seguirán escribiendo pedidos absurdos como “haz el logo como un cuadrado donde cada punto esté a la misma distancia del centro”; también se menciona como broma un error tipográfico de jpg
Entre el ‘no’ y el ‘sí’ existen 50 tonos de gris del tipo “¿esto está bien?”; se recuerda el caso de alguien que quería una página web “desde la que se pudiera descargar la base de datos”, cuando en realidad se refería a una simple exportación csv, subrayando la importancia de interpretar el contexto; queda la duda de si chatgpt puede captar bien ese tipo de matices
Decir “no” es realmente la parte más difícil y pesada del trabajo del desarrollador; muchos desarrolladores en realidad no disfrutan ese rol o sienten que ni siquiera es su trabajo; al final, el éxito real de un proyecto depende no de la tecnología, sino de la comunicación de ‘persona a persona’ con las partes interesadas, por lo que sigue existiendo la convicción de que siempre hará falta un ‘desarrollador que en la práctica también haga de PM’
Todo esto aparece muy bien explicado en el libro llamado ‘Peopleware’; por eso gusta tanto el saludo “ojalá todos tus problemas fueran técnicos”; en la práctica, los problemas que realmente se resuelven con código, salvo algunos casos extremos, casi nunca fueron tan difíciles
Hay quien opina que es un buen punto y que la IA potencialmente será cada vez mejor estimando complejidad y emitiendo advertencias; se usa como analogía el caso del ajedrez, donde la IA ya muestra capacidades de evaluación y juicio muy superiores a las humanas; aquí IA no se limita a los LLM, aunque se reconoce el avance dentro de esa categoría
Hay quien no está de acuerdo con la afirmación del artículo de que “la IA no puede diseñar sistemas (architecting)”; en realidad, la IA ya está mejorando cada vez más en esa área, y se señala que se sigue cambiando la definición de las condiciones necesarias para mover la discusión; aun así, la IA no puede decidir por sí sola qué debería querer, ni reemplazar la motivación del usuario (aunque sí puede proponer ideas); para que la sociedad funcione, alguien todavía tiene que querer actuar y resolver problemas, así que el rol del desarrollador cambiará, pero resolver problemas seguirá siendo tarea humana
Se dice que el significado de “desarrollador” está cambiando, pero desde otra mirada la esencia siempre fue la misma: programar es, en esencia, convertir requisitos ambiguos en código claro; a diferencia del pasado, los métodos cambiaron de machine code y tarjetas perforadas a frameworks, GUI y hasta herramientas visuales, pero escribir código sigue siendo lo más efectivo por su claridad y capacidad de comunicación; los LLM son buenos para repetir lo existente, pero cuando se intenta hacer algo completamente novedoso o explicarlo en lenguaje natural, resultan frustrantes; el mercado está en pleno hype, pero este patrón de cambios parciales se repite cada vez que aparece una nueva tecnología
Ya se perciben cambios, como empresas que están reduciendo la contratación de juniors por la IA; si la IA hace todo salvo el architecting, entonces en la práctica se termina necesitando a menos ingenieros
Se afirma de forma tajante que la IA todavía no puede hacer architecting; se distingue entre architecting y planning: planning es asignar restricciones, soluciones y recursos, además de anticipar; se sostiene que la IA todavía está lejos de poder hacerlo eficazmente; el architecting real implica diseños cooperativos y competitivos en múltiples capas, y si la IA falla en una sola capa, todo el sistema puede desviarse; se enfatiza que solo los humanos pueden diseñar y supervisar ese tipo de sistemas con seguridad
También hay quien opina que, si se le da suficiente contexto, la IA puede entender bastante bien lo que uno quiere; esto enlaza de hecho con advertencias sobre privacidad: si una organización controla sistemas potentes y tecnologías conscientes del contexto, lo más inquietante es que la IA podría llegar a predecir “lo suficiente” tus deseos o incluso tu siguiente acción
Se señala con franqueza que la IA no está haciendo architecting, sino apenas simulación, y que en muchos casos ni siquiera programa bien
Se argumenta que la propia suposición de que los negocios valoran la calidad es errónea; las empresas solo consideran la rentabilidad y ofrecen alta calidad únicamente si el cliente la quiere; sinceramente, los clientes también suelen preferir el producto con la ‘mejor’ relación precio-beneficio antes que la calidad, así que compran la herramienta más barata en Amazon y siguen produciendo repetidamente código flojo parecido (vibe code); al final, el único grupo que realmente se preocupa por la calidad son los ingenieros, por lo que desde esta postura se puede ignorar sin problema cualquier predicción de futuro basada en que la calidad importa desde la perspectiva del ingeniero
Hay quien responde que la calidad sí puede ser un factor diferenciador; se subraya que, cuando apareció el iPhone, aunque había competidores con muchas más funciones, al ofrecer una UI más fluida y pulida terminó aplastando al mercado
Se presenta a Fractal Audio como la empresa orientada a la calidad favorita de alguien: una compañía pequeña que fabrica modeladores de hardware para guitarra (simuladores de amplificadores y pedalboards), con actualizaciones innovadoras sucesivas y un CEO obsesionado con el rendimiento del modelado analógico; ofrece una calidad muy superior a la de las grandes empresas y se posiciona mediante venta directa y actualizaciones gratuitas de algoritmos, sin comisiones, suscripciones ni marketing con celebridades; se la pone como ejemplo vivo de una firma que ganó cuota de mercado gracias a la calidad, y como prueba de que no todos los negocios compiten solo por ‘lo más barato y de peor calidad’
Se rebate la idea de que a los clientes no les importa la calidad: si la calidad fuera irrelevante, entonces todas las startups habrían triunfado simplemente creando productos baratos e incompletos, con ventas enormes y gran éxito
Se enumeran productos de software exitosos que en realidad tenían muy buena calidad: Google, iPhone, Stripe, Notion y otros productos que han sobrevivido mucho tiempo en el mercado no son lentos ni están plagados de bugs; más bien, se considera que la calidad fue un factor de éxito, y se cuestiona no haber oído ejemplos en sentido contrario
Aunque hasta cierto punto la calidad podría difuminarse por la modularización, las suscripciones o la conexión permanente a internet, preocupa la posibilidad de un futuro donde todo se derrumbe de golpe: dispositivos convertidos en ladrillos, sitios sencillos que tardan 12 segundos en cargar, infraestructura social y sistemas gubernamentales inestables pese a miles de millones invertidos, y un mundo donde las conversaciones cotidianas sean con LLM
Se recuerda que la vieja revolución organizacional basada en UML, donde “el arquitecto hace la especificación y el desarrollador rellena los espacios en blanco”, terminó creando sistemas demasiado complejos y perdiendo agilidad; luego apareció “Agile”, que también fue malinterpretado y derivó en micromanagement de desarrolladores, desconfianza y culturas organizacionales poco creativas; al final, se evalúa que los equipos exitosos, sin importar las herramientas o procesos, eran aquellos donde los no desarrolladores se interesaban sinceramente por el trabajo de los desarrolladores y resolvían juntos los problemas, mientras que los intentos de reducir la complejidad siempre fracasaron
Frente a la afirmación de que “el architecting es la habilidad más valiosa, pero también la parte que la IA no puede reemplazar”, hay quien responde que, cuando se le pide explícitamente a la IA que diseñe una arquitectura de sistema, a menudo produce resultados mejores que al menos el 30% de los diseñadores con los que se ha encontrado en la vida real; desde esta postura, el problema es que los usuarios de IA simplemente no suelen hacerle ese tipo de solicitudes
Los LLM actuales están entrenados sobre todo con muchas respuestas de nivel intermedio (best practice), por lo que naturalmente producen resultados mejores que los de un tercio de los diseñadores humanos: diseños sensatos y ‘correctos’ basados en sentido común; en cambio, en áreas completamente nuevas que no aparecen en los datos de entrenamiento o en industrias donde se exige alto rendimiento, se necesita más el pensamiento humano basado en primeros principios, y se predice que incluso un kernel de base de datos diseñado por un LLM se quedaría en algo básico antes que innovador
Se critica el estilo del propio artículo por parecer escrito con ChatGPT: frases cortas, repeticiones, demasiados recursos del tipo “no es X sino X+1” o “no es X sino anti-X”; también sorprende que en HN este tipo de textos reciba tantos upvotes
Se interpreta la postura del autor como ‘wishful thinking’ nacido de creer, o de la arrogancia de creer, que su propia habilidad (architecting) es inmutable e irremplazable; se comenta con ironía que, si hubiera sido especialmente bueno en otra cosa, habría considerado esa otra habilidad como la imposible de sustituir
Se resume que la esencia de un arquitecto es la capacidad de entender con precisión los requisitos y restricciones y reflejarlos en el sistema; es decir, saber escribir buenos prompts, leer correctamente las respuestas y, cuando haga falta, rebatirlas con firmeza
Se apunta que muchos de los ‘arquitectos’ encontrados en la realidad carecían de verdadera experiencia en infraestructura IT y creían que bastaba con manejar herramientas de diagramación o Excel, lo que revela una falta de capacidad real; parecían managers, pero en la práctica solo unos pocos podían desempeñar la labor esencial
Hay quien opina que las empresas que dependen ‘demasiado’ de la IA en realidad aumentan su exposición a la ola de innovación; en la era de la IA, más que la productividad al generar código, lo central es gestionar la calidad del código, pero el mercado está demasiado enfocado en la producción automática; se menciona la declaración de Satya Nadella de que “el 30% del código de Microsoft está escrito por IA”, así como la tendencia de más de 20 incidentes mensuales en Github (enlace de referencia: githubstatus.com/history); se anticipa que las empresas que persigan solo eficiencia terminarán pagando el costo de la baja calidad, y que ese riesgo es especialmente alto para empresas pequeñas y medianas, no para gigantes del tamaño de Microsoft
Como contraargumento, hay quien piensa que las empresas que ignoren la IA serán las que más sufran
También se sostiene que “las empresas que abusan de la IA acaban cargando con costos mucho mayores a largo plazo”, y se comparte un artículo relacionado (AI: Accelerated Incompetence)
Hay un 100% de acuerdo con la idea de que “el código no es un activo, sino una deuda”; el objetivo es lograr el resultado con la menor cantidad posible de código, y preocupa que la IA, al facilitar demasiado la producción de código, termine aumentando mucho más la deuda de código
Se comparte un enlace de Wikipedia sobre la paradoja de la productividad tecnológica, es decir, el fenómeno por el cual aumenta la productividad pero la eficiencia real se compensa por el incremento de la complejidad del sistema (Productivity paradox)
Se compara la actual era de generación de código con IA con la época en que se hacían sitios web con MS FrontPage, cuando el html estaba lleno en un 90% de código inútil: la ‘era del cruft’
También se plantea una idea contraria: si ahora el código puede reemplazarse tan fácilmente, quizá la perspectiva de verlo como deuda pierda sentido; en el futuro, cuando haya un error, el programador simplemente podría pedirle a la IA que reescriba el código, lo que reduciría la carga
Alguien comparte además una visión del código como expresión creativa y artística: al ver código legible y elegante, podía sentir de inmediato cierta belleza
Se comparte un enlace recordando que, ya en los inicios de FORTRAN (1954), existía el eslogan de que “Fortran eliminará el propio proceso de codificación y depuración” (BackusEtAl-Preliminary Report)
La suposición de fondo en todas estas discusiones es que el progreso tecnológico pronto llegará a un límite; pero si eso es falso, entonces no hay razón para pensar que algún día la IA no pueda comprender y diseñar el negocio de forma integral, entendiendo toda la infraestructura, los logs, las finanzas y la documentación; dado que los modelos de IA siguen aumentando y se vuelven mejores y más baratos, esta postura se inclina más hacia la idea de que eventualmente alcanzarán incluso la esencia del reemplazo
Se plantea que los despidos de desarrolladores no se deben al avance tecnológico, sino a medidas posteriores derivadas de la incertidumbre, y que usar la tecnología o la IA como excusa es una justificación a posteriori; se pone como ejemplo que hace apenas cinco años las empresas estaban dispuestas a asumir costos con tal de aumentar la cantidad de ingenieros de software para elevar la productividad, por lo que se argumenta que el costo no es la causa fundamental
Busco a alguien que revise código hecho con vibecoding de IA. Ya está casi todo hecho, pero da errores; por favor corrijan solo un poco. Ya están saliendo pedidos de trabajo freelance así, pero suele ser más rápido hacerlo de nuevo.
Esto también me pasó a mí, y fue terrible...
No sé si es que no saben o no les importa, pero en fin, hay mucha gente así...
Con la traducción pasa lo mismo... ¿La IA sirve? Sí, pero parece que está haciendo sufrir a mucha gente...
A simple vista parece convincente, pero desde el punto de vista de quien tiene que corregirlo, el trabajo incluso aumenta más, snif snif
Qué escalofrío jajajaja