La IA no simplificó la ingeniería de software: solo hizo más fácil crear mala ingeniería

• Los LLM aceleraron la escritura de código, pero no redujeron la complejidad esencial de la ingeniería de software
• A medida que generar código se volvió más fácil, se ha extendido la ilusión de que ya no se necesita experiencia especializada, y algunas organizaciones están reduciendo sus equipos de ingeniería con ese argumento
• La dificultad real no está en escribir código, sino en el diseño del sistema, la especificación, la verificación y el mantenimiento de la consistencia, y la IA más bien acelera esa carga
• La desalineación entre especificación, pruebas e implementación (spec drift) se está agravando rápidamente, aumentando el riesgo de colapso de la confiabilidad del sistema
• Es un patrón observado repetidamente a lo largo de más de 40 años de experiencia: en la era de Visual Basic en los años 90 también surgió la misma afirmación de que “la experiencia ya no era necesaria”, y al final se volvió a confirmar la necesidad de la disciplina de ingeniería
• Los LLM son herramientas excelentes para explorar diseños y acelerar implementaciones iniciales, pero deben usarse para reforzar la disciplina de ingeniería, no para reemplazarla

---

Una peligrosa confusión en la industria

• Desde que los LLM pueden generar código, en la industria del software se ha instalado la idea de que la ingeniería de software ya no hace falta
• Disciplinas como la arquitectura, la especificación o la validación cuidadosa están siendo tratadas como si fueran reliquias de otra época
• En algunas organizaciones, esta idea ya se ha convertido en política, con casos de despidos masivos de ingenieros justificados por los avances de la IA
• La IA no es más que la excusa más reciente para encubrir malas decisiones de negocio o presiones del mercado
• Cada vez más se presenta el hecho de escribir prompts a una IA como si pudiera sustituir las disciplinas que definían la ingeniería de software

Un patrón histórico que se repite

• A lo largo de más de 40 años de carrera se ha visto el mismo patrón una y otra vez: aparece una nueva herramienta → se declara que los problemas difíciles ya fueron resueltos → sube la productividad y aparecen demos impresionantes → recortes de personal → aumento de la complejidad del sistema → y al final, resultados muy distintos a lo esperado
• Cambian las herramientas y los discursos, pero el patrón en sí casi no cambia

La analogía con el mantenimiento de aeronaves

• El sector del mantenimiento de aeronaves ha avanzado muchísimo con mejores herramientas, diagnóstico computarizado, manuales digitales e interpretación de telemetría con IA, pero la necesidad de técnicos experimentados sigue intacta
• Un avión comercial es un sistema extremadamente complejo, con millones de piezas y miles de subsistemas interconectados
• Diagnosticar problemas no consiste solo en tener la herramienta correcta o seguir una checklist, sino en contar con experiencia y criterio sobre cómo se comporta el sistema en condiciones reales de operación
• Ninguna aerolínea propondría eliminar a sus técnicos capacitados porque mejoraron las herramientas y dejar las reparaciones en manos del personal de puerta
• Y, sin embargo, la industria del software está haciendo una afirmación muy similar sobre sí misma

DIY vs. sistemas profesionales

• No hay ningún problema con proyectos hobby, apps pequeñas de uso personal o experimentos con ideas nuevas; de hecho, muchas de las ideas más interesantes en la historia de la computación nacieron así
• Pero el desarrollo profesional de software es una categoría completamente distinta: procesar pagos, almacenar información sensible, gestionar infraestructura y operar sistemas de los que la gente depende todos los días
• Los clientes dan por hecho que esos sistemas funcionarán correctamente, que seguirán siendo correctos mientras evolucionan y que quienes los construyen entienden cómo funcionan
• Esa expectativa es una condición básica de la ingeniería profesional, y es justamente donde la disciplina y la experiencia se vuelven inevitables

El código nunca fue la parte difícil

• Que la parte difícil del desarrollo de software sea escribir código es un malentendido antiguo
• Teclear sintaxis siempre fue la parte menos interesante de construir sistemas; el trabajo realmente difícil está en decidir cómo debe comportarse el sistema, diseñar la interacción entre componentes y mantenerlo comprensible a medida que aumenta la complejidad
• Eso no es un problema de programación, sino un problema de ingeniería
• Reducir el esfuerzo para producir código no elimina esos problemas; solo permite construir sistemas más grandes y más complejos con mayor rapidez
• Creer que eso es un aumento de productividad es una ilusión: la carga simplemente se desplazó a otro lugar
  • La carga cognitiva necesaria para revisar código y lidiar con código generado puede convertirse en un factor de caída de productividad mayor que escribirlo directamente
  • Si la velocidad aumenta sin que se entienda suficientemente el comportamiento subyacente, lo único que se acelera es el momento en que la complejidad se vuelve inmanejable, y además el resultado será incorrecto

Un patrón ya visto: la era de Visual Basic

• En los años 90, Visual Basic vino acompañado de promesas parecidas: que la programación se había democratizado y que la experiencia especializada ya no era necesaria
• En la práctica, Visual Basic sí permitió crear muchas aplicaciones que de otra forma nunca habrían existido
• Pero a medida que esos sistemas crecieron y se interconectaron, se redescubrió que producir artefactos de software no es lo mismo que hacer ingeniería de sistemas confiables
• Lo que vemos hoy es una versión amplificada del mismo patrón: no solo se redujo la barrera para construir aplicaciones, sino la barrera para producir código en sí
• Y de ahí nace la tentadora creencia de que la experiencia ya no es necesaria

El problema de la alineación

• El software confiable depende de algo de lo que casi no se habla fuera de la ingeniería: la alineación (alignment)
• Un sistema empieza con una idea sobre cómo debe comportarse → eso se documenta en una especificación (specification) → y luego los ingenieros convierten esa especificación en pruebas y código de producción
• Para que un sistema siga siendo confiable en el largo plazo, especificación, pruebas e implementación deben mantenerse siempre alineadas
• Cuando esas tres cosas empiezan a desviarse, el sistema pierde su integridad de manera gradual
  • La especificación describe comportamientos que ya no están implementados
  • Las pruebas solo verifican una parte del comportamiento y dejan fuera el resto
  • Los ingenieros que llegan después adivinan cómo funciona el sistema leyendo código que puede o no reflejar el diseño original
• Con el tiempo, esas suposiciones se acumulan, hasta que se termina con un sistema que nadie entiende realmente
• A este fenómeno se le da el nombre de “spec drift”: la descripción del sistema y el sistema mismo se separan progresivamente
  • El código cambió, pero la especificación se quedó igual
  • La especificación evolucionó, pero las pruebas quedaron fijas
  • El comportamiento fue cambiando poco a poco hasta que ya nadie puede asegurar cuál era la intención original
• Cuando la alineación se rompe, la confiabilidad no puede sostenerse por mucho tiempo

La IA acelera la deriva

• Los LLM aceleran de forma drástica la producción de código, y esa es al mismo tiempo su mayor fortaleza y el punto donde aparece el riesgo
• Cuando el código se produce más rápido que la disciplina de ingeniería que lo rodea, se acelera la fuerza que genera spec drift
• Cambios que antes requerían pensamiento cuidadoso e implementación manual ahora pueden hacerse en cuestión de segundos
• Secciones completas del sistema pueden reescribirse antes de que alguien verifique si su comportamiento sigue ajustándose a la especificación
• El código puede verse razonable, compilar, leerse bien e incluso pasar las pruebas existentes, pero la alineación que gobernaba el sistema quizá ya desapareció
• Lo que parece productividad puede ser, en realidad, la capacidad de moverse hacia la desalineación (misalignment) más rápido que antes

Dónde sí ayuda la IA

• Los LLM no son un error; usados con criterio, pueden mejorar drásticamente la forma en que los ingenieros exploran y diseñan sistemas
• Son especialmente buenos para: razonar sobre problemas, explorar alternativas de diseño, resumir sistemas complejos y generar borradores que aceleren las primeras etapas de implementación
• Donde siguen siendo débiles es en ámbitos que requieren disciplina rigurosa y consistencia a lo largo del tiempo
• Mantener alineadas la especificación, las pruebas y la implementación sigue siendo una responsabilidad de ingeniería, y ninguna herramienta puede reemplazar esa responsabilidad, aunque sí puede apoyarla
• La verdadera oportunidad está en usar los LLM para reforzar el proceso de ingeniería, no para sustituirlo silenciosamente

Ingeniería de software conversacional

• Una de las posibilidades interesantes que abrieron los LLM es que parte de la ingeniería de software podría volverse más conversacional (conversational)
• Durante décadas, las herramientas de diseño de sistemas fueron rígidas: las especificaciones eran documentos, la arquitectura eran diagramas y el razonamiento que llevaba a ellos se perdía entre reuniones y conversaciones de pasillo
• Con los LLM, los ingenieros pueden explorar ideas de forma interactiva, poner a prueba supuestos y trabajar el diseño de una manera más cercana a una conversación natural
• Pero conversar no es hacer ingeniería: la conversación sirve para explorar ideas; la ingeniería empieza cuando esas ideas quedan capturadas en una forma verificable, testeable y mantenible
• El reto de la próxima generación de herramientas de ingeniería será aprender a conectar esos dos mundos sin perder la disciplina que exigen los sistemas complejos

La experiencia sigue importando

• El software profesional sigue necesitando ingenieros que entiendan cómo funcionan realmente los sistemas que construyen
• Las herramientas pueden acelerar el desarrollo, pero no eliminan la experiencia necesaria para diseñar, razonar y mantener sistemas complejos
• La industria está peligrosamente cerca de olvidar este hecho
• Los LLM pueden volver mucho más productivos a los ingenieros con experiencia, pero no sustituyen la disciplina de ingeniería necesaria para construir sistemas confiables
• Hay que usar estas herramientas con eficacia, no con adoración

[GN⁺]

Opiniones de Hacker News

• No estoy de acuerdo con la premisa del artículo. Creo que la ingeniería en general se volvió más fácil, para bien o para mal. Antes también veía a mucha gente meter montones de null checks en vez de entender el problema. Ahora eso simplemente se amplificó a gran escala. Por otro lado, la buena ingeniería también se potenció, y he visto funciones que antes tomaban semanas hacerse en solo unos días

  • Me parece que el artículo exagera un poco. La buena ingeniería también puede beneficiarse de agentes basados en LLM, pero la verificación de resultados sigue siendo tarea humana. La mala ingeniería se salta esa etapa, así que, desde la perspectiva de la ley de Amdahl, los LLM aceleran mucho más la mala ingeniería
  • La mala ingeniería se volvió muchísimo más fácil, y la buena ingeniería se volvió un poco más fácil. Así que la gente que antes hacía buena ingeniería ahora hace tres veces más mala ingeniería
  • En desarrollo de apps empresariales he visto mock tests que solo verifican si devuelven el valor esperado. No entiendo qué sentido tiene eso
  • Es fácil olvidar que un LLM no es un oráculo mágico. La forma en que tratas su salida determina la calidad del resultado. A veces se puede usar tal cual, pero la mayoría de las veces necesita ajustes. Es fácil caer en la trampa de pensar “si lo dijo el LLM, debe estar bien”, y eso facilita la mala ingeniería
  • Incluso si estás de acuerdo con el artículo original, en la práctica hay muchas áreas de aplicaciones donde da igual si la calidad del software es buena o mala. En muchos casos basta con que funcione

• Hay casos donde ni cien pruebas unitarias bastan para demostrar que un código es correcto. La mayoría de los desarrolladores no sabe qué es suficiente. La gente que usa mucho vibe coding hasta le deja las pruebas a la máquina. Cuando pasas a la etapa de diseño de sistemas, necesitas una arquitectura que garantice la seguridad y las invariantes temporales del sistema completo. Pero la mayoría simplemente dibuja cajas y flechas y cita “best practices”. El software se parece más a las ciencias naturales, como en el efecto Sussman, así que terminas dedicando más tiempo a la observación. Usar GenAI como herramienta puede ser útil, pero dejar de pensar y depender de la herramienta es peligroso

  • Yo ni siquiera sé qué es una prueba unitaria, pero gracias a la IA puedo crear programas que me ayudan muchísimo en el trabajo real. Los programadores de élite no te responden ni un correo aunque les pagues

• Cada pocos años, cada vez que sale una herramienta nueva, aparece el discurso de que “ya se resolvió la parte difícil de la ingeniería de software”. La productividad se dispara, los demos impresionan y la industria se felicita a sí misma. Pero poco después llegan los recortes de personal. Estaría bien si fuera un avance real, pero si el resultado son despidos, entonces no significa gran cosa. Al final la pregunta es la misma: si el objetivo es reducir empleos, ¿cuál es la visión empresarial cuando la gente ya no pueda mantenerse?

  • El objetivo no es el empleo individual. El fin último es construir AGI, y en ese proceso los salarios y la contratación de desarrolladores ya pasaron su punto máximo. Solo unos pocos superdesarrolladores de IA serían la excepción
  • Creo que eliminar la complejidad es imposible. La realidad y las personas son complejas por naturaleza. La idea de que el software puede ser simple es irrealista. Desde una perspectiva más amplia, el objetivo al final parece ser la desaparición de la clase media
  • Si no hay demanda, toca hacer otra cosa. Si te niegas, te mueres de hambre
  • El capitalismo depende de la existencia de una clase baja. Esa clase ejerce presión sobre otros trabajadores para que acepten salarios más bajos y peores condiciones. Los programadores solo estuvieron protegidos de esa realidad por un tiempo. Esta estructura también está vinculada al trabajo migrante, donde las empresas pueden asignar tareas peligrosas y deportar a quienes no obedezcan. En última instancia, todo esto es un sistema para bajar los costos laborales

• Estoy de acuerdo con que “programar nunca fue la parte difícil”. Los expertos ya sabían qué había que construir; lo molesto era solo el trabajo repetitivo

  • El mantenimiento del código sigue siendo un tema de personas y experiencia. Ahora es más importante saber “qué código no deberías escribir”. Hoy generar código es tan fácil que vivimos en una época ideal para producir código espagueti en masa
  • El núcleo del debate sobre los LLM está aquí. Hay gente que solo quiere resultados, y hay gente que quiere mantenibilidad y estabilidad. Ambas posturas son necesarias, y los roles de prototipo y producción se van a separar de forma natural
  • La gente realmente talentosa igual quiere hacerlo por sí misma. No por los LLM, sino porque siempre fue así. De hecho, quienes más se benefician son los que decían que “escribir sintaxis no tiene gracia”. Para mí, teclear en sí mismo es la única parte interesante

• Los desarrolladores junior que dependan demasiado de la IA más adelante van a pagar el precio por no dominar los fundamentos. Al final, la estabilidad laboral quedará solo para la gente con experiencia

• Me cuesta estar de acuerdo con la afirmación de que “escribir código no era la parte difícil”. Claro, no siempre es difícil, pero cuando hay restricciones de tiempo, escribir código sí se vuelve el cuello de botella. La IA hace posibles intentos que antes eran inviables y permite disponer de más tiempo de ingeniería

  • Hay una contradicción en decir que “es difícil tomarlo en serio” y aun así terminar dándole la razón. El texto original tiene matices mucho más finos
  • Escribir código era la tarea que más tiempo consumía, y la IA lo deja en evidencia. Cualquiera puede tipear, pero la verdadera habilidad es leer código. Como un leñador con motosierra en vez de hacha: sube la eficiencia, pero también puede aumentar el daño

• La IA también hizo más fácil la buena ingeniería. Al final, es un amplificador de conducta

  • Los buenos ingenieros pueden hacerlo mejor, pero la mayoría ni siquiera sabe qué es property testing. Me pregunto qué tan útil puede ser la IA para esa gente
  • Internet conectó el conocimiento de todo el mundo, pero los humanos terminaron cayendo en la charla vacía y el contenido de desgaste. Considerando la naturaleza humana, la IA probablemente siga un camino parecido
  • Muchos problemas creativos se resuelven en el proceso mismo de escribir código. Si usas IA, ese circuito mental se activa menos
  • Datos como el reporte DORA también respaldan esto
  • La frase “la IA es un amplificador de conductas existentes” es realmente precisa. Me la voy a quedar

• Soy escéptico de la IA, pero no creo que le quite el trabajo a mis colegas. Más bien me ahorra tiempo. La uso como herramienta de investigación mejor que Google, y me sirve para explorar codebases, generar funciones helper y revisar errores

  • Yo también estoy de acuerdo. Creo que esta forma de uso es, al final, el destino final del uso de IA

• Últimamente se está marcando más la diferencia entre ingeniería de software e investigación. La IA es una herramienta increíble en investigación exploratoria. Si veo potencial, entonces cambio al modo SWE, entiendo y modifico el código, y lo pulo con mi propia experiencia. El papel de la IA es limitado, pero sigue siendo útil

  • Los LLM pueden explorar de inmediato una amplitud de conocimiento mucho mayor que la de los humanos. Pero el juicio final depende del gusto y criterio de calidad humanos

• ¿Cuántos modelos más tendrán que salir para que esta gente (los pesimistas) se rinda? ¿Dos? ¿Tres?