Por qué la IA no ha reemplazado a los ingenieros de software, y por qué no podrá hacerlo en el futuro

• La ingeniería de software es una de las profesiones donde la adopción de IA avanza más rápido, pero la narrativa de que cuando la IA alcance cierto nivel provocará despidos masivos no está respaldada por la evidencia actual
• En los casos de Block, Snap e Intuit, la IA apareció como justificación de los despidos, pero el trasfondo real estuvo más directamente ligado a la presión financiera, las exigencias de recorte de costos y la reducción de capas de gestión
• El desarrollo de software tiene una estructura sándwich de decisión, ejecución y entrega, y la IA comprime la capa de ejecución, pero las capas que deciden qué construir y validan/asumen responsabilidad por el resultado resisten fuertemente la automatización
• El “vibe coding” consiste en dejar el trabajo en manos de agentes sin supervisión ni revisión, mientras que los ingenieros reales usan agentes en un enfoque de ingeniería agéntica donde los humanos mantienen el control y la responsabilidad
• Si la IA reduce el costo de producir software, puede surgir más demanda de software, y aunque la carrera de cada ingeniero pueda volverse más inestable, es posible que la demanda total se mantenga fuerte

---

Por qué la IA no ha reemplazado a los ingenieros de software, y por qué no podrá hacerlo en el futuro

• Los agentes de código como tecnología normal

  • Hay mucha ansiedad e incertidumbre sobre si la IA reemplazará empleos, pero para analizar este problema conviene observar la profesión de ingeniería de software, donde la capacidad y adopción de IA han avanzado rápido
  • La narrativa de que habrá despidos masivos cuando la IA alcance cierto umbral de capacidad puede descartarse por falta de evidencia suficiente
  • Si esa narrativa no se sostiene ni siquiera en un sector con casi nulas barreras regulatorias, es probable que otras profesiones tengan amortiguadores todavía mayores
  • El trabajo del conocimiento y el desarrollo de software pueden verse como un decide-execute-deliver sandwich, y la IA comprime la capa de ejecución, pero las capas de decisión y entrega no se automatizan solo porque mejore la capacidad
  • Se puede tener un optimismo cauteloso sobre el futuro de la demanda de ingeniería de software, aunque una demanda total saludable no implica que la carrera de cada ingeniero sea estable

Los casos de despidos masivos en software atribuidos a IA se parecen mucho al típico “AI washing”

• Caso Block

  • Block anunció en febrero el despido de 4,000 empleados, y Jack Dorsey dijo que la IA permite equipos “más pequeños y planos”, mencionando mejoras en la capacidad de los modelos hacia fines de 2025
  • Luego, la cobertura mostró otro panorama: Block enfrentaba una fuerte presión financiera después de haber triplicado su plantilla durante la pandemia
  • Naoko Takeda, científica de datos del equipo de Cash App, escribió que Block empujó el uso de IA para todos, pero que las mejoras de productividad fueron muy limitadas, y renunció tras rechazar un aumento de retención del 75%
  • Otros empleados entrevistados tenían percepciones muy distintas sobre lo que la IA podía hacer en Block y sobre si Dorsey entendía realmente el tema
  • Aaron Levie señaló que los CEOs pueden construir prototipos rápidos, pero no ven el 90% del trabajo necesario para convertirlos en productos terminados, por lo que es fácil que se hagan ilusiones sobre la utilidad de la IA

• Caso Snap

  • Snap despidió a unas 1,000 personas en abril, y Evan Spiegel citó la IA como razón principal en el memo de despido
  • Spiegel dijo que el 65% del código nuevo había sido generado por IA
  • En realidad, los despidos ocurrieron después de una campaña de inversionistas activistas que exigían recortes de costos
  • Snap ha reportado pérdidas netas cada año desde su IPO de 2017, y en 2026 su acción había caído más de 30%
  • La reducción se concentró en eliminar 150 puestos de distintos tipos dentro del área de realidad aumentada, algo que no coincide con el patrón esperado de recortes generalizados en programación o funciones expuestas a IA si la causa hubiera sido realmente la IA

• Caso Intuit

  • Intuit anunció en mayo un recorte de 3,000 puestos, y al mismo tiempo se supo de sus acuerdos con Anthropic y OpenAI
  • La prensa lo vinculó a una reestructuración centrada en IA, pero el CEO respondió que los despidos no estaban relacionados con IA
  • Señaló que los recortes afectaban “roles con mucha coordinación” y capas excesivas de gestión
  • Los casos de Block, Snap e Intuit muestran que la IA se usa como justificación superficial de los despidos, mientras que la situación organizacional y la estructura de costos eran el trasfondo más directo

• El AI washing es un fenómeno de toda la economía

  • En cada historia revisada sobre despidos en ingeniería de software atribuidos a IA aparecía el mismo desajuste narrativo
  • El 59% de los gerentes de contratación en EE. UU. admitió que, al explicar congelamientos de contratación o despidos, poner el foco en la IA en lugar de en restricciones financieras resulta más aceptable para los stakeholders
  • J. P. Gownder, de Forrester, dijo que cuando pregunta a las empresas que se preparan para despidos por IA si ya tienen aplicaciones maduras y probadas de IA, nueve de cada diez no las tienen y ni siquiera han empezado
  • En una encuesta de HBR a más de 1,000 ejecutivos globales, el 21% dijo haber hecho grandes reducciones de personal “anticipando” la IA, y el 39% hizo recortes preventivos bajos o medios
  • Solo el 2% ya había hecho grandes reducciones relacionadas con implementaciones reales de IA, lo que muestra una gran brecha entre los recortes basados en expectativas y los recortes basados en despliegues reales

• Datos del WARN Act

  • El WARN Act exige ciertas divulgaciones para cierres de centros de trabajo y despidos masivos que afecten a más de 100 trabajadores
  • En marzo de 2025, el estado de Nueva York se convirtió en el primero de EE. UU. en agregar una casilla de divulgación sobre IA al formulario de presentación del WARN Act
  • Durante el primer año, más de 160 empresas presentaron notificaciones WARN, pero ninguna marcó la casilla de IA
  • A finales de mayo, según confirmación del Departamento de Trabajo de Nueva York, solo Nespresso había marcado esa casilla
  • Si los registros son correctos, de alrededor de 25,000 despedidos en el estado de Nueva York durante ese período, solo 46 se vieron afectados por IA, aproximadamente un 0.2%

• Los despidos son una mala señal para medir el efecto de productividad de la IA

  • Hay investigaciones que sugieren que el efecto de productividad de la IA opera más a través de una desaceleración en la contratación que mediante el despido de trabajadores existentes
  • Despedir personal actual implica perder el conocimiento tácito y el capital organizacional necesarios para usar la IA de forma efectiva
  • Además, los despidos son costosos por indemnizaciones, caída de la moral y riesgo de tener que volver a contratar
  • Con solo dejar actuar la rotación natural se puede lograr el mismo resultado en pocos años, por lo que los despidos masivos suelen ser innecesarios

• Datos de tendencias de empleo

  • Un paper de economistas de la Reserva Federal sintetiza la evidencia relevante en el contexto estadounidense
  • El empleo sigue creciendo, pero desde ChatGPT lo hace aproximadamente 3 puntos porcentuales anuales más lento que la trayectoria contrafactual sin IA
  • La metodología de ese estudio no captura el trabajo por cuenta propia, así que parte de la desaceleración podría haberse absorbido vía emprendimiento
  • Otros estudios ofrecen evidencia de que la IA facilita crear nuevas startups
  • El panorama real podría ser más saludable de lo que sugiere el estudio de la Reserva Federal

• Sí existen pérdidas de empleo vinculadas a IA, pero de otro tipo

  • Puede haber pérdida de empleos en ingeniería de software cuando la IA reduce la demanda de un producto
  • Chegg y Stack Overflow se citan como casos donde la IA redujo la demanda de productos de ayuda para tareas o soporte técnico, y ambas empresas hicieron despidos
  • En esos casos, la IA no realizó directamente el trabajo de los empleados, sino que redujo la necesidad de ese trabajo
  • De las 270 ocupaciones del censo de EE. UU. de 1950, solo una desapareció por automatización —el operador de ascensor—, pero varias sí se volvieron innecesarias por nuevas tecnologías, como los telegrafistas
  • Los despidos en empresas que venden IA, como IBM o SAP, se parecen más a reestructuraciones corporativas normales para mover personal desde funciones existentes hacia líneas de producto de rápido crecimiento que a reemplazo directo de trabajadores

Por qué los agentes de código no han llevado al reemplazo laboral: el sándwich decide-execute-deliver

• El porcentaje de código escrito por IA casi no se relaciona con el reemplazo laboral

  • Algunos líderes tecnológicos presentan el porcentaje de código escrito por IA junto con despidos o proyecciones de futuras pérdidas de empleo
  • Ese enfoque refuerza la idea simplista de que, si la IA escribe todo el código, entonces ya no hacen falta programadores
  • Pero el porcentaje de código escrito por IA casi no tiene relación con la métrica clave para evaluar reemplazo laboral
  • Escribir código no era el cuello de botella, y nunca lo fue

• Escribir código no era el cuello de botella

  • Un paper de 2019 que sintetizó investigaciones previas concluyó que, según el estudio, los desarrolladores dedicaban sorprendentemente poco tiempo a programar: entre 9% y 61%
  • Ese resultado coincide con datos internos de Microsoft sobre 6,000 desarrolladores
  • Después de que empezara la adopción de agentes de código, varios textos hacia fines de 2025 señalaron que escribir código no era el cuello de botella
  • Los desarrolladores reconocen que, aunque los agentes escriban la mayor parte del código, el impacto en la productividad total puede ser pequeño

• Tres cuellos de botella reales

  • El cuello de botella real está en decidir y especificar qué construir
  • También es un cuello de botella clave validar el resultado entregado y asumir responsabilidad por él
  • La comprensión humana profunda del codebase, del negocio y del entorno es necesaria tanto para decidir como para entregar
  • El trabajo del ingeniero de software es un sándwich de decisión, ejecución y entrega, y la comprensión es la condición previa para las tres capas
  • La IA comprimió el centro del sándwich, pero los extremos permanecen en gran medida igual

• Evidencia de “Writing Code vs. Shipping Code”

  • Writing Code vs. Shipping Code analiza el efecto de productividad de la IA en 100,000 desarrolladores de GitHub
  • Los agentes de IA multiplicaron por 8 la cantidad de líneas de código escritas, lo que coincide con la idea de que la capa de ejecución se comprime fuertemente
  • Pero los releases solo aumentaron 30%, lo que sugiere con fuerza que los cuellos de botella humanos en decisión y entrega siguen ahí

• La capa de decisión difícilmente puede adelgazarse mucho más

  • Los equipos de desarrollo tienen que decidir qué construir
  • Una de las lecciones importantes que aprende un ingeniero de software junior es que especificar requerimientos toma más tiempo del esperado
  • Comprimir la especificación de requerimientos genera más dolor en etapas posteriores
  • Esta capa es difícil de automatizar porque debe considerar necesidades de usuarios, señales del mercado, prioridades organizacionales y, a veces, restricciones regulatorias
  • A medida que la capacidad de la IA mejora, aumenta el tipo de decisiones que pueden delegarse a la IA, pero las decisiones delegables dejan de ser fuente de ventaja competitiva
  • El valor de la decisión humana se desplaza hacia niveles superiores, y como la complejidad del software aumenta con el tiempo, no hay un techo claro para este proceso

• La capa de entrega permanece por responsabilidad y validación

  • Los equipos humanos deben asumir responsabilidad por los resultados que entregan
  • En algún punto del futuro, quizá haya equipos que desplieguen código de misión crítica que no hayan probado ni entendido suficientemente
  • Hoy la IA es demasiado inestable, así que ese tipo de desorden representa una amenaza existencial para los equipos de software y sus clientes
  • Incluso si desaparece la barrera técnica, no hay necesidad de ceder el control humano a la IA
  • Es posible optar por mantener la responsabilidad humana mediante normas compartidas, leyes y políticas
  • La legislación de responsabilidad y las regulaciones sectoriales ya funcionan como barreras de velocidad, y podrían reforzarse

• El ingeniero de software del futuro se parecerá más a un operador de grúa

  • Cuanto más se delegue la capa de ejecución a la IA, más se parecerá el rol del ingeniero de software al de un operador de grúa
  • Los agentes de IA harán la mayor parte del trabajo cognitivo pesado, y el trabajo central del humano será supervisarlos y controlarlos
  • Algunos sostienen que un futuro con control humano no será viable por costos
  • Ya se han vuelto virales casos de agentes de código con poca supervisión que borran bases de datos en producción u ocasionan otros daños
  • Estos casos no son la nueva norma, sino excepciones que se difunden por lo impactantes que son, y funcionan como aprendizaje para desconfiar de una dependencia excesiva de la IA
  • Detectar si está aumentando el uso de IA con poca supervisión en tareas de alto riesgo es una importante laguna de datos no solo en ingeniería de software, sino en toda la economía

• La reducción de la programación no es un fenómeno exclusivo de la IA

  • La tendencia a comprimir el sándwich es nueva, pero no es resultado exclusivo de la IA
  • Hace más de 20 años, el Bureau of Labor Statistics empezó a seguir por separado programación e ingeniería de software
  • A grandes rasgos, los programadores se encargan solo de la ejecución, mientras que los ingenieros de software gestionan una parte más grande del sándwich
  • La programación se redujo, pasó a verse como trabajo de simple ejecución y quedó mucho peor pagada
  • La IA acelera una tendencia antigua y reduce todavía más el valor de la capacidad pura de ejecución técnica
  • El patrón en el que los humanos participan profundamente en los extremos de decisión y entrega, mientras la IA automatiza la capa media de ejecución, podría aplicarse ampliamente a todo el trabajo del conocimiento

Vibe coding no es lo mismo que ingeniería agéntica

• Confusión terminológica

  • El término “vibe coding” se usa de forma imprecisa para referirse a un amplio rango de prácticas, y eso genera confusión sobre los cambios en la ingeniería de software
  • En el verdadero vibe coding, el usuario le dice al agente qué hacer, pero no supervisa la ejecución ni revisa el código
  • Ese usuario puede no tener capacidad para revisar el código, o puede no evaluar el resultado salvo que falle de forma evidente
  • Eso es distinto de cómo usa agentes la mayoría de los ingenieros de software

• Ingeniería agéntica

  • La mayoría de los ingenieros de software usan agentes como herramientas mientras los humanos conservan el control y la responsabilidad por el resultado
  • Para referirse a esta práctica se está difundiendo el término agentic engineering
  • A medida que la ingeniería agéntica se vuelve estándar, los ingenieros descubren que supervisar agentes de código toma más tiempo de lo esperado
  • Simon Willison dijo que, tras supervisar agentes, ya hacia las 11 de la mañana se siente mentalmente agotado, algo que también coincide con la experiencia real

• Datos de SWE-chat

  • SWE-chat es un dataset de interacciones con agentes de código de desarrolladores open source que participaron voluntariamente en una herramienta de logging
  • En este estudio, el 44% del código generado por agentes sobrevivió hasta el commit final del usuario
  • Los commits hechos con vibe coding introdujeron vulnerabilidades a una tasa 9 veces mayor que los commits escritos solo por humanos
  • La intención de usuario más común no fue generar código nuevo, sino entender código existente, en una proporción de 19% frente a 13%
  • Como el dataset es una muestra autoseleccionada, no se pueden sacar conclusiones fuertes a partir solo de este estudio
  • Aun así, refuerza otras evidencias de que vibe coding e ingeniería agéntica son patrones distintos

• La diferencia clave

  • Vibe coding e ingeniería agéntica no son dos categorías completamente separadas, sino los extremos de un espectro
  • No todos los proyectos se dividen entre proyectos de una sola vez y proyectos de misión crítica
  • No todos los flujos de trabajo encajan exactamente en la columna izquierda o derecha de una tabla
  • La implicación clave para el tema del empleo es que las empresas no pueden contratar a un vibe coder no validado en lugar de un ingeniero de software para desplegar software de producción

Qué podría pasar en adelante

• Por qué es difícil que se cumpla el pronóstico de despidos masivos

  • Los defensores de la IA pueden argumentar que los despidos masivos todavía no llegan, pero que llegarán
  • Pero si el modelo del sándwich es correcto, esa predicción no se cumplirá
  • La IA ya comprimió fuertemente la capa media del sándwich, y esa compresión en realidad empezó hace décadas
  • Incluso si la capa de ejecución se volviera instantánea y perfecta, el cambio respecto al estado actual sería pequeño
  • Las razones por las que las capas de decisión y entrega resisten a la IA no dependen de límites de capacidad

• La demanda de ingenieros de software puede crecer

  • No solo es posible que la IA no elimine los empleos de ingeniería de software, sino que incluso podría aumentar la demanda
  • Si una mejora de productividad tecnológica reduce el costo de crear software, la gente compra más software
  • En términos económicos, el software tiene alta elasticidad precio
  • Si la IA no reemplaza a los ingenieros de software, una mayor demanda de software se traduce en más demanda derivada de ingenieros de software
  • “Jevons’ paradox” es el término económico que suele usarse en el discurso sobre IA para explicar este concepto

• Patrón histórico

  • El empleo de programadores en EE. UU. era casi cero alrededor de 1950, pero hoy suma millones
  • Eso contrasta fuertemente con ocupaciones como la agricultura, donde la mecanización y automatización sí redujeron drásticamente la demanda de trabajo
  • El consumo de calorías humanas es relativamente fijo, pero la cantidad de software producida ha aumentado un millón de veces
  • Un automóvil moderno contiene alrededor de 100 millones de líneas de código ejecutándose en varias computadoras a bordo
  • Aunque exista un techo para la demanda de código, hoy no estamos cerca de él
  • Casi todo trabajo cognitivo se beneficia del software, y al bajar el costo de programar, la IA está permitiendo crear utilidades puntuales tanto para trabajo como para uso personal

• Eso no significa que solo crecerá Big Tech

  • Puede haber mucho más software en el futuro y también más ingenieros de software, pero eso no significa que las grandes tecnológicas se harán todavía más grandes
  • Hoy, la mayoría de los ingenieros de software ya trabaja dentro de organizaciones internas de empresas que no son de software
  • Esa proporción podría crecer aún más
  • “AI rollups” se refiere a la idea de que firmas de venture capital o private equity compren negocios de Main Street, como consultorios dentales o despachos contables, y luego incorporen ingenieros de software o ingenieros de IA para rehacerlos como negocios AI-native
  • Esa idea podría terminar siendo puro hype, y todavía es demasiado pronto para juzgarla

• Respuesta a la predicción de democratización

  • Algunos predicen que la IA democratizará la ingeniería de software y reducirá la demanda de ingeniería de software
  • Según esa visión, tanto el software producido como el tiempo humano dedicado a producirlo aumentarán, pero ese trabajo lo harán personas que no son ingenieros de software
  • Por ejemplo, se piensa que alguien con formación legal podría crear software jurídico más fácilmente que alguien con formación en ingeniería de software
  • Ese argumento cae en la trampa de confundir vibe coding con ingeniería agéntica, y la capa de ejecución con el sándwich completo
  • Lenguajes del pasado como FORTRAN, COBOL y SQL también vinieron acompañados de expectativas de democratización de la programación, pero eso no ocurrió
  • La barrera no es aprender sintaxis, sino desarrollar el criterio experto necesario para tomar buenas decisiones manteniendo la responsabilidad

• Las carreras individuales sí pueden vivir una gran reestructuración

  • Con el tiempo, es probable que aumente el tiempo que las personas dedican a hacer cosas nuevas con computadoras
  • Esa actividad puede tomar la forma de construir software, gestionar workflows complejos con ayuda de agentes, u otras formas distintas
  • Las capacidades necesarias serán una combinación de habilidades de software, habilidades de IA y expertise de dominio
  • Aún no está claro si los ingenieros de software actuales serán quienes mejor se adapten a esos nuevos roles
  • Que la demanda total de trabajo en software siga fuerte no significa que los trabajadores individuales no vayan a verse afectados
  • La IA está generando un gran cambio estructural en la forma de producir software, y qué ingenieros salgan ganando o perdiendo dependerá del tipo de empresa donde trabajen, la región, el nivel de experiencia y la velocidad de adaptación

[GN⁺]

Opiniones en Hacker News

• A lo largo de toda la historia de la industria informática, hemos impulsado la automatización de la ingeniería de software de forma agresiva y entusiasta, y cada vez eso nos ha permitido crear cosas más grandes y mejores más rápido
  Cuando la productividad sube así, también aumenta el valor del trabajo y las expectativas, y hasta ahora la demanda mundial de software ha sido inagotable
  La razón por la que la IA no ha reemplazado a los ingenieros de software es que cada vez que aumenta la productividad, la meta también se mueve
  Hay dos formas en que esta dinámica podría terminar: la primera es que la productividad finalmente llegue a un punto donde pueda satisfacer toda la demanda mundial de software
  Todavía no hay evidencia de eso, y habría que explicar con claridad por qué esta vez sería distinta de toda la historia de la industria informática
  La segunda es que la IA, al actuar de forma autónoma, se convierta en un ingeniero de software superior al humano
  Es decir, una situación en la que IA+desarrollador humano no sea mejor que la IA sola; pero hasta ahora la evidencia apunta a que la IA es un amplificador para el desarrollador, y que para obtener buenos resultados hace falta que un experto marque la dirección mientras la IA hace hasta el 90%
  No hay evidencia sólida de que alguna de esas dos cosas vaya a ocurrir en el futuro cercano, así que parece que los ingenieros de software estarán seguros por un tiempo
  Aun así, si tu rango técnico es estrecho y te concentras en un área específica, por ejemplo el desarrollo web frontend, sí habría más motivo de preocupación
  Aunque la IA no reemplace a todos los ingenieros de software, es bastante probable que absorba por completo dominios específicos bajo la dirección de generalistas

  • Creo que el punto final del software no está tan lejos
    En conjunto, ya estamos creando más software del que la gente realmente quiere, y una parte importante de eso va desde basura hasta fraude descarado, e incluso cosas cercanas a lo malicioso
    Al final, parece probable que para pequeñas necesidades de software que la gente común sí tiene, como gestionar listas de tareas o sincronizar archivos, cada quien use su propia IA para escribir algo a medida, y que los ingenieros de software queden sobre todo para grandes proyectos empresariales
    Durante las últimas décadas, la tendencia dominante del software comercial ha sido una despersonalización extrema y antiusuario
    Se dejó un solo camino feliz, y si no se ajusta a tus necesidades, arréglatelas como puedas
    Casi no existe software comercial para la gente común, e incluso el open source se está alejando de los usuarios generales
    Pronto, la gente común podrá crear por sí misma software que resuelva sus problemas a su manera
    En la mayoría de los casos, la calidad y la precisión no importan tanto; importa más que sea personalizado, gratis y que no sea una plataforma invasiva de vigilancia y publicidad
  • El ejemplo del desarrollo web frontend me parece medio gracioso
    Como desarrollador frontend, creo que los modelos de punta actuales sí son buenos para el trabajo de plomería de backend aburrido que a mí no me interesa, pero todavía no sirven bien para el trabajo de diseño personalizado que los clientes realmente quieren
    No digo que alguien tenga claramente la razón o esté equivocado, y sí coincido en que tener un rango técnico más general es probablemente la mejor manera de tener éxito en esta nueva era
    Pero todavía no estamos en un punto donde los LLM dominen por completo una parte del stack al grado de que desaparezcan los especialistas de esa área
  • A diferencia de la idea de que “no se ve evidencia de que esto esté ocurriendo”, al menos en las tiendas de apps móviles ya se observa algo parecido
    Según análisis recientes, la cantidad de apps lanzadas ha aumentado mucho, pero el total de reseñas y descargas se ha estancado
    Es decir, hay muchas más apps, pero los usuarios no han aumentado mucho, o casi nada
    Basta con ver p40 / figure 12 de "WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS": https://www.nber.org/system/files/working_papers/w35275/w352...
    El análisis está en las páginas 42~43
    No se puede demostrar que el tamaño del pastel ya esté fijo, pero tampoco se puede demostrar lo contrario, que el pastel sea infinito
    El punto clave que la gente suele pasar por alto cuando habla del crecimiento económico del software es que el dinero tiene que venir de alguna parte
    Para que siga creciendo, alguien que hoy no paga por software tendría que empezar a pagar, y hay que ver quiénes son, cuánto dinero tienen y con qué otros gastos compite eso
  • Decir que “la demanda mundial de software ha sido inagotable” no significa que todo el mundo ande buscando siempre la tecnología más nueva y avanzada
    Muchas empresas todavía dependen de cosas como hojas de cálculo personalizadas o tecnologías como Microsoft Access
    Porque hacen exactamente lo que necesitan, el costo es fijo y casi no requieren cambios adicionales ni mantenimiento
    Si sales de la burbuja en la que estamos metidos, te das cuenta de que mucha gente no está interesada en actualizarse, sino en que lo viejo que ya conoce simplemente siga funcionando
  • Si la IA puede hacer el 90% del trabajo bajo la dirección de un experto, eso significa que el 90% de los desarrolladores se queda sin empleo
    Y tampoco veo por qué ese porcentaje no podría llegar al 99%

• La IA sin duda va a reemplazar a los ingenieros de software
  La parte que falta, como dice el texto, es la entrega y operación, y eso corresponde más al ámbito de DevOps/SRE/ingeniería cloud que al de los ingenieros de software
  Trabajo como ingeniero cloud, y varios amigos no ingenieros me han contactado para decirme que ahora pueden crear sus propios side projects desde cero en varios lenguajes y ejecutarlos como apps locales, web apps y apps nativas
  Lo que les falta es una plataforma para desplegar y mantener eso con la facilidad de un “desarrollador común”
  Ahora mismo, construir esa base sigue siendo bastante engorroso, pero con AGENTS.md, skills y pruebas integrales estrictas, es perfectamente posible
  Una vez que eso esté armado, un usuario no técnico puede seguir desarrollando sin contratar a un ingeniero de software, simplemente diciéndole a claude/codex lo que quiere
  claude/codex puede razonar en función de una arquitectura definida de antemano y guiar al usuario no técnico
  En mi experiencia anecdótica, la IA ya reemplazó a varios ingenieros de software
  Si esta base se convierte en producto, creo que los proyectos greenfield podrán gestionarse solo desde la perspectiva del producto, mediante agent coders y platform engineering
  Eso es el presente; solo hay que imaginar cómo será dentro de 5 años

  • Este tipo de razonamiento está muy extendido aunque no se entiende bien
    Que alguien no ingeniero traiga una app hecha por su cuenta no significa que la IA haya reemplazado o vaya a reemplazar a los ingenieros de software
    Puedes buscar síntomas en Dr. Google, probar cambios de hábitos, remedios herbales y medicamentos de venta libre, e incluso obtener resultados reales, pero eso no significa en absoluto que los médicos vayan a desaparecer
    Con IA generativa se puede hacer música sin teoría musical, sin oído musical y sin creatividad, pero eso tampoco hace desaparecer a quienes sí tienen talento musical
    Aunque puedas hacer proyectos DIY en casa con ayuda de IA, eso no significa que los ingenieros vayan a desaparecer
    ¿Quién ayudará a que los expertos de dominio aclaren lo que realmente necesitan mediante iteraciones de prototipo-mejora?
    ¿Quién va a escribir y mantener los sistemas operativos, lenguajes, sistemas de control de versiones, editores y emuladores de terminal, sistemas de gestión de conocimiento y documentación, plataformas PaaS, etc., de los que dependen los creadores de software por hobby?
    ¿Se ha probado correctamente lo que hicieron como para garantizar que es robusto?
    ¿Entienden las condiciones de borde que pueden aparecer?
    ¿La seguridad está bien resuelta?
    Producir algo rápido a punta de prompts no es lo mismo que hacer ingeniería
    Puede que no lo vean así porque caen en el error de pensar que el valor de la ingeniería de software está principalmente en el código producido, es decir, en el arreglo de bits en sí
    El valor principal de un proyecto está en el proceso de construir teoría y abstracciones: https://pages.cs.wisc.edu/~remzi/Naur.pdf
  • Generar y mantener son bestias completamente distintas
    Habrá ingenieros que hagan una app de dos semanas y no la vuelvan a tocar nunca más, pero no conozco a mucha gente que se gane la vida con eso
    Tal vez sí funcione para trabajos como “un sitio en WordPress para tu negocio”
    El problema aparece cuando ya hay 432 funciones y quieres agregar la número 433 sin romper las demás
    A veces no puedes equivocarte ni un poco, y a veces una sola función aumenta la complejidad más rápido de lo que un ingeniero puede absorber, hasta que con el tiempo el proyecto crece a un tamaño imposible de gestionar
  • En nuestra empresa, los equipos no técnicos empezaron a crear sus propias herramientas porque el equipo técnico estaba saturado
    Era la idea de una pequeña aplicación integrada con sistemas grandes, y en 2 o 3 días ya habían hecho una prueba de concepto con 3 o 4 commits
    Fue impresionante, pero en los últimos 3 meses esa persona ya hizo 400 commits más en ese proyecto, y con las correcciones sucesivas, construir y mantener esa app se convirtió de hecho en un trabajo de medio tiempo o tiempo completo
    Esa persona se convirtió en un desarrollador de software no capacitado, y no entiende de seguridad ni de buenas prácticas
    Si Claude mejora más, tal vez la carga baje y ya no le consuma el día entero, pero en nuestra empresa todas estas primeras “vibe apps” terminaron convirtiéndose en trabajo de mantenimiento y cada vez consumen más tiempo
    Está claro que la gente no quiere menos software, sino más
    Aunque la ingeniería de software tradicional pueda desaparecer, la gestión de plataformas en expansión, la seguridad, la complejidad, la documentación y la lógica de negocio siguen estando frente a nosotros en la empresa
    Es cierto que hoy se puede crear un proyecto con texto, pero salvo que sea el software más simple posible, da la impresión de que nunca existió realmente eso de “configúralo y olvídalo”
    Todavía hace falta que alguien gestione el conjunto completo
    Haya recibido formación en ingeniería de software o no
    Un desarrollador con experiencia sigue teniendo muchas probabilidades de hacerlo mejor que alguien sin formación
    Claro, los builders curiosos se pondrán al día rápido, pero los desarrolladores tradicionales todavía tienen una gran ventaja
    Porque siempre hemos querido entender cómo funciona todo por dentro
    La actual vibe app que ellos tardaron meses en hacer, yo habría podido hacerla en una hora usando IA
  • El despliegue de software ya bajó al nivel de ejecutar vercel en la terminal, y un agente también puede hacerlo sin problema si se lo pides
    El despliegue de software de escritorio sí es un poco más difícil según la plataforma
    Aun así, la brecha entre un side project y un gran software sigue siendo enorme, y cuesta creer que esa brecha vaya a cerrarse algún día
    No veo por qué no se reemplazaría antes lo que ya era un problema resuelto incluso antes de la IA
    También me cuesta creer que un proyecto personal necesite una infraestructura compleja
  • La programación asistida por IA es excelente, pero creo que el vibe coding sirve solo para prototipos descartables
    No haría con vibe coding una app financiera que haya que mantener indefinidamente
    Tampoco tocaría sistemas legacy
    Está claro que la IA ha reemplazado a algunos ingenieros, pero los casos de amigos no ingenieros haciendo side projects son poco relevantes
    Los hicieron porque ahora se puede, no porque antes pensaran contratar a alguien para hacerlos
    Igual que tampoco habían contratado a nadie hasta ahora

• Trabajo en una agencia de desarrollo, y la mayoría de nuestros clientes son startups que necesitan salir rápido al mercado.
  Llevamos alrededor de año y medio usando desarrollo basado en agentes, y durante ese tiempo nuestro rol ha cambiado mucho.
  No puedo hablar con cifras exactas sobre el volumen de proyectos que entra, pero sí puedo compartir un cambio visible: cambiaron las expectativas sobre el alcance de lo que se puede entregar.
  Antes, un proyecto que hacían 5 personas ahora normalmente lo hacen 1 o 2.
  Siendo realistas, los proyectos greenfield ya están bastante automatizados.
  Mucho trabajo manual, como iteraciones de diseño UX/UI, iteraciones de arquitectura de sistemas y probar varios enfoques para problemas difíciles sin métricas claras, ahora ocurre de inmediato.
  Si puedes entenderlo en tu cabeza, básicamente puedes sacarlo al mundo en una centésima parte del tiempo.
  En este período también cambió mucho nuestra forma de trabajar y de pensar los sistemas.
  Hemos entrado en una relación de simbiosis con los LLM, y ahora de verdad sería muy difícil trabajar sin ellos.
  Eso no significa que no entienda el código que escriben los LLM; sigo cada cambio y entiendo la base de código mucho mejor y a mucha mayor escala que el propio LLM.
  Pero mi capacidad de escribir código manualmente sí se ha deteriorado bastante, y creo que eso está bien.
  Ahora me siento más como una capa de traducción entre los objetivos del negocio y la tecnología que mejor los respalda.
  Sigue siendo resolver problemas, pero a un nivel mucho más alto, y sigue siendo interesante y divertido.
  La mejor estrategia para los desarrolladores en esta era parece ser mantener el pensamiento crítico y usar las herramientas a su favor.
  Ahora todos tenemos superpoderes.
  Ya ni siquiera hace falta trabajar necesariamente en una empresa, y como un desarrollador individual puede construir cosas impresionantes, tampoco hace falta depender tanto de otras personas como antes.
  Tal vez el futuro sea una economía macro de productos donde cada quien ofrezca algo único al mundo.

  • Interpretaciones del tipo “ahora todos tenemos superpoderes” parecen ser un malentendido raro de la situación por parte de los entusiastas de la IA.
    Si la codificación con agentes llega a ser lo bastante buena como para crear proyectos greenfield, eso afecta no solo a los desarrolladores, sino a empresas enteras y a sectores industriales completos.
    El modelo de negocio de las agencias de desarrollo existe porque las empresas débiles en tecnología no saben cómo manejar software, y en algunos casos también porque existe el incentivo oportunista de subcontratar el trabajo inicial intensivo en mano de obra.
    Pero ahora esa tecnología ya está al alcance de los clientes de las agencias, así que es solo cuestión de tiempo para que los CEO y gerentes empiecen a hacer vibe coding y se den cuenta de que “solo necesitan un desarrollador con un poco de criterio técnico”.
    Esto también podría extenderse a muchos negocios SaaS.
    Muchas pequeñas empresas siguen queriendo software a medida para eliminar trabajo manual, pero los desarrolladores de software serios siempre han sido demasiado caros.
    Por eso terminaban usando el código desastroso hecho por el sobrino de alguien, o un SaaS que apenas funciona.
    Ahora podrán crear su propia solución personalizada, que seguramente seguirá siendo bastante improvisada, pero les dará más.
    Lo que hacen las big tech se parece más a un reajuste adaptado a una recesión, y lo más preocupante es el caos en el sector tecnológico de pymes.
  • La razón por la que uno trabaja en una empresa no es solo que un desarrollador no pueda sacar resultados por su cuenta.
    También es porque no tiene la red de contactos necesaria para conseguir clientes.
    La mayoría de los desarrolladores necesitan que la empresa al menos se encargue del marketing para que ellos puedan concentrarse en lo que hacen bien.
  • Ya estoy sintiendo la degradación de mi capacidad para escribir código.
    Generar código y evaluar código son habilidades distintas en el cerebro.
    Como programar consiste sobre todo en muchos detalles sintácticos pequeños, puedes tener dificultades para escribir código y aun así ser bueno revisándolo.
    https://xcancel.com/karpathy/status/2015883857489522876
  • No hay que confundir lo teóricamente posible con lo realmente posible.
    Las empresas exitosas del mundo real tienen fosos competitivos basados en datos, patentes y propiedad intelectual, efectos de red, etc.
    Que el tiempo de desarrollo se haya reducido a una centésima parte no significa que de inmediato puedas crear un negocio nuevo.
    Si miras hoy la industria tecnológica, hay muchas empresas que parecen vulnerables a ser disrumpidas por builders ágiles impulsados por IA, pero en la práctica eso no está ocurriendo por los efectos de lock-in.

• La afirmación de que “de las 270 ocupaciones del censo estadounidense de 1950, solo desapareció una por la automatización: el operador de ascensor” lleva a confusión.
  En el mismo período, los empleos agrícolas bajaron del 15% al 2% de la fuerza laboral.

  • El texto parece abordar ese punto también.
    Dice que esto es distinto de ocupaciones como la agricultura, donde la mecanización y la automatización redujeron mucho la demanda de trabajo. La diferencia es que la cantidad de calorías que consume la gente es relativamente fija, y un aumento de apenas 25% ya produjo una epidemia de obesidad, mientras que la cantidad de software producido creció un millón de veces.
  • El empleo agrícola en sí se redujo a una cuarta parte del nivel de 1950.
    La cifra porcentual exagera la caída porque la fuerza laboral total creció.
    Pero si miras el empleo en la industria alimentaria en sentido amplio, sí aumentó bastante.
    Así que aunque el empleo de “codificadores” baje, el empleo en la industria más amplia de “software/tecnología” podría crecer.
  • Basta con mirar la industria maderera.
    Cerca del 95% de esos empleos ya fue automatizado, pero ellos suelen culpar a los búhos.
  • Es la forma típica de usar las estadísticas de manera selectiva.
    Lo mismo pasó con las fábricas y las cintas transportadoras.
    Cada vez que llega la automatización, la gente sigue perdiendo empleos, y nosotros solo “esperamos” que encuentren otra cosa, o escuchamos ese optimismo extremo e incoherente de “sé generalista”, “sé especialista”, “vete a servicios”, “aprende a programar”, “vete a extraer carbón”.
    Basta escuchar a @pmarca para ver qué tan perdida e incoherente está la dirigencia tecnológica.
    También vale la pena ver el libro más reciente de Stripe Press sobre automatización industrial: https://press.stripe.com/origins-of-efficiency

• Las personas que creían en la IA de la forma más ingenua por lo general eran tinkerers.
  Es entendible, porque con la ayuda de los LLM para programar, la velocidad para trastear con cosas aumentó de forma asombrosa.
  Tinkering es un proceso, y la gente obtiene mucho placer del acto mismo de construir y ajustar cosas.
  El resultado es una consideración de segundo o tercer orden.
  La IA ha ampliado muchísimo nuestra capacidad de actuar y, por tanto, de trastear, pero no puede producir por sí sola un impacto significativo, es decir, “ingeniería”.
  El impacto importa más que la actividad.

  • Muchas veces tinkering se parece a la ingeniería antes de que una organización construya procesos a su alrededor.
    Prototipado, depuración, pruebas y demás no son trabajo falso solo porque ocurran rápido.
    Un compilador tampoco produce impacto por sí solo.
    Lo mismo pasa con CI, los IDE, los frameworks y la infraestructura en la nube.
    Esas cosas aumentan el apalancamiento de quien las usa.

• A mi esposa sí la reemplazó la IA
  Era programadora, y la empresa creó agentes abiertamente con el objetivo de reemplazar a mi esposa y a algunas otras personas; la despidieron alrededor de un mes después de que empezó a funcionar

  • La moral de los colegas que siguen ahí debe estar mal
    Nuestro equipo recibió a un nuevo jefe hace 18 meses, hubo favoritismo descarado, y la única persona que le gustaba no era precisamente alguien que trabajara en equipo
    En 18 meses encontró la manera de despedir a todos los que trabajaban en remoto, sin importar su desempeño pasado
    Una de esas personas incluso había recibido varias veces premios de un nivel superior al del jefe, pero el jefe siempre solo reconocía a esa persona tóxica
    No fue un reemplazo por IA, pero un ambiente en el que la gente siente que no vale nada probablemente se parece a ser reemplazado por IA
    Todos en ese equipo, incluido mi supervisor, están postulando a otros trabajos
    El supervisor tiene autismo de alto funcionamiento y el jefe se burla de él con frecuencia
    De verdad espero que le vaya bien por su salud mental
    Reporté el problema a RR. HH. varias veces, e incluso encontré cláusulas del reglamento laboral que el jefe estaba violando, pero al menos aquí aprendí que esas normas son puro texto
    Más bien eso solo hizo que me pusieran una diana en la espalda, así que tuve que irme
    Varias otras personas también plantearon preocupaciones, y la mayoría de ellas después encontró otro trabajo
    Por suerte pronto conseguí un nuevo empleo y estoy entusiasmado
  • Qué duro
    Ojalá estés bien
    Me pregunto qué pasó después, si encontraste un nuevo trabajo y si sigues en software

• Que la comunicación corporativa sobre despidos por IA sea falsa no invalida el riesgo
  Aunque lo que dicen las empresas pueda ser mentira, el impacto de la tecnología puede ser real, y en este contexto eso es solo ruido
  Como en el diagrama de hamburguesa del artículo, la suposición de que la etapa de ejecución se reduce pero todas las demás crecen y por eso el tamaño total de la hamburguesa se mantiene igual tampoco suena muy plausible
  Aun así, parece que algunas áreas de la ingeniería de software siguen estando muy lejos de verse amenazadas
  En particular, las áreas donde la precisión es clave
  En desarrollo web hay mucho más margen para sacar algo a empujones, pero el código de navegación de cohetes es otra cosa
  Puede que los LLM puedan hacer ambas, pero no creo que nadie vaya a hacer vibe coding de lo segundo pronto

• La IA, literalmente, ya reemplazó parte del trabajo y lo hará aún más en el futuro
  No va a reemplazar a todos los ingenieros de software, pero una vez abierta la caja de Pandora, el trabajo de bajo esfuerzo y bajo riesgo lo hará la IA
  En servicios como Lovable hay muchísimos proyectos reales en producción, y la alternativa era que los hiciera una persona

  • ¿Puedes mostrar algún proyecto “excelente” en Lovable, escrito o generado por alguien que no sea experto en software, que sea útil como una herramienta SaaS completa?
  • La alternativa podría no haber sido que lo hiciera una persona, sino que simplemente no existiera

• Quien reemplaza empleos siempre es el empleador
  No hay que antropomorfizar un montón de tarjetas gráficas

  • Si ese montón de tarjetas gráficas de verdad se vuelve más eficiente, los empleadores que quieran contratar humanos ya no podrán competir

• No me convence esta parte del artículo
  La afirmación es: “el verdadero cuello de botella es (1) decidir y especificar qué construir, (2) verificar y hacerse responsable de lo entregado, (3) la comprensión humana profunda de la base de código, el negocio y el entorno”
  Puede ser que, como programar era caro y se consideraba el cuello de botella, se invirtiera mucho esfuerzo tanto aguas arriba como aguas abajo para asegurar que la entrada fuera correcta y que el resultado no se tirara a la basura
  Si programar se considera una etapa rápida y barata, quizá no haga falta el mismo nivel de supervisión aguas arriba, porque se puede desechar el resultado

  • El costo de tirar código incorrecto no es el costo principal de construir algo equivocado
    El impacto cuando el software funciona mal y mantener la compatibilidad hacia atrás es mucho peor