La complejidad es el límite: diseño de software en la era de la codificación por IA

      La IA ha hecho que escribir código sea más rápido que nunca. El trabajo más arduo es entender un sistema y cambiarlo sin romperlo. Eso no se ha vuelto más barato, y ahora decide cuánto puedes delegar a una máquina.

      Introducción

      En 1987, en un ensayo llamado “No Silver Bullet”, Fred Brooks predijo que ninguna herramienta o técnica traería un aumento de diez veces en la productividad del software en una década [1]. Las décadas desde entonces han demostrado en gran medida que tenía razón, y la razón es que su argumento nunca se basó en la tecnología de su época. Brooks dividió la dificultad de construir software en dos tipos. La complejidad accidental es el esfuerzo incidental que nuestras herramientas imponen: sintaxis, boilerplate, plomería. La complejidad esencial es lo que el problema en sí demanda: averiguar qué debe hacer el sistema y diseñar una estructura que se mantenga a medida que crece. Las herramientas, argumentó, solo eliminan la complejidad accidental. Lo esencial queda intacto, y lo esencial es la mayor parte del trabajo.

      Los asistentes de codificación de IA son el ataque más efectivo a la complejidad accidental hasta ahora. Escriben una función o estructuran un conjunto de pruebas completo en segundos, y han hecho que las partes mecánicas de la programación sean más baratas que nunca. Eso ha fomentado una conclusión repetida con suficiente frecuencia como para sonar obvia: el código es barato ahora, por lo que el código en sí apenas importa. Describe lo que quieres, deja que el modelo lo genere, y cuando algo se rompa, cambia la descripción y regenera.

      El educador de software Matt Pocock hizo recientemente una versión del contraargumento en una charla de conferencia, y coincide con lo que veo en mi propio trabajo [2]. Dirijo la ingeniería de IA en una empresa de investigación legal, donde construir con estas herramientas es mi trabajo diario, y en una base de código real la conclusión de “el código es barato” no se sostiene. Escribir código es barato. Entenderlo y cambiarlo sin romper algo más no lo es, y un modelo tiene que entender una base de código antes de poder modificarla de manera segura. La complejidad de un sistema es, por lo tanto, el límite de cuánto puedes delegar a una máquina. En lugar de hacer que el diseño de software sea opcional, la IA eleva el costo de descuidarlo.

      El costo que no desapareció

      Cuando la gente dice que el código es barato ahora, lo que quieren decir es que es barato de escribir. Pero escribir nunca fue donde residía el gasto. La parte costosa del software es todo lo que viene después de que la primera versión funciona: darle sentido más tarde y cambiarlo sin romper algo que ni siquiera estabas mirando.

      El 💜 de la tecnología de la UE

      Los últimos rumores de la escena tecnológica de la UE, una historia de nuestro sabio fundador Boris, y un arte de IA cuestionable. Es gratis, cada semana, en tu bandeja de entrada. ¡Inscríbete ahora!

      John Ousterhout le da a este gasto un nombre preciso. La complejidad, en su definición, es cualquier cosa sobre la estructura de un sistema que lo hace difícil de entender o modificar [3]. Se presenta como amplificación del cambio, donde un pequeño cambio obliga a ediciones en muchos lugares a la vez; como carga cognitiva, la cantidad pura que un desarrollador debe mantener en mente para tocar el código de manera segura; y como desconocidos desconocidos, donde ni siquiera puedes decir qué partes podría afectar un cambio. Ninguno de estos tiene algo que ver con la velocidad de escritura. Todos se relacionan con la comprensión, y la comprensión es exactamente lo que generar código más rápido no compra.

      La IA mueve esta aritmética en la dirección equivocada. Un modelo produce mucho más código que una persona, y mucho más rápido. Eso significa más superficie para entender y más lugares a los que un solo cambio puede llegar, todo compitiendo por la misma memoria de trabajo. La carga de comprensión también se duplica, porque ahora dos partes tienen que entender el sistema: el modelo, que debe comprenderlo lo suficientemente bien como para cambiarlo correctamente, y tú, que debes comprender tanto el sistema como los cambios del modelo lo suficientemente bien como para confiar en ellos. “El código es barato” es medio cierto. Es la mitad peligrosa.

      La IA es un programador táctico

      Ousterhout traza una línea clara entre la programación táctica y la estratégica [3]. El programador táctico se optimiza para hacer que la tarea actual funcione y sigue adelante. El programador estratégico dedica un esfuerzo adicional a mantener la estructura del sistema limpia, de modo que el siguiente cambio sea más barato y seguro. El trabajo táctico es más rápido hoy y más costoso cada día después.

      Un modelo de lenguaje, dejado a sus propios valores predeterminados, es un programador táctico implacable. Está entrenado y se le indica que produzca código que funcione, no código que un colega estará encantado de heredar. Así que duplica un bloque en lugar de extraer la idea compartida, añade otro parámetro en lugar de repensar una interfaz, y busca una solución local que funcione en aislamiento y empeore silenciosamente todo. El Programador Pragmático llama a este desvío entropía del software: cada cambio realizado sin tener en cuenta el diseño del sistema lo empuja más hacia el desorden [4].

      Este desvío comienza a aparecer en los datos. Un estudio de 2026 examinó más de 300,000 commits generados por IA en más de 6,000 repositorios públicos, realizando análisis estáticos antes y después de cada cambio para medir lo que el modelo realmente introdujo [5]. Más del quince por ciento de esos commits añadieron al menos un nuevo problema, y de todos los problemas encontrados, casi nueve de cada diez eran olores de código: problemas estructurales que se compilan y pasan sus pruebas pero hacen que el código sea más difícil de entender y cambiar. El código funciona mientras el diseño se degrada silenciosamente. Esa es la complejidad accidental acumulándose un commit a la vez, y es exactamente el costo que un modelo que se optimiza por un resultado aprobado no se cobrará a sí mismo. Alguien tiene que proporcionar la capa estratégica que el modelo no proporciona, y esa persona es el ingeniero.

      Los módulos profundos son la superficie de control

      Si la complejidad es el problema, el instrumento más útil que Ousterhout ofrece contra ella es el módulo profundo: una unidad con una interfaz simple que oculta una implementación poderosa [3]. La idea precede al nombre. En 1972, David Parnas argumentó que un sistema debería dividirse no según los pasos de su computación, sino según las decisiones que cada parte puede ocultar del resto, de modo que un cambio dentro de un módulo no necesite repercutir en los demás [6]. El ocultamiento de información es el objetivo principal, y la profundidad es lo que lo hace funcionar.

      Esa misma profundidad resulta ser lo que decide cuánto puedes delegar de manera segura a la IA. Un módulo profundo te entrega dos cosas a la vez: un contrato lo suficientemente pequeño como para mantener en tu cabeza, y una implementación que puedes delegar. Especificas la interfaz, dejas que el modelo complete el cuerpo y revisas lo que importa en el límite: su contrato, sus invariantes, sus pruebas y cualquier interno sensible al riesgo, sin tener que reconstruir cada detalle de implementación. El módulo se convierte en una especie de caja gris: examinas sus bordes y las partes que conllevan un riesgo real, y dejas que el resto permanezca complejo en su interior.

      Un diseño superficial quita esa opción. Cuando el comportamiento se distribuye delgado a través de muchos módulos pequeños con interfaces porosas, no hay un límite contra el cual verificar, y entender cualquier cambio significa rastrearlo a través de todos ellos. Ese costo recae sobre ti y sobre el modelo al mismo tiempo. En la práctica, un agente hace su mejor trabajo dentro de un módulo bien delimitado, donde la tarea es legible y el contrato es claro, y su peor trabajo en código enredado, donde no puede decir qué depende de qué y empeora las cosas sutilmente mientras parece ayudar. La estructura de la base de código, mucho más que la astucia del prompt, establece el tamaño del trabajo que puedes delegar de manera segura.

      Las piezas encajan. Cuanto más limpio sea un sistema, más puede hacer un agente en él sin supervisión, y mejor será la retroalimentación que recibe mientras lo hace, porque tipos y pruebas fuertes en interfaces limpias le dicen a un modelo de inmediato cuándo se ha equivocado. La regla del Programador Pragmático se aplica tanto a las personas como a las máquinas: la tasa de retroalimentación es tu límite de velocidad [4]. Un sistema desordenado ralentiza esa retroalimentación mientras que el modelo acelera el daño.

      La evidencia de que este límite es real ha comenzado a llegar, y parte de ella es contraintuitiva. En un ensayo controlado aleatorio a principios de 2025, METR hizo que dieciséis desarrolladores experimentados de código abierto completaran tareas en grandes repositorios maduros que conocían bien, con y sin asistencia de IA [7]. Los desarrolladores esperaban que las herramientas los aceleraran en aproximadamente un quinto; medido contra el reloj, las herramientas los ralent