> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/es/2026/w21-the-inflection-point-of-software-engineering.md).

# W21-El punto de inflexión de la ingeniería de software

La semana pasada vi una charla del ingeniero de Google Adam Bender en Google I/O 2026, [La ingeniería de software en su punto de inflexión](https://io.google/2026/explore/workshop-2). Trata del impacto de la IA en la ingeniería de software y de los límites que alcanzará el ecosistema actual cuando la velocidad de generación de código se multiplique por diez o más.

La charla me recordó el libro [Ingeniería de software en Google](https://abseil.io/resources/swe-book/html/toc.html), conocido en el sector como el Flamingo book. Resume la experiencia central de más de veinte años de ingeniería de software en Google: monorepos, desarrollo sobre la rama principal, cambios a gran escala, revisión de código, sistemas de pruebas y cultura de ingeniería. Antes veía estas ideas sobre todo como buenas prácticas de las grandes tecnológicas. Al releerlas ahora, descubro que no hablan de una herramienta concreta, sino de cómo mantener la evolución del software a lo largo del tiempo y a mayor escala.

Ahí está la principal diferencia entre programar y hacer ingeniería de software. Programar consiste en escribir código para resolver el problema inmediato. La ingeniería de software se pregunta si, varios años y cientos de personas después, ese sistema seguirá siendo comprensible, modificable, verificable y capaz de evolucionar de forma segura. Escribir el código es solo el comienzo. Lo difícil es mantenerlo a largo plazo dentro de un ecosistema controlable.

Muchas prácticas de Google construyen, en esencia, un destino compartido. El monorepo permite que toda la empresa comparta los mismos activos de código. El desarrollo sobre la rama principal mantiene a todos alineados en una misma versión. Los cambios a gran escala permiten reparar automáticamente bibliotecas fundamentales y problemas de seguridad. La revisión de código y las retrospectivas sin culpables convierten la experiencia individual en capacidad organizativa. No se trata de venerar herramientas, sino de construir un sistema sociotécnico. Las herramientas resuelven los problemas de escala y la cultura de ingeniería resuelve los de colaboración.

Lo más interesante de la charla de Bender es que sitúa la IA dentro de este ecosistema, en lugar de limitarse a preguntar si puede escribir código. Los viejos problemas de la ingeniería de software no desaparecen con la IA: se amplifican. Coincido mucho con una idea de DORA: [la IA es un amplificador](https://dora.dev/capabilities/user-centric-focus/). Amplifica la magnitud, pero no determina la dirección. Si las pruebas, la arquitectura y los mecanismos de colaboración de un equipo son sólidos, la IA amplifica la eficiencia. Si esos cimientos ya son frágiles, amplifica el desorden.

Antes, una persona escribía decenas o cientos de líneas al día, y muchos problemas tardaban en aparecer. Con varios agentes modificando código a la vez, la velocidad de generación podría multiplicarse por diez o incluso por cien, y el sistema de ingeniería se acercará mucho más deprisa a sus límites. Cuando el código se abarata, resulta más fácil acumular código de baja calidad, y los activos de código se convierten pronto en pasivos. Los sistemas de compilación y pruebas sufrirán más presión. Una batería de pruebas que hoy puede completarse podría volverse inasumible por el crecimiento del código y sus dependencias. La revisión de código también encontrará un límite de capacidad. Si los expertos humanos solo alcanzan a revisar el enorme volumen de cambios generado por la IA, será fácil que se vean obligados a rebajar sus criterios.

Más problemático aún: sin restricciones globales, varios agentes podrían modificar mutuamente su código. Uno decide refactorizar de una manera y otro deshace el cambio, hasta crear una especie de «guerra civil de ediciones entre agentes». Suena a broma, pero no es del todo imposible bajo una forma de producción de código mucho más rápida y barata. Cuando faltan límites de abstracción claros y mecanismos de retroalimentación, el desorden también se automatiza a mayor velocidad.

Por eso la ingeniería de software en la era de la IA no puede centrarse solo en cómo conseguir que la IA escriba más código. Escribir código cuesta cada vez menos. Lo realmente escaso son las restricciones del sistema, la capacidad de verificación y el criterio arquitectónico. Tenemos que pasar de gestionar un árbol a gestionar un bosque. Antes nos ocupábamos de una función, un módulo o una revisión de código. En adelante tendremos que prestar más atención a los límites, los ciclos de retroalimentación y el orden de evolución de todo el ecosistema.

Creo que hay varias direcciones para las que los equipos deberían prepararse.

Primero, los tokens y la capacidad de cómputo para pruebas serán nuevos recursos de ingeniería. No deben tratarse como un fondo ilimitado.

Segundo, la estrategia de verificación tendrá que ser más inteligente. No bastará con ejecutar siempre todas las pruebas y recurrir a la revisión manual.

Tercero, los sistemas necesitarán un aislamiento más sólido para impedir que el código experimental de IA afecte con facilidad a los flujos centrales.

Cuarto, las personas tendrán que recuperar la comprensión del sistema. El mayor valor de la IA no consiste solo en ayudarnos a escribir código, sino también en comprender sistemas complejos, generar diagramas de arquitectura dinámicos, explorar dependencias y analizar efectos de segundo orden.

Esto se acerca mucho a lo que hemos estado hablando sobre ingeniería AI-Ready. Ser AI-Ready no consiste en conectar unas cuantas herramientas o escribir algunos prompts más. Consiste en preparar el sistema de ingeniería existente para soportar una producción con más velocidad, más concurrencia y más incertidumbre. La infraestructura, las normas de código, las pruebas, la documentación, la representación de la arquitectura y los mecanismos de revisión, tareas que antes parecían «lentas», serán aún más importantes en la era de la IA.

Los principios de la ingeniería de software no han cambiado. Han cambiado la productividad y la presión sobre el sistema. Cuanto más rápido se genere código, más necesario será volver a los fundamentos. La verdadera ventaja de un equipo quizá ya no sea escribir más código con IA, sino diseñar un ecosistema de ingeniería en el que la IA participe de forma segura, se verifique de manera continua y evolucione bajo control.