Menos programación humana, más arquitectura humana

Si mañana la IA produjera cada línea de la implementación de un sistema, ¿qué tendría que seguir diseñando, decidiendo y verificando la ingeniería? La pregunta es hipotética, pero ya no es ociosa, y este artículo sostiene que la respuesta es arquitectura, en un sentido concreto y ejecutable. Mantiene separados tres tipos de afirmación: lo que los estudios han medido, con su fuente; lo que se sigue de esas mediciones por razonamiento, marcado como inferencia; y la tesis misma, una hipótesis que hay que poner a prueba, no un hallazgo.

La capacidad medida es real y ha crecido deprisa. SWE-bench pide a un sistema que resuelva issues reales de GitHub en repositorios Python reales y evalúa el resultado con las pruebas de los propios proyectos; en 2023 el mejor modelo resolvió el 1,96 % de ellos. En SWE-Bench Pro, más difícil, construido a partir de cambios más grandes y en parte de código comercial que nunca fue público, el mejor resultado de la primera versión del artículo, en septiembre de 2025, rondaba el 23 %; a mediados de 2026, la clasificación que mantiene el propietario del benchmark mostraba alrededor del 60 % en el conjunto público y alrededor del 50 % en el comercial, con harnesses que difieren entre entradas. El horizonte temporal de METR es la duración de una tarea, cronometrada por una persona experta, que un agente de IA completa la mitad de las veces. En sus tareas bien especificadas y evaluadas automáticamente, esa duración se duplicó aproximadamente cada siete meses entre 2019 y comienzos de 2025, y cada unos cuatro meses desde 2023 según su estimación de 2026.

Dentro de las organizaciones, el cambio aparece como volumen, comunicado por las propias empresas. Google informó en enero de 2025 de que las sugerencias de IA aceptadas sumaban el 67 % de los caracteres de código introducidos en los editores de sus ingenieros, sin contar el código pegado, y de que el 80 % de las modificaciones de una serie de grandes migraciones internas, un tipo de tarea bien especificado, fueron escritas íntegramente por IA, cada una revisada como cualquier otro código. En una encuesta no anónima a 132 de sus empleados, los ingenieros de Anthropic declararon usar su modelo en alrededor del 59 % de su trabajo, mientras que más de la mitad dijo poder delegar por completo como mucho una quinta parte.

La evidencia sobre productividad es más desigual de lo que sugiere la curva de capacidad. En un ensayo controlado aleatorizado realizado a comienzos de 2025 con 16 desarrolladores experimentados que trabajaban en proyectos maduros en los que llevaban años contribuyendo, METR constató que el acceso a herramientas de IA hizo que las tareas duraran un 19 % más, mientras los desarrolladores creían haber ido alrededor de un 20 % más rápido. Un estudio de seguimiento a comienzos de 2026 apuntó a aceleraciones modestas, con intervalos de confianza que incluyen el cero, y METR calificó esos datos de señal poco fiable, porque cada vez más desarrolladores se negaban a trabajar sin IA. Experimentos de campo con 4867 desarrolladores en Microsoft, Accenture y una tercera empresa, con coautores de Microsoft y realizados con el autocompletado de 2022 a 2024, hallaron un 26 % más de tareas completadas, con ganancias mayores, aunque estimadas con mucha incertidumbre, entre los menos experimentados. Un ensayo aleatorizado que Google hizo con 96 de sus propios ingenieros estimó alrededor de un 21 % menos de tiempo en una tarea, con un intervalo de confianza lo bastante amplio como para incluir la ausencia de efecto. La encuesta DORA de 2024 asoció cada aumento del 25 % en la adopción de IA con una caída estimada del 1,5 % en el rendimiento de entrega y del 7,2 % en la estabilidad de entrega; su informe de 2025 halló que el rendimiento ahora sube con la adopción mientras la inestabilidad sigue creciendo, y describió la IA como un amplificador de las fortalezas y disfunciones que una organización ya tiene.

Leídos en conjunto, estos estudios no muestran que la IA abarate la ingeniería de software. Son coherentes con algo más acotado, que este artículo infiere en lugar de medir: producir una implementación candidata se abarata más deprisa que establecer que una candidata es aceptable. La IA también está automatizando partes de la verificación, desde pruebas generadas hasta demostraciones comprobadas por máquina. Lo que no resuelve por sí sola es qué deben comprobar las comprobaciones. Esa asimetría es el punto de partida de todo lo que sigue.

Un benchmark da una tarea por resuelta cuando un parche hace pasar las pruebas designadas. Un sistema se acepta cuando las personas responsables están dispuestas a depender de él. La mayor parte de la dificultad vive en la distancia entre ambas cosas.

Los propios benchmarks muestran esa distancia. SWE-bench Verified existe porque, cuando 93 desarrolladores revisaron una muestra de las tareas originales en 2024, el 38,3 % fue marcado por enunciados infraespecificados y el 61,1 % por pruebas que podían rechazar soluciones válidas, un filtro que sus propios autores consideran probablemente demasiado estricto. En 2026, OpenAI dejó de informar del benchmark, después de que una auditoría de 138 tareas, elegidas porque su propio modelo fallaba en ellas una y otra vez, encontrara problemas importantes en las pruebas o los enunciados del 59,4 %, y de que todos los modelos punteros probados pudieran reproducir, para algunas tareas, la corrección original o detalles del enunciado. Un estudio presentado en ICSE 2026 halló que el 29,6 % de los parches de agentes contados como plausibles se comportaba de forma distinta a la corrección de los propios desarrolladores, no todos de forma errónea; junto con otras debilidades de las pruebas, eso infló las tasas de resolución publicadas en unos seis puntos porcentuales. Y METR pidió a mantenedores de scikit-learn, Sphinx y pytest que revisaran parches que pasaban las pruebas sin saber quién los había escrito. Los parches procedían de agentes publicados hasta finales de 2025, cada uno con un intento y sin retroalimentación, y aproximadamente la mitad no se habría integrado; METR subraya que esto no es un techo de lo que pueden hacer los agentes.

Más allá de las pruebas funcionales, el panorama es parecido. En BaxBench, un benchmark de aplicaciones de backend presentado en ICML 2025, el mejor modelo produjo un programa correcto el 62 % de las veces y, en promedio entre modelos, los exploits de seguridad tuvieron éxito contra alrededor de la mitad de los programas correctos. En 576.000 muestras de código generadas en 2024 por 16 modelos, el 19,7 % de los paquetes de software a los que se referían los modelos no existía, el 5,2 % en los modelos comerciales y el 21,7 % en los abiertos; un atacante puede registrar esos nombres. En un estudio de 2022 con 47 participantes, en su mayoría estudiantes, y un modelo temprano, quienes tenían un asistente de IA escribieron código menos seguro y creyeron con más frecuencia que era seguro. Un estudio cuasiexperimental de proyectos públicos de GitHub que adoptaron un editor de código con IA, Cursor, halló un aumento de producción grande pero pasajero, mientras las advertencias del análisis estático subieron un 30 % y la complejidad del código un 41,6 %, y se quedaron ahí.

La evidencia también apunta en sentido contrario, y eso importa. Un ensayo prerregistrado con 151 participantes no halló diferencias significativas en la facilidad con la que otros desarrolladores podían hacer evolucionar después código escrito con ayuda de IA. La mayoría de los estudios de seguridad citados no tiene una línea base humana comparable. Nada de esto muestra que el código generado sea peor que el humano.

Lo que sí muestra es que el código generado debe tratarse como lo que es: una implementación candidata. Un cambio candidato debe comprobarse frente a las restricciones de la arquitectura y frente a sus pruebas, validaciones y políticas; debe dejar evidencia de lo que se comprobó; y debe aceptarse o rechazarse sobre esa base. Donde una decisión conlleva un riesgo que ninguna comprobación puede resolver, debe consultarse a una persona. Ese modelo no depende de quién produjo la candidata.

Si las implementaciones candidatas abundan, la pregunta escasa pasa a ser cuál de ellas es aceptable, y responderla exige saber qué significa aceptable. Este artículo sostiene que, a medida que la implementación resulta más fácil de generar, aumenta el valor relativo de decidir qué debe seguir siendo cierto. Es una inferencia, no una medición, y no dice que el código no tenga valor.

Hay evidencia de apoyo en los márgenes. Más de un tercio de las tareas revisadas para SWE-bench Verified fue marcado como infraespecificado. Los modelos detectan mal cuándo una instrucción está infraespecificada, y los agentes que hacen preguntas aclaratorias rinden bastante mejor, hasta un 74 % en términos relativos, con un usuario simulado, en un estudio de ICLR 2026. Google describe cómo quien escribe código asistido por IA se convierte cada vez más en su revisor, y los ingenieros de Anthropic describen una paradoja de la supervisión: usar bien el modelo exige supervisarlo, y supervisarlo exige precisamente las habilidades que un exceso de delegación puede erosionar. El informe DORA de 2025 observa que la fricción no desaparece tanto como se desplaza, del trabajo manual a decidir y verificar. En la encuesta de Stack Overflow de 2025, más desarrolladores desconfiaban de la precisión de las herramientas de IA que confiaban en ella, un 46 % frente a un 33 %, y la frustración más común eran resultados casi correctos, pero no del todo.

Una forma útil de describir el cambio es separar dos preguntas. La arquitectura responde: ¿qué debe seguir siendo cierto? La implementación responde: ¿cómo se realiza aquí? Tomemos una propiedad: un resultado probabilístico no debe convertirse en silencio en un dato de referencia. Puede realizarse con validación de esquemas en tiempo de ejecución, con una frontera tipada que solo un servicio de validación puede construir, con un adaptador en la capa de aplicación o con una prueba de arquitectura en la integración continua que falla cuando se importa un cliente de modelo en el núcleo. Cada una cubre parte de la propiedad, con distinta fuerza; una regla de importación, por ejemplo, impone la dirección de una dependencia, no la propiedad misma. La tecnología puede cambiar. La propiedad permanece.

Una IA puede producir cada vez más el segundo tipo de respuesta. El primero sigue siendo una cuestión de intención, comprensión del dominio, riesgo y responsabilidad. La línea no es del todo limpia: una caché o una política de reintentos elegidas durante la implementación crean propiedades propias, así que el código generado sigue necesitando revisión frente a la arquitectura, no solo frente a sus pruebas.

La arquitectura de software ya tiene una noción de intención ejecutable. En Building Evolutionary Architectures, Ford, Parsons y Kua definen una función de aptitud arquitectónica como una evaluación objetiva de la integridad de una o varias características arquitectónicas. Herramientas como ArchUnit hacen que las reglas de dependencia entre capas se ejecuten como pruebas unitarias corrientes. Contratos, esquemas, sistemas de tipos, pruebas basadas en propiedades y, donde el coste lo justifica, verificación formal expresan la misma idea a distintas profundidades.

La definición de trabajo que se usa aquí es sencilla. Una restricción se vuelve arquitectónica en el sentido que interesa a este artículo, aplicada y no solo enunciada, cuando violarla hace que el sistema o su proceso de entrega rechace el resultado. Con esa definición, un principio que ningún build, ningún despliegue y ninguna comprobación en tiempo de ejecución puede hacer fallar sigue siendo una descripción, por cuidadosamente que esté escrito. No todo lo arquitectónico puede aplicarse así; cómo se descompone un sistema, o quién es dueño de qué datos, se juzga, no se comprueba.

Cuando la implementación abunda, la arquitectura trata menos de dibujar diagramas de sistemas y más de definir fronteras ejecutables: restricciones comprobables por máquina, propiedades de aceptación, requisitos de evidencia, pruebas de arquitectura, requisitos de observabilidad, fronteras de políticas y un comportamiento definido ante fallos. Dicho como tesis y no como definición de la disciplina: el artefacto del arquitecto ya no es solo un diagrama. Es también el conjunto de propiedades que el sistema es incapaz de violar en silencio.

Ejecutable no significa demostrado. Las pruebas muestrean el comportamiento; pueden revelar defectos, pero no mostrar que no queda ninguno. Propiedades distintas requieren aseguramientos distintos: tipos y esquemas para la forma de los datos, análisis estático y pruebas de arquitectura para las dependencias, pruebas basadas en propiedades para el comportamiento sobre muchas entradas, verificación formal donde una propiedad es crítica y puede especificarse, controles en tiempo de ejecución para lo que solo se observa en operación, y revisión humana para lo que ningún mecanismo puede juzgar.

La investigación sobre generar especificaciones junto con el código muestra a la vez la promesa y el límite. Modelos de lenguaje convirtieron intención en lenguaje natural en postcondiciones que detectaron 64 errores históricos reales del conjunto de datos Defects4J. En el benchmark VERINA, el mejor modelo escribió código correcto para el 72,6 % de las tareas, pero una especificación correcta y completa solo para el 52,3 %. Lahiri formula el límite de fondo: comprobar una implementación frente a una especificación puede definirse mecánicamente, pero no hay una vía algorítmica para asegurar que la especificación recoge lo que el usuario pretendía. Ese es el problema arquitectónico en una frase.

Un sistema no está bajo control porque a un modelo se le haya dicho lo que no debe hacer. Un prompt de sistema, una política escrita, una instrucción para evitar algo, la aparente disposición de un modelo a seguir una regla y una persona que repasa todo por encima después describen un comportamiento deseado. Ninguno de ellos bloquea de forma fiable un estado inaceptable cuando el modelo no coopera; una persona que repasa después detecta una parte, tarde y de forma desigual.

El control, en el sentido que se usa aquí, existe cuando un estado inaceptable puede detectarse, bloquearse, rechazarse o escalarse con independencia de la cooperación del modelo. Sus instrumentos son conocidos: restricciones de arquitectura ejecutables, fronteras de tipos, esquemas, validadores deterministas, pruebas de arquitectura y de contrato, comprobaciones en la integración continua que hacen fallar el build, aplicación de políticas, admisión en el despliegue, procedencia y trazabilidad, pruebas de aceptación, revisión humana controlada y puertas de publicación. Una regla que una IA puede ignorar todavía no es un control arquitectónico.

Una consecuencia es que los controles no necesitan saber quién escribió el código. La misma frontera restringe un cambio tecleado por una persona, un cambio sugerido por un asistente y un cambio producido de principio a fin por un agente. La pregunta importante ya no es solo quién escribió el código, sino si el sistema resultante preserva las propiedades exigidas. El perfil del NIST para el desarrollo seguro en equipos que construyen modelos de IA generativa adopta la misma posición respecto a las vulnerabilidades: sus prácticas no distinguen entre código fuente escrito por personas y generado por IA, porque todo código debe evaluarse antes de usarse. No es un régimen de vigilancia del código escrito por máquinas. Es arquitectura que restringe la implementación, sea cual sea su origen, incluidos los errores que cometen las personas.

También cambia lo que un sistema debe dejar tras de sí. Un sistema generado que solo parece correcto no ha dejado evidencia de lo que se comprobó. Las propiedades importantes deben dejar evidencia de que se evaluaron: qué pruebas se ejecutaron, qué versión de la política se aplicó, qué devolvió una validación, cómo se vincula un cambio con el requisito al que sirve, de dónde vinieron sus entradas y qué decidió la puerta de publicación. Los marcos de la cadena de suministro ya tratan registros de este tipo como algo que un build produce y un consumidor verifica: SLSA especifica la procedencia de cómo se construyó un artefacto, e in-toto verifica que cada paso de una cadena de suministro se realizó según lo previsto. La procedencia muestra cómo se produjo un artefacto, no que sea correcto.

Volvamos a la pregunta inicial. Si mañana la IA produjera cada línea de la implementación, la ingeniería seguiría teniendo que establecer qué puede significar y hacer la implementación, qué propiedades no puede violar en silencio y qué evidencia se necesita antes de poder confiar en ella.

En la práctica es una lista de responsabilidades: definir el propósito del sistema, decidir qué resultados son inaceptables, determinar qué cuenta como evidencia, resolver la ambigüedad semántica, fijar la tolerancia al riesgo, definir invariantes, revisar casos excepcionales, validar la arquitectura, aceptar el riesgo residual y seguir rindiendo cuentas. No todos los puntos necesitan que una persona los haga a mano cada vez. Cada uno necesita una persona o un rol con nombre, que actúe dentro de un proceso definido y responda de él. Un sistema puede automatizar trabajo sin dejar la responsabilidad sin definir. Menos programación humana no significa menos responsabilidad humana.

La intención humana no es automáticamente correcta, ni está automáticamente disponible. Un requisito que solo vive en la cabeza de alguien no es un control arquitectónico. Para restringir la implementación generada, la intención tiene que hacerse explícita, representarse de una forma comprobable, revisarse, versionarse cuando cambia y conectarse con la verificación que la aplica.

Donde esto resulta más difícil es en el significado. Un generador puede producir un sistema sintácticamente impecable que malinterpreta su dominio, porque los términos llevan contexto: la misma etiqueta significa cosas distintas en dos organizaciones, las definiciones de una norma cambian entre versiones y los datos que cruzan una frontera entran en un vocabulario jurídico distinto. Generar sintaxis no resuelve la alineación semántica. Decidir qué significa un campo, y mantener estable ese significado mientras los datos pasan entre sistemas, organizaciones y jurisdicciones, es trabajo de arquitectura que más implementación no sustituye.

La atención humana es además un recurso limitado con modos de fallo conocidos. Bainbridge observó en 1983 que la automatización deja a los operadores las tareas que sus diseñadores no supieron automatizar y les pide vigilar un sistema instalado precisamente porque hace el trabajo mejor que ellos. Una revisión sistemática sobre el sesgo de automatización, la tendencia a confiar en exceso en resultados automatizados, incluye el énfasis en la rendición de cuentas del usuario entre las medidas que lo reducen. La conclusión no es que las personas deban leer cada línea generada, algo que no escala. Es que los sistemas deben concentrar la atención humana en el juicio y el riesgo sin resolver, y dar consecuencias a esa atención.

Este artículo sostiene que solo se puede confiar en la autonomía de la implementación en la medida en que el comportamiento resultante pueda restringirse y verificarse de forma independiente. Dicho como principio y no como fórmula: la autonomía concedida a un agente de implementación debería guardar relación con lo independientemente que pueda verificarse su resultado. Donde las propiedades están bien especificadas y las comprobaciones son fuertes, como en una migración mecánica, una actualización de dependencias bajo un conjunto de pruebas exhaustivo o un adaptador detrás de una frontera tipada, puede delegarse mucho. Donde las propiedades son vagas, las comprobaciones débiles o el coste de un error alto, la autonomía debería crecer despacio o no crecer.

Según este argumento, la implementación puede volverse cada vez más autónoma sin que el control se vuelva autónomo. La autonomía la conceden las restricciones, se mide frente a la evidencia y se retira cuando la evidencia deja de respaldarla. Los criterios de aceptación no tienen por qué depender de quién escribió el código; cuánto puede hacer un productor antes de que una persona mire sí puede depender de su historial.

Por eso el argumento tampoco depende de un lenguaje o una plataforma concretos. La misma propiedad arquitectónica puede comprobarse en tiempo de compilación con un tipo en TypeScript, en tiempo de ejecución con un esquema en Python, con una frontera de módulo en Java o con una política de admisión en Kubernetes. Cuando la implementación cambia, incluso cuando se regenera, la propiedad es lo que sobrevive.

COADF, el Compliance-Oriented AI Development Framework, es una exploración práctica de esta tesis, y solo una. Es un método de desarrollo para sistemas de IA que tienen que sostenerse ante la regulación europea. Leído a la luz de esta tesis, pregunta qué propiedades deben seguir siendo ciertas cuando componentes probabilísticos participan en la producción, transformación o publicación de información, y cómo puede un build advertir que dejan de serlo. Surge del proyecto de investigación y desarrollo AnyLAI, que explora cómo la intención arquitectónica puede seguir siendo exigible en sistemas que contienen cada vez más comportamiento probabilístico y generado por máquinas.

Sus principios aplican la tesis a un caso más acotado: en qué puede convertirse la salida de un modelo mientras el sistema funciona. P-1 mantiene el comportamiento probabilístico acotado por el comportamiento determinista del sistema: un modelo devuelve un valor junto con su confianza y el método que hay detrás, nunca un valor desnudo. P-4 mantiene trazables las transformaciones importantes, desde una salida publicada hasta la evidencia en la que se apoya. P-6 convierte las barreras de protección en fences, comprobaciones que bloquean una publicación en lugar de consejos en un documento, y exige a cada fence que demuestre que se dispara. P-7 mantiene las normas externas, los sistemas de clasificación y los servicios terminológicos en adaptadores fuera del núcleo. P-8 mantiene las reglas explícitas y versionadas como datos, de modo que una decisión nombra la versión de la regla que la produjo. P-2 y P-3 establecen que una confianza baja nunca llega a una salida publicada y que ahí decide una persona, un hecho cada vez, frente a su fuente.

Solo sus plantillas de gobernanza abordan el otro caso, los agentes de IA que escriben código de producción. Una escala de autonomía fija cuánto puede hacer un agente antes de que una persona mire: en el peldaño más bajo, una persona lee cada línea; en el más alto, una persona lee los resultados de las pruebas y la salida de los guardianes, un peldaño que requiere una cobertura madura de fences y un historial y que, según el framework, debería seguir siendo raro. Una lista breve de decisiones, entre ellas los cambios en el esquema de la base de datos, la configuración de seguridad, los contratos de interfaz cuyo cambio rompe a quien los llama y los cambios en el propio sistema de fences, queda en manos de una persona en todos los peldaños.

COADF no hace segura la programación autónoma ni establece que el software generado sea correcto. No es un framework de programación autónoma. Hace explícitas y comprobables algunas suposiciones arquitectónicas, y se publica para que esas suposiciones puedan examinarse y discutirse.

No afirma que los desarrolladores de software vayan a dejar de ser necesarios, que la programación humana esté obsoleta ni que los desarrolladores vayan a ser sustituidos por arquitectos. Buena parte de lo que este artículo llama arquitectura lo hacen desarrolladores. La tesis trata de dónde crea más valor el esfuerzo de ingeniería, no de títulos profesionales.

No afirma que la IA ya pueda construir software de producción de forma autónoma, que la arquitectura elimine las alucinaciones ni que los controles adecuados sean todo lo que una IA necesita. La evidencia citada más arriba incluye mantenedores que rechazan alrededor de la mitad de los parches que pasan las pruebas, benchmarks que sobrestiman la corrección y fallos de seguridad en código generado.

Y no afirma que la transición que describe esté completa, sea universal o inevitable. Es una hipótesis sobre una dirección, con un mecanismo que puede examinarse: a medida que la implementación resulta más fácil de generar, la verificación se vuelve más importante, y el trabajo de decidir qué debe seguir siendo cierto pasa a ser una parte mayor de la ingeniería.

Una tesis solo es útil si produce preguntas que puedan responderse. Estas parecen las más apremiantes.

1. 01¿Cuánto detalle de implementación puede delegarse antes de que la verificación se convierta en el coste dominante?
2. 02¿Qué propiedades arquitectónicas pueden comprobarse automáticamente y cuáles siguen requiriendo juicio humano?
3. 03¿Cómo debería representarse la arquitectura para que tanto las personas como las máquinas puedan razonar sobre ella?
4. 04¿Puede la intención arquitectónica volverse verificable por máquina sin quedar atada a una tecnología de implementación?
5. 05¿Cuánta autonomía debería concederse cuando las técnicas de aseguramiento difieren en fuerza?

Ninguna tiene una respuesta definitiva. Entre la afirmación de que la IA solo ayuda a los desarrolladores a programar más deprisa y la de que los desarrolladores ya no son necesarios está la pregunta de la que trata esta investigación: qué debe ser incapaz de hacer un sistema, quién lo decide y cómo se aplica esa decisión.