La ingeniería de software sube de nivel. Otra vez.

La ingeniería de software está subiendo un nivel de abstracción. Los agentes de IA facilitan convertir un diseño en código, y este salto es mucho mayor que pasar de un lenguaje de programación a otro. Ahora podemos delegar partes de la implementación que antes exigían que una persona expresara explícitamente la solución. La tarea fundamental sigue siendo comprender el problema, elegir una estructura adecuada y demostrar que el sistema resultante se comporta correctamente.

La profesión lleva mucho tiempo confiando el trabajo mecánico a herramientas mejores. Las tarjetas perforadas, los ensambladores, los compiladores y los entornos de ejecución gestionados cambiaron la relación entre el ingeniero y la máquina. La IA continúa esa historia y amplía lo que podemos delegar.

De las tarjetas perforadas a los entornos de ejecución gestionados

Para muchos de los primeros programadores, escribir software consistía en preparar lotes de tarjetas perforadas y entregarlos para su ejecución. El Computer History Museum documenta su uso como medio de entrada y almacenamiento de programas. Podían contener código ensamblador o de alto nivel; eran la interfaz física por la que los programadores entregaban instrucciones a la máquina.

El ensamblador ofreció una forma simbólica de trabajar con instrucciones de máquina. Un programa ensamblador traducía los mnemónicos y las referencias simbólicas a código máquina, pero el programador seguía cerca del procesador: los registros, las instrucciones y el flujo de control explícito seguían siendo esenciales para expresar la solución.

Antes de que los lenguajes de alto nivel fueran prácticos, los programadores trabajaban mucho más cerca de las instrucciones de máquina. La historia de Fortran de IBM explica cómo su lanzamiento comercial en 1957 permitió traducir automáticamente expresiones matemáticas a código máquina. Los desarrolladores podían expresar los cálculos en un nivel más próximo al problema y dejar la representación de bajo nivel al compilador.

Los lenguajes y sus entornos de ejecución siguieron asumiendo responsabilidades. JavaScript, como otros lenguajes con recolección de basura, gestiona automáticamente la asignación y liberación de memoria. Por lo general, el desarrollador crea objetos y deja que el entorno recupere su memoria cuando dejan de ser accesibles, en lugar de asignarla y liberarla explícitamente.

La gestión de memoria sigue existiendo. Los desarrolladores deben vigilar las referencias retenidas, las cachés sin límite y la presión sobre la memoria. Pero gran parte de esa gestión se ha trasladado por debajo del nivel en el que suelen escribir la lógica de la aplicación.

Con estos cambios, más detalles de la máquina pasaron a las herramientas y los entornos de ejecución. Los ingenieros pudieron prestar más atención al comportamiento deseado. El sistema subyacente seguía necesitando un diseño coherente.

La IA supone un salto mucho mayor

Un compilador toma una solución ya expresada en un lenguaje formal y la traduce. Un recolector de basura gestiona la memoria según las reglas del entorno de ejecución. Ambos eliminan trabajo, pero el programador sigue siendo responsable de describir explícitamente la lógica del programa.

Un agente de IA puede recibir la descripción de una tarea, inspeccionar un repositorio desconocido, proponer un enfoque, modificar varios archivos, ejecutar pruebas y revisar el resultado. Abarca decisiones y actividades que antes correspondían al programador al otro lado de la frontera de abstracción. Por eso el salto supera con creces una nueva mejora de lenguaje o entorno de ejecución.

Esto también cambia quién puede participar en la implementación y cómo distribuyen su tiempo los ingenieros experimentados. Más trabajo puede empezar con una intención, ejemplos y restricciones, mientras la herramienta propone una solución inicial y su código. Los arquitectos pueden explorar estructuras alternativas con menos esfuerzo de implementación manual.

La comparación con el compilador refleja la dirección del cambio: se delega más traducción. Sin embargo, no refleja toda su magnitud. Los agentes interpretan intenciones incompletas y proponen soluciones, por lo que su frontera de abstracción es más amplia y menos predecible que la de un compilador convencional.

Reconoce la magnitud del cambio y evalúalo por el trabajo de ingeniería que permite realizar. Los métodos y la economía pueden cambiar radicalmente, mientras permanece la obligación de diseñar, verificar y operar un sistema útil.

Expresar una solución con más facilidad no elimina el problema de diseño

Fred Brooks planteó una distinción útil en No Silver Bullet: la dificultad esencial de especificar y diseñar software, y la dificultad accidental introducida por la forma de representarlo e implementarlo. Los lenguajes de alto nivel eliminaron mucha fricción de implementación sin hacer desaparecer las decisiones de diseño.

Los agentes pueden reducir aún más esa fricción. También ayudan a investigar diseños, comparar alternativas y encontrar errores. Pero disponer de sugerencias no elimina la necesidad de resolver requisitos contradictorios o justificar una decisión entre alternativas.

Pensemos en un servicio de procesamiento de pagos. Crear un punto de acceso, una migración de base de datos y un consumidor de colas puede resultar sencillo con un agente. Decidir qué ocurre cuando un proveedor de pagos agota el tiempo de espera después de aceptar un cargo sigue siendo un problema de diseño de sistemas.

Un reintento puede duplicar el cargo. No reintentar puede dejar el pedido en un estado incierto. Una clave de idempotencia solo ayuda si su alcance, persistencia y el comportamiento del proveedor permiten ofrecer la garantía necesaria. También hace falta conciliar el estado local con el del proveedor después de una caída.

El agente puede implementar esas decisiones e incluso proponerlas. Pero si los requisitos no especifican cómo gestionar la incertidumbre, una implementación plausible puede convertirse silenciosamente en la política del producto.

Ese riesgo ya existía cuando las personas escribían cada línea. Una generación más rápida simplemente da menos tiempo para detectar una suposición no examinada.

El patrón arquitectónico sigue teniendo que justificar su uso

Una implementación más barata hace accesibles más patrones. Un agente puede generar la estructura de un monolito modular, introducir un consumidor de eventos o crear clientes de servicios. Explorar alternativas antes de elegir una puede costar menos.

Eso no convierte las alternativas en equivalentes.

Para un equipo pequeño cuyas operaciones principales comparten datos transaccionales, normalmente empezaría con un monolito modular y límites explícitos. Dividirlo en servicios debe responder a un requisito concreto: despliegue independiente, aislamiento, responsabilidad o escalabilidad. Que un agente pueda generar seis servicios es una mala razón para operar seis servicios.

Del mismo modo, la mensajería asíncrona justifica su complejidad cuando lo requieren el almacenamiento temporal, el desacoplamiento o la latencia. También introduce cuestiones de entregas duplicadas, orden y recuperación. Generar más rápido un consumidor no cambia esas propiedades.

La investigación de DORA sobre equipos con bajo acoplamiento destaca la capacidad de implementar, probar y desplegar de forma independiente. Es un objetivo arquitectónico útil porque describe lo que permite una estructura. El nombre de un patrón en un diagrama aporta mucha menos información.

En mi opinión, los agentes aumentan el valor de unos límites claros. Un cambio acotado con contratos explícitos resulta más fácil de delegar y comprobar. Si los cambios cruzan habitualmente límites poco claros de datos y responsabilidades, producirlos más rápido puede aumentar la carga de integración.

El informe DORA de 2025 describe la IA como un amplificador de las fortalezas y debilidades existentes de una organización. El hallazgo respalda el argumento general, aunque no demuestra que una arquitectura concreta funcione mejor con agentes.

La abstracción es útil, pero menos fiable

Un compilador convencional traduce un lenguaje definido formalmente y se espera que preserve su semántica especificada. Un agente suele interpretar intenciones incompletas, inferir detalles ausentes y utilizar herramientas externas. Su resultado puede parecer coherente mientras implementa una suposición equivocada.

La ficha de aplicación de Copilot Agents de GitHub reconoce las alucinaciones y la necesidad de revisar y validar los resultados generados. Es relevante para la analogía: avanzamos hacia una abstracción superior, pero la frontera de traducción exige una verificación más explícita.

Dijkstra defendía en The Humble Programmer que la abstracción debe permitir razonar con precisión en un nuevo nivel semántico. Ese es un objetivo más útil para el trabajo con agentes que escribir peticiones más breves y vagas.

Para el servicio de pagos, una especificación útil establecería que una misma solicitud lógica no debe generar varios cargos; que un tiempo de espera agotado debe conservar un estado explícito de incertidumbre; y que la recuperación debe consultar al proveedor antes de decidir si reintenta. Son obligaciones de comportamiento frente a las que se puede verificar una implementación.

Las pruebas, el análisis estático y la revisión siguen formando parte del proceso. Deben comprobar el requisito de forma independiente de la implementación generada. Pedir a un agente que escriba ambas partes no demuestra su corrección si las dos incorporan la misma suposición equivocada.

Menos programación manual no garantiza entregas más rápidas

Existen pruebas de que la asistencia con IA puede mejorar la productividad. Tres experimentos de campo aleatorizados con 4.867 desarrolladores observaron un aumento agregado del 26,08 % en las tareas completadas. Los experimentos individuales presentaban variabilidad y la intervención era un asistente de programación, no un agente de ingeniería plenamente autónomo.

El resultado no es universal. El estudio de METR de principios de 2025, con 16 mantenedores experimentados que completaron 246 tareas, observó que permitir la IA aumentó un 19 % el tiempo de finalización. Su actualización de febrero de 2026 apuntaba a que las herramientas probablemente ayudaban más, pero los efectos de selección dificultaban estimar con fiabilidad la magnitud de la mejora.

Estos estudios miden contextos y resultados distintos. Permiten extraer una conclusión práctica: hay que medir los cambios aceptados y el esfuerzo total de entrega, incluidas la revisión y las correcciones. Generar código puede ser más sencillo mientras otra fase de la entrega se convierte en el cuello de botella.

La mejor defensa de los agentes no necesita prometer que todas las tareas serán más rápidas. Basta con poder delegar más implementación, explorar alternativas a menor coste y dedicar menos atención a la traducción mecánica.

La ingeniería avanza con la abstracción

El flujo de trabajo está cambiando de forma sustancial. Cada vez más, los ingenieros especifican, delegan, inspeccionan y refinan cambios en lugar de expresar todos los detalles. La economía de la implementación cambia con ello.

Las obligaciones fundamentales siguen siendo reconocibles: comprender el dominio, elegir una arquitectura adecuada a sus restricciones, demostrar la corrección y mantener el sistema operativo mientras evoluciona.

Utiliza los agentes para abaratar la implementación. Aprovecha esa libertad para elegir la estructura que merece el trabajo y verificarla con más rigor. A medida que resulta más fácil producir código, las decisiones que le dan sentido adquieren más importancia.

Ideas principales

• La programación con IA supone un salto de abstracción mucho mayor que las anteriores mejoras de lenguajes: los agentes interpretan intenciones y proponen implementaciones, mientras permanece la responsabilidad de ingeniería.
• Una implementación más barata facilita explorar arquitecturas; los requisitos y las decisiones operativas siguen determinando el patrón adecuado.
• Los contratos precisos, las invariantes y la verificación independiente son esenciales cuando los agentes interpretan intenciones incompletas.
• Mide resultados aceptados y esfuerzo total de entrega, incluidas la revisión y las correcciones, además del volumen de código.