La IA es un amplificador, no una dirección.

Autor y fuente del artículo: InfoQ

La IA te hace escribir código 10 veces más rápido, ¿y luego? Más código significa compilaciones más largas, pruebas más pesadas, revisiones de código más bloqueadas y una base de código que nadie entiende. El software es una deuda; cuanto más rápido escribas, más debas.

La advertencia de Adam Bender, ingeniero principal de software de Google, es directa: el modo en que construyes software hoy no funcionará en una velocidad 10 veces mayor. Pero los verdaderos ganadores de la era de la IA no son los equipos que producen más, sino aquellos con las bases más sólidas. Porque la IA solo amplifica, no determina la dirección.

Durante una conferencia magistral en Google I/O 2026, Adam Bender planteó una pregunta que la mayoría aún no ha tenido tiempo de considerar: ¿qué se derrumbará primero en nuestro ecosistema de desarrolladores cuando la IA impulse la velocidad de producción de código más allá de lo que los procesos de ingeniería actuales pueden soportar? Utilizó un concepto que probablemente no ha escuchado antes para unir toda la charla: la ecología del software, es decir, el estudio integral del ecosistema sociotécnico que produce software. En otras palabras, no solo debes observar la tecnología, sino también a las personas, la cultura y las reglas no escritas dentro de las organizaciones. Basado en el video de la conferencia, InfoQ ha organizado el contenido.

Los puntos clave son los siguientes:

• La IA no resuelve automáticamente ningún problema. Si tu práctica es buena, la amplifica. Pero si no es suficientemente buena, solo genera más problemas.
• Es genial que todos sean constructores, hasta que debas mantener todo lo que todos han construido.
• Las prácticas de ingeniería no son sagradas e inalterables. Las prácticas cambian; lo importante son los principios.
• Como ingeniero de software en primera línea, en este momento crítico, estás en el núcleo de la decisión sobre hacia dónde se dirigirá la ingeniería de software. Desde herramientas hasta flujos de trabajo, desde prácticas de ingeniería hasta cultura de ingeniería, si puedes comprender el sistema que está en funcionamiento, podrás encontrar palancas.

¿Qué es un "sistema"?

Tu trabajo en 2026 es completamente diferente a lo que imaginaste en 2020. Si intentara explicarle a mi yo de 2020 lo que está sucediendo hoy, no me creería. Ha habido demasiados cambios, tantos que resultan abrumadores. No puedo predecir el futuro, pero creo que si estudiamos cuidadosamente el ecosistema de software actual, algunas respuestas están más cerca de lo que imaginamos.

Hoy quiero hablar contigo sobre una palabra: ecología de software. Suena como si la hubiera inventado para subir al escenario, pero no es así; es un término real. Antes de dar una definición, quiero proporcionar un poco de contexto y profundizar un poco en el pensamiento sistémico.

Un sistema es un conjunto de elementos interrelacionados que funcionan según un conjunto de reglas para formar un todo unificado. Suena abstracto, pero no eres ajeno a los sistemas. Por ejemplo, el aire acondicionado: un termostato que conoce la temperatura objetivo, un sistema de calefacción, ventilación y aire acondicionado que calienta o enfría, una habitación; cuando la temperatura es adecuada, la señal se detiene. Este es un sistema.

Si eres ingeniero de software, todos los días trabajas con sistemas, diseñas sistemas, construyes sistemas y operas sistemas; en este proceso, probablemente aprendiste una cosa: todo está conectado.

A continuación, el ecosistema: es un sistema especial. La definición es un poco larga, pero importante: un ecosistema es una red dinámica de actores interdependientes que coevolucionan con su entorno, caracterizada por comportamientos emergentes y autonomía descentralizada. En términos sencillos, un ecosistema es complejo, con componentes profundamente interconectados, cada uno con su propia autonomía para tomar decisiones y actuar. Y lo más importante: el entorno forma parte del sistema; no puedes separarlos.

Un ecosistema también es un sistema complejo adaptativo que puede crecer, cambiar y evolucionar con el tiempo. Además, poseen una característica llamada propiedad emergente: algo que no puedes ver al observar cualquier componente individual, sino que solo surge cuando el sistema completo está ensamblado. Es precisamente esta combinación de cambio continuo, aprendizaje constante y emergencia lo que hace extremadamente difícil comprender qué está sucediendo dentro de un ecosistema.

Cuando se habla de ecosistema, probablemente te vengan a la mente montañas, ríos, cantos de pájaros y flores perfumadas. Pero el entorno de desarrollo interno también es un ecosistema: contiene diversas herramientas y servicios, personas con sus propias ideas y necesidades, y restricciones empresariales. Y es un sistema especial: un sistema socio-técnico, es decir, un sistema compuesto por personas y tecnología. Los sistemas socio-técnicos son extremadamente complejos, porque comienzas con todas esas tecnologías y luego introduces a las personas.

Probablemente ya hayas estado expuesto a la inteligencia de los sistemas sociales técnicos sin darte cuenta. ¿Conoces la ley de Conway?: la tecnología que construyen las organizaciones refleja su estructura interna de comunicación. En términos sencillos, si tienes cuatro equipos trabajando en el mismo compilador, terminarás con un compilador de cuatro pasos, y punto. La observación central de la ley de Conway es que la forma en que construimos tecnología está intrínsecamente ligada a la estructura organizacional que la crea; la organización da forma a lo que finalmente se construye.

Pero no solo la estructura organizacional influye en el ecosistema de desarrolladores; los valores y la cultura también tienen un impacto profundo. El ecosistema que construyes es lo que la organización incentiva; tu cultura de ingeniería crea el entorno que rodea al ecosistema de desarrolladores. Una vez que comprendes los sistemas socio-técnicos, los verás en cada rincón del desarrollo de software: arquitectura, cultura de análisis de incidentes, revisiones de código, políticas de seguridad, en todas partes. Lo que construimos y la forma en que elegimos construirlo refleja lo que valoramos. Si prestamos suficiente atención, podemos aprovechar este conocimiento para amplificar nuestros valores e inyectarlos en lo que construimos.

Ahora puedo darte una definición correcta: la ecología del software es la disciplina que estudia de manera integral el ecosistema sociotécnico de la producción de software. Si lo anterior fue un poco abstracto, no importa; ahora veamos un caso real.

El ecosistema de desarrolladores de Google

Hablo de Google no porque trabaje allí y quiera alabarlo, sino porque es el ecosistema de desarrolladores que mejor conozco. Mi objetivo no es decirles que deben copiar a Google, porque eso no les beneficiaría. Son empresas diferentes, en etapas distintas y enfrentan diferentes compromisos. Muchas de las decisiones que tomó Google se basaron en las necesidades específicas que teníamos al construir nuestro ecosistema en ese momento.

Hace unos años escribimos un libro, internamente llamado "El libro del flamenco". La mitad del libro trataba sobre control de versiones y pruebas, pero toda la primera parte se centraba en la cultura de ingeniería. Mucha gente preguntaba por qué dedicábamos tantas páginas a la cultura, porque si no entiendes la cultura de Google, no puedes comprender por qué tomamos esas decisiones técnicas; todo está interrelacionado.

Google tiene varias características culturales únicas. Somos profundamente orientados a la ingeniería, y los ingenieros siempre están presentes al tomar decisiones importantes; valoramos extremadamente la transparencia, abriendo tantos documentos y código como sea posible a todos; fomentamos la disposición para ayudar, de hecho, cualquier persona que haya dejado Google mencionará primero la generosidad de sus colegas; consideramos la revisión de código como una oportunidad de orientación, no como una corrección de exámenes; valoramos enormemente la estandarización; creemos en la mejora continua; promovemos revisiones de incidentes sin culpa; estamos convencidos de que la sostenibilidad supera al heroísmo y la automatización supera al trabajo manual. Por supuesto, no siempre alcanzamos todos estos ideales, pero esta es la dirección hacia la que esforzadamente trabajamos en nuestra cultura.

¿Qué hay de lo técnico? Un solo repositorio de código, donde casi todo el código está en un solo repositorio; desarrollo basado en la rama principal, donde cada cambio se integra directamente en la rama principal; al construir un archivo binario, casi cada línea de código se compila desde el origen; una cadena de herramientas de construcción unificada que todos utilizan; una plataforma global de automatización de pruebas, donde se ejecutan todas las pruebas en un solo lugar, con miles de millones de casos de prueba diarios; una señal global de "último estado verde" que me permite decirte el estado de cualquier compilación mediante un simple sitio web interno; un entorno de cómputo unificado, por lo que el problema de "en mi máquina funciona" prácticamente no existe; marcos de desarrollo altamente estandarizados y un pequeño conjunto de lenguajes de programación principales.

Esta mezcla de cultura y tecnología es lo que ha formado a Google tal como es hoy; no puedes comprender solo la mitad y ignorar la otra.

Compartir el destino

Si tuviera que elegir un principio que haya estado guiándonos sutilmente, elegiría “Destino Compartido (Shared Fate)”. Describe el grado de interconexión entre un ecosistema y sus componentes; en un ecosistema con alto destino compartido, un componente puede afectar a todos los demás. En el ecosistema de desarrolladores, el destino compartido es tanto una elección técnica como una elección social. No puedes lograr el destino compartido simplemente haciendo que todos usen la misma tecnología; también necesitas establecer un contrato social sobre cómo gestionar estas tecnologías.

En Google, compartir el destino comenzó con un repositorio de código único. Cada línea de código de la empresa, con pocas excepciones como Android y Chrome, se encuentra en un repositorio compartido. Todo el código se envía al tronco principal, sin ramas ni números de versión; todo está en un solo lugar. Esta shared fate nos permite aplicar un parche de seguridad en un solo archivo y saber que, en una semana, todas las aplicaciones de la empresa estarán corregidas. Corregir mil millones de líneas de software de aplicaciones y sistemas con solo diez líneas de código es como tener un superpoder.

Pero compartir el destino no siempre es algo bueno; es una elección. En algunos lugares, compartir el destino no es apropiado, como en entornos de producción, donde nunca deseamos que un servicio arrastre a todos los demás, o que un clúster infecte toda una región. Por eso hemos invertido mucho esfuerzo en evitar los peligrosos destinos compartidos que provocan fallos en cascada. Compartir el destino es un compromiso; debes encontrar el lugar adecuado y asegurarte de que funcione a tu favor.

Cambio a gran escala

Uno de los atributos emergentes más interesantes en nuestro entorno compartido es el cambio a gran escala. Tenga en cuenta esto: mucho antes de que surgiera la IA, las herramientas internas de Google ya permitían a un desarrollador modificar millones de líneas de código, millones de líneas que nunca leería, nunca volvería a ver y posiblemente no conocía en absoluto. Hemos construido herramientas que hacen posible todo esto de forma automática, y así ha sido hoy, y lo hemos hecho al menos durante los últimos quince años.

Esta capacidad nos permite evolucionar continuamente el repositorio de código monolítico, actualizar lenguajes y marcos, y evitar que el entorno interno se vuelva rígido. Sin exagerar, sin cambios a gran escala, no seríamos la Google de hoy. Los colegas que desarrollan estas herramientas realizan un trabajo de héroe tras bambalinas que permite a la empresa avanzar a la velocidad que necesita.

Pero lo fundamental es que no puedes comprenderlo realmente si no entiendes los componentes culturales y técnicos que hacen posibles los cambios a gran escala. ¿Qué necesitas? Una cultura de pruebas generalizada, donde todos escriban pruebas. Una plataforma de pruebas unificada, para que sepas dónde obtener los resultados. Herramientas de construcción comunes, para que tu construcción sea idéntica a la mía. Bibliotecas estandarizadas, para que al reemplazar componentes no tengas que saltar de una versión a otra buscando cuál funciona para ti pero no para mí. Revisiones de código estandarizadas y transparencia en el repositorio de código, para que sepas qué código necesita modificaciones. Los cambios a gran escala son la máxima expresión de la filosofía de Google de "automatización sobre trabajo manual", y solo son posibles cuando todo el ecosistema colabora. No puedes señalar una sola parte del entorno de desarrollo y decir: "esto es lo que lo causó"; es la conexión de todas las partes lo que lo explica.

Tu ecosistema, tus equilibrios

Cada ecosistema de desarrolladores tiene estas propiedades emergentes. Por lo general, son precisamente lo que te hace sentir que tu lugar de trabajo tiene algo único, porque son el resultado de una serie de decisiones que has tomado.

El ecosistema de desarrolladores de Google ha generado un conjunto único de compromisos que sirven a nuestros objetivos tecnológicos y comerciales. Pero, como cualquier ecosistema, no puede destacar en todas las tareas. Hemos optado por optimizar la escala extrema, la seguridad y el rendimiento, incluso si eso implica sacrificar en ocasiones la productividad de los desarrolladores; estamos dispuestos a hacer este compromiso. Un ecosistema de una startup de cinco personas luciría completamente diferente, donde la velocidad y la agilidad serían lo más importante.

La mayoría de ustedes se encuentran en un ecosistema que va de cinco personas a doscientas mil. Los compromisos que deben hacer son muy importantes, porque al examinar estos compromisos, puede comenzar a entender los valores de la organización: qué es lo que realmente le importa, no lo que dice que le importa, sino lo que sus decisiones reales revelan. Cuando comprenda estos valores, podrá comenzar a dar forma al cambio que está teniendo lugar.

Momento de 10x: Cada nodo está bajo presión

Es hora de hablar del elefante en la habitación que se come los tokens: ¿cómo se ve realmente un ecosistema de desarrolladores con IA como prioridad?

Claro, construir un ecosistema completamente nuevo desde cero suena ideal, pero nadie tiene ese lujo. Deben seguir entregando software mientras reemplazan casi cada componente. La empresa confía en que sigas generando valor, al mismo tiempo que garantizas que no ocurran problemas.

Entonces, pregúntate esto: ¿cuánto sabes sobre tu ecosistema de desarrolladores hoy? ¿Puedes dibujarlo por completo? ¿Sabes dónde están todas las piezas, no solo las técnicas, sino también las sociales? ¿Puedes enumerar qué compone tu ecosistema? ¿Cuánto saben los demás en tu organización? ¿Cuáles son sus fortalezas y debilidades? ¿Dónde están los cuellos de botella? ¿Dónde hay restricciones y dónde hay libertad? ¿Qué opciones tienes? ¿Qué propiedades emergentes has observado? Quizás lo más importante: si tu ecosistema tuviera que procesar de repente de 10 a 15 veces más cantidad de código en los próximos dieciocho meses, ¿sabes qué se rompería primero?

Cada ecosistema de desarrolladores en la Tierra está experimentando una transformación radical; quizás aún no haya llegado a cada rincón donde te encuentras, pero está en camino, y cada ecosistema de desarrolladores deberá enfrentar este momento de 10 veces. Es una época increíble, pero también bastante confusa. Los equilibrios y compromisos que hemos desarrollado intencionalmente durante los últimos veinticinco años serán reequilibrados.

Generar código 10 veces más rápido y acelerar el desarrollo de ingeniería 10 veces son dos cosas diferentes. En Google, decimos comúnmente que la ingeniería es programación integrada a lo largo del tiempo. Pero el problema es que estamos acelerando enormemente la etapa de programación, haciendo que la máquina de código funcione más rápido. Por lo tanto, debemos encontrar formas de realizar una buena ingeniería alrededor de esta máquina de código para entregar realmente resultados a los clientes. Nadie sabe hasta dónde puede llevar esta oleada de crecimiento de productividad, pero hay una cosa segura: desde aquí, estamos subiendo.

El problema es que la forma en que construimos y entregamos software hoy no funcionará a 10 o 100 veces la velocidad; algo debe cambiar.

Comencemos con una versión simplificada del mapa del ecosistema de desarrolladores. ¿Qué debe cambiar en un mundo donde la actividad aumenta diez veces?

Código ingresado

Escribe el código fuente. Si cada persona escribe código mucho más rápido, la cantidad de código aumentará mucho, y eso no es algo bueno. Jeff Atwood dijo que el software es una deuda. Por lo tanto, 10 veces más código, 10 veces más deuda. Y no puedes simplemente darle a cada persona un montón de tokens y decirles “buena suerte”; espero que inviertas después de tu capacitación: ¿sabes dónde está tu documentación de prácticas de ingeniería? ¿Sabes cómo evolucionarla? Considera eso después.

Construir sistemas. Más código, sistemas más grandes significan tiempos de compilación más largos. Estoy seguro de que nadie en su empresa actualmente se queja de que la compilación es lenta. Pero adivinen qué, se volverán aún más lentas. Y si el agente impulsa una gran cantidad de trabajo, el número de compilaciones también aumenta exponencialmente. La compilación no es gratuita, ni en tiempo ni en recursos computacionales. Es posible que nunca haya notado cuánto tiempo dedica a la compilación, pero a una escala 10 veces mayor, seguro que lo notará.

Diseño de código. ¿Cuentas con habilidades adecuadas basadas en agentes para fomentar el desacoplamiento? ¿Tienes un marco de servidor adecuado para garantizar la combinación rápida y segura de diversas capacidades? ¿Sabes cuántas formas de despliegue existen para las aplicaciones web en tu empresa? ¿Cuántos marcos de servidor diferentes están en funcionamiento? ¿Cómo gestionas la reutilización de componentes del código escrito por agentes? Tal vez estés apostando a que esto no es importante. Pero si los agentes generan código fácil de escribir pero difícil de mantener, no te sorprendas demasiado: ese es el nivel actual de referencia. Los agentes son excelentes escribiendo código, pero no siempre piensan a largo plazo. Ese código, estoy seguro, no se reestructurará bien. No importa, resolveremos esa parte más adelante. Pero el hecho es que los agentes están realizando una gran cantidad de trabajo para nosotros, y debemos encontrar cada día formas más eficientes de aplicar estas capacidades.

En algún momento, estos trabajos agentizados podrían hacer que tus archivos binarios sean tan grandes que no se puedan compilar, o tan grandes que ya no se puedan subir al teléfono. ¿Te has preguntado alguna vez: cuál es el tamaño máximo de binario que puedes compilar? No sé la respuesta, pero sé que en Google estamos llegando al límite, y en algunos lugares los binarios ya son tan grandes que no se pueden compilar; creo que encontraremos una solución. Pero la realidad es que la escala tiene muchas consecuencias en cadena, y el impacto de la escala está en todas partes.

Tal vez estés en una pila de microservicios y pienses: "Mis servicios son muy pequeños, ¿por qué preocuparme?". Pero tengo una pregunta: ¿estás preparado para 10 veces el tráfico de red, 10 veces la cantidad de servicios y 10 veces el volumen de comunicación? Nadie puede salir indemne; el impacto de la escala está en todas partes.

Revisión de código. Supongamos que no puedes compilar confiablemente todo este código, ¿cómo sería tu proceso de revisión de código? Todos están preocupados por la revisión de código, y con razón. Estamos sometiendo a este proceso profundamente humano a una presión enorme, y en muchos casos se está convirtiendo en un cuello de botella, y a las personas no les gusta ser un cuello de botella. Cuando les aplicas presión, su comportamiento se vuelve extraño. Diez veces más código significa o bien cambios diez veces más grandes, o diez veces más cambios. ¿Puede tu líder técnico mantener la velocidad de revisión necesaria? La mayoría de los líderes técnicos ni siquiera pueden revisar el código generado por cinco desarrolladores 10x en un solo día.

Entonces, para evitar convertirse en un cuello de botella, comenzarán a reorganizar los procesos, buscarán atajos y se asegurarán de no bloquear a nadie, porque nadie quiere ser el que bloquea. Quizás puedas resolver parte de esto con IA, implementando IA para mejorar la revisión de código. Pero esto solo resuelve una parte del problema, porque si tus miembros del equipo ya no escriben código, el único momento en que interactúan con él es durante la revisión, y si la atención durante la revisión es insuficiente, ¿quién está monitoreando la evolución del repositorio? Nadie. Pronto, tu repositorio de código se convertirá en un desastre que nadie pueda entender.

Economía de tokens. Los tokens son caros, algunos de ustedes ya lo saben. A gran escala, el token es un costo real que debes considerar. ¿Qué sucedería si todos en la empresa comenzaran a usar 10 o 100 veces más tokens? ¿Qué pasaría si accidentalmente gastaras todo tu presupuesto mensual en un solo día? ¿Si tuvieras que priorizar dónde gastar los tokens, sabrías dónde invertir primero? ¿Siquiera tienes visibilidad sobre hacia dónde están fluyendo los tokens?

Ya hemos identificado problemas en los primeros nodos de este sistema simple. Y es muy claro que habrá algunos efectos de segundo orden desafiantes.

Pruebas y control de versiones

¿Has visto alguna vez cuántos recursos de cómputo consume tu infraestructura de pruebas? En Google, nunca he estado satisfecho con la velocidad de mis pruebas.

Cada cambio incorporado al control de versiones debe ser probado. Pero además, los agentes también disfrutan ejecutando pruebas, ya que estas les indican qué tan bien están desempeñándose. Por lo tanto, los agentes generan carga de trabajo adicional, lo que aumenta mi cantidad de tareas. Entonces, ¿cuántos recursos de cálculo para pruebas consume ahora un volumen de commits 10 veces mayor, más todo el trabajo realizado por los agentes?

La situación podría ser incluso peor. En Google, observamos que a medida que la base de código crece, el gráfico de dependencias crece de forma cuadrática, no lineal. Por lo tanto, si tu base de código se vuelve 10 veces más grande, es posible que necesites ejecutar no 10 veces más pruebas, sino 100 o incluso 1000 veces más. Esto representará un desafío muy interesante, y en algún momento se convertirá en una línea en tu presupuesto. Si actualmente no te preocupas por el costo de los recursos de cálculo para las pruebas, eso me preocupa aún más, porque significa que probablemente no tienes suficientes pruebas, y esos agentes están operando en tu base de código sin red de seguridad.

Suponiendo que los problemas de compilación y prueba se han resuelto, ahora veamos el sistema de control de versiones. La mayoría de los sistemas de control de versiones populares no están optimizados para el rendimiento; están optimizados para la coherencia y el orden. Ese es su trabajo principal: mantener un registro completo, no correr a toda velocidad. ¿Cuántas confirmaciones puede procesar tu sistema de control de versiones por minuto? Te aseguro que es mucho menos de lo que imaginas. No puede escalar hasta la velocidad 10 veces mayor que necesitas. ¿Cuándo fue la última vez que pensaste en el rendimiento de tu sistema de control de versiones? Si no estás desarrollando Git, probablemente nunca lo has hecho. Honestamente, llegar a discutir el rendimiento del control de versiones indica que algo ha salido gravemente mal. Estamos en la capa más básica de la experiencia del desarrollador, pero este es el resultado de los cambios sistémicos: encuentran cada rincón de tu sistema y dicen: “Oye, ¿estás prestando atención? Porque llega algo que no esperabas.”

Para aquellos que piensan resolver problemas de control de versiones con muchos pequeños repositorios, pregúntenle a alguien que haya gestionado cientos o miles de pequeños repositorios; puedo asegurarles que eso solo genera un nuevo conjunto completo de desafíos, y la IA no garantiza que estos problemas se vuelvan más fáciles.

Lista de incidentes

Hasta ahora solo hemos estado examinando esos nodos de capacidad relativamente fáciles de identificar, que consisten en multiplicar un número por 10 y preguntarse si será bueno o malo, además de muchos desafíos inesperados.

Verificar la estrategia. Hoy en día, tu verificación probablemente consiste en muchas pruebas unitarias y algunas pruebas de integración. Pero en un mundo con 10 veces más código y 10 veces más servicios, las pruebas de integración se convertirán en la parte más importante de la estrategia de calidad. ¿Cuántas personas aquí están satisfechas con su actual方案 de pruebas de integración? Yo tampoco lo estoy. Las pruebas de integración son realmente difíciles; aún no tengo las herramientas que necesito para realizar pruebas de integración de la manera que deseo.

Problema de conjunción booleana. Hoy lanzas un software y exiges que todas las pruebas pasen, que todos los valores booleanos se vuelvan verdes, y que todo esté en orden antes de lanzar; esto es razonable. ¿Qué sucede cuando tienes un millón de pruebas y la propia infraestructura de pruebas subyacente tiene problemas de confiabilidad para ejecutar un millón de pruebas? Es posible que ya no sea factible requerir que todos los valores booleanos sean verdaderos para lanzar el software. Necesitas una nueva estrategia, probablemente basada en métodos estadísticos, para determinar qué pruebas son correctas y deben ejecutarse, ya que no puedes ejecutar todas las pruebas.

Cambio masivo. Es emocionante poder reestructurar completamente, cambiar lenguajes y marcos. Pero ¿tienes un flujo de trabajo y un contrato social que permita a las personas gestionar conflictos de fusión de decenas de miles, cientos de miles o millones de líneas? Probablemente no. Si todos en la empresa pudieran realizar cambios masivos, necesitaríamos nuevas estrategias de flujo de trabajo.

Guerra de agentes. Un agente realiza un cambio, otro agente llega diciendo: “No, no me gusta, voy a hacer un cambio diferente”. Parece gracioso, hasta que te das cuenta de que estás pagando tarifas en tokens por ambos lados.

Frecuencia de lanzamiento. ¿Con qué frecuencia publicas a tus clientes hoy? ¿Cada día? Eso está bien. Si no es así, aquí hay un problema: obtendrás más de 10 veces más software, y todo eso debe ir a algún lado. Si no publicas diariamente, cada cambio se vuelve mucho más grande. Y tus amigos de SRE te dirán que los cambios muy grandes son muy aterradoras. No lo hagas. Pero el código debe desplegarse para generar valor, por lo que podrías intentar publicar con más frecuencia, lo cual está bien, y los amigos de DORA se alegrarán. Pero en algún punto, los rendimientos disminuyen; publicar una vez por segundo probablemente no te aporte mucho valor. El código seguirá creciendo, y necesitas entender dónde colocarlo sin generar más riesgos.

API interna. He estado diciéndole a mis colegas que de la noche a la mañana, todas tus API se volvieron públicas. El agente no te consultará; encontrará la API y la llamará directamente. Usará todo lo que pueda acceder, te lo garantizo. Si nunca has fortalecido tus interfaces internas y conjuntos de datos internos como lo harías con una API pública, el agente encontrará cosas que no deseas que se descubran.

La paradoja de Jevons. Jevons dijo que cuanto más barata y eficiente sea una reserva, más la usamos. El auge de los tokens es un ejemplo vivo. Los estamos colocando en todas partes, lo que está cambiando cómo trabajamos y cómo pensamos sobre el trabajo. Estamos asignando un valor a trabajos de productividad previamente invisibles, ¿qué impacto tendrá esto en nuestro comportamiento? Todavía no lo sé.

Rollback. ¿Sabes por qué el rollback es hoy básicamente factible? Porque publicas software ligeramente más lento de lo que tardas en detectar problemas en tu entorno de producción. ¿Qué sucedería con tu postura de rollback si pudieras publicar extremadamente rápido, tan rápido que no tuvieras tiempo para detectar ningún problema? Cada rollback tendría que lidiar con múltiples cambios conflictivos acumulados encima. Por lo tanto, simplemente publicar más rápido no es suficiente; debes considerar todo el sistema, incluido el rollback, como un importante mecanismo de seguridad. Por cierto, debes tener cuidado con dónde colocas el motor de tokens. Si tu proceso de rollback depende de que un agente tenga suficiente capacidad, y alguien agotó previamente el presupuesto de tokens de ese agente, impidiéndote ahora realizar un rollback, probablemente no sea algo bueno.

Todos son constructores. Probablemente has pensado en crear una alternativa al tool que no te gusta en la empresa. Ahora, multiplica eso por cada persona y cada herramienta en la empresa. ¿Qué sucede con la estructura social de la empresa cuando todos usan herramientas completamente diferentes? Si tienes suerte y cuentas con una base de datos unificada donde todos los datos convergen en un solo lugar, está bien. Pero ¿y si no la tienes? Que todos sean constructores es genial, hasta que debes mantener todo lo que todos han construido.

Curso intensivo de liderazgo técnico. Llevar tanto tiempo convertirse en un líder técnico se debe a que debes acumular intuición, juicio y competencia profesional para tomar decisiones, porque cuando lideras un equipo, tus errores tienen un impacto mucho mayor que cuando actúas solo. ¿Qué puede salir mal cuando un recién graduado entra en un entorno donde puede invocar cincuenta agentes, pero carece de intuición y juicio? ¿Cómo puedo enseñar diez años de experiencia en seis meses? No lo sé.

La atención humana es nuestro recurso más valioso. Ahora hay mucho ruido, tantos agentes y tantas cosas compitiendo por nuestra atención, y debemos encontrar formas de gestionarlo. Anteriormente nos beneficiábamos del hecho de que nuestra capacidad para causar problemas no superaba nuestra capacidad para invertir atención, pero ahora ya no es así.

Suena como mucho, porque en un sistema, todo está conectado. Todos los desafíos que mencioné antes, no puedes resolver ninguno solo mirando un solo nodo del sistema; debes ver todo el sistema.

Para adaptarnos al desarrollo basado en agentes, todos debemos comenzar a aprender a pensar de manera sistemática y continua. Cuando piensas en un sistema, estos son los aspectos que debes considerar: cómo las cosas crecen, los efectos que cambian con el tiempo, la dirección en la que fluyen las relaciones de causa y efecto, qué nodos están comunicándose con todos sus vecinos, cómo se ve lo emergente y qué son esas cosas que aparecen sin una fuente clara. ¿Y los mecanismos de incentivo? Incluyendo los sociales y los técnicos, la capacidad, los bucles de retroalimentación y los cuellos de botella: estos son las herramientas del análisis sistémico.

Parece complicado, pero realmente solo necesitas dos preguntas: ¿por qué (Why?), y ¿y si (What if?)? ¿Por qué tenemos tan pocas pruebas de integración? ¿Y si tuviéramos más pruebas de integración que pruebas unitarias? ¿Por qué usamos estos lenguajes específicos? ¿Y si la IA escribiera todo el código?

“¿Por qué?” es la broca que usas para profundizar en el núcleo del sistema y entender cómo funciona. Todos ustedes son muy buenos preguntando “¿por qué?”, pero “¿y si?” es la parte más difícil. “¿Y si?”, puede resultar aterrador, si requiere que abandones prácticas que antes creías muy bien diseñadas. ¿Y si no las pruebas? ¿Y si no escribes pruebas en absoluto? No vayas demasiado lejos. Pero si permites que suceda, “¿y si?” también puede ser bastante emocionante.

La IA es un amplificador, no una dirección

La IA es un amplificador. Esta idea proviene de mis amigos en DORA, cuyo informe de desarrollo de IA del año pasado descubrió una relación entre los equipos que realmente comprendieron las cosas: descubrieron cómo hacer que la IA sea un amplificador.

La IA puede darte más: más pruebas, más documentación, más código, pero también más confusión. La amplificación es una magnitud, no una dirección. A la IA no le importa adónde van esas cosas; simplemente te da más. Lo que DORA descubrió realmente es que los equipos con una base sólida pueden dirigir el efecto de amplificación hacia direcciones útiles.

Esto plantea la pregunta: ¿Cómo te sientes con tus fundamentos? ¿Cuál es la cultura de toma de decisiones en tu empresa? ¿Qué puedes hacer para mejorarla? ¿Y la estrategia técnica? ¿Alguien se preocupa por la productividad de los desarrolladores? ¿Cómo colaboran las personas en la organización hoy? ¿Cuál es el estado de seguridad? ¿Qué tal la salud del código, la higiene de lanzamiento y la confiabilidad? AI no resuelve automáticamente ningún problema. Si tus prácticas son buenas, las potencia. Pero si no son suficientemente buenas, solo genera más problemas.

Pero incluso con una base sólida, pronto emprenderemos un verdadero viaje. Supongo que para 2030, nuestro ecosistema de desarrolladores actual parecerá tan lejano como lo era el de 2001 para nosotros hoy. En 2001 aún publicábamos software en CD-ROM; para 2030, podríamos estar tan distantes.

Mientras continúas fortaleciendo tus fundamentos, déjame compartir contigo cuatro cosas que puedes considerar en el camino.

Primero, capacidad de infraestructura. Si no sabes cuántos recursos tienes disponibles, no puedes implementar IA ni recursos de cómputo; necesitas una buena manera de rastrearlos.

En segundo lugar, valida tu estrategia. No puedes ni debes publicar software que no haya sido validado. Pero las estrategias de validación cambian; es hora de aclararlo. Las pruebas de integración se convertirán en tu arma más importante, y es posible que aún no cuentes con las herramientas adecuadas.

Tercero, aislamiento. Recibirás muchos códigos destinados a diferentes propósitos, algunos de los cuales nunca antes se habían implementado con código. Esto está bien, pero no deseas que un prototipo divertido termine en producción. Mantén las cosas divertidas alejadas de las que generan ingresos.

Cuarto, abstracción. Construimos abstracciones para evitar que los desarrolladores tomen malas decisiones, por eso tenemos bibliotecas y marcos. Nadie escribe un servidor web desde cero. Permitir que los agentes tomen muchas decisiones conduce al mismo resultado, por lo que necesitas buenas abstracciones que los agentes sigan. No les des malas opciones.

También debes aceptar una cosa: las prácticas de ingeniería no son sagradas. Las prácticas cambian, pero los principios son lo importante. Decirlo es fácil, hacerlo es difícil; si nunca has reflexionado realmente sobre por qué tu equipo prueba el software de esa manera, o por qué el proceso de lanzamiento funciona así, no podrás evolucionarlo. Comprender los principios te dará la fuerza y la confianza para atravesar este momento de 10 veces.

Ahora es una época fascinante para los ingenieros de software. Cada dimensión de nuestro trabajo está siendo redefinida; necesitamos ser más creativos que nunca; necesitamos habilidades para abordar problemas como la gestión de contexto, la economía de tokens y el desplazamiento del modelo; necesitamos creatividad; no podemos quedar demasiado atrapados por la tentación de optimizarlo todo, y debemos fomentar la exploración.

Una pregunta que me ha mantenido despierto y que no se puede resolver solo con optimización: ¿cómo mantenemos el control intelectual sobre el código a medida que crece? El control intelectual se refiere a si los humanos pueden razonar sobre lo que tienen frente a ellos. Hace al menos quince años que hemos perdido esta batalla; nuestros sistemas más grandes ya superan con creces la capacidad de cualquier persona para comprenderlos. Si no me crees, haz un experimento: pide a cada miembro de tu equipo que dibuje un diagrama de arquitectura del sistema y observa cuántas versiones diferentes obtienes.

Muchos de nuestros sistemas de software son muy frágiles: una sola línea de código defectuosa o una bandera de configuración incorrecta puede derribar un sistema de millones de líneas, y esta fragilidad te obliga a pensar dos veces antes de realizar cualquier cambio. Pero sobre la IA tengo una idea muy entusiasmante: un espacio arquitectónico continuamente actualizado y casi interactivo al que pueda hacer preguntas. ¿Qué sucedería si moviéramos esta capacidad a la costa este? ¿Y si el crecimiento de usuarios aumentara repentinamente un 40%? Para cualquier sistema de tamaño mediano hoy en día, hacer esto es funcionalmente casi imposible, hay demasiadas variables. Pero la IA puede comprender conjuntos de datos extremadamente grandes, por lo que creo que aquí hay algo que vale la pena explorar.

Me gusta esta pregunta porque no solo nos enfocamos en hacer que las máquinas de código giren más rápido; nos preguntamos: ¿cómo podemos profundizar nuestra comprensión de lo que ya hemos construido?

Los cambios ocurren muy rápidamente, más rápido de lo que la mayoría de ustedes han experimentado. Una de las cosas más importantes que pueden hacer ahora es ayudar a quienes están luchando y ofrecer apoyo a quienes aún no lo entienden. Todos avanzamos a diferentes velocidades y enfrentamos este cambio de distintas maneras. Es fácil sentir que te quedas atrás.

Los ingenieros experimentados, sean mentores. Encuentren a quienes están atascados y ayúdenlos. Si ya entendieron el flujo de trabajo de desarrollo de IA, compártanlo con otros; no es ningún secreto valioso. Los líderes técnicos, deben participar activamente y ayudar a guiar la dirección del engineering de software en sus empresas. Si les importa la calidad del software o el diseño de software, deben usar su voz para defenderlo. Ustedes, los presentes, son los que deben hacer esto; probablemente sus jefes no lo harán.

Si imaginamos el ecosistema de desarrolladores como un ecosistema vivo, todos hemos estado acostumbrados a observar minuciosamente cada hoja en cada rama, cuidando cada árbol como si fuera una forma de vida especial. Pero no tardaremos en tener que gestionar no un solo árbol, sino todo el bosque. Y no puedes gestionar un bosque observando un solo árbol; debes ver el bosque como un ecosistema y gestionarlo así.

Los cambios sistémicos tienen una cualidad: ocurren simultáneamente en todas partes y en todo, de manera tan vasta que parece imposible aferrarse a algo. En este momento, es posible que sientas que nada te permite mantener el equilibrio frente a las olas de transformación que parecen llegar cada semana. Pero, como acabamos de descubrir, en un sistema todo está conectado, y pequeñas acciones pueden generar grandes consecuencias.

Aunque parezca lo contrario, la transformación de IA no es un ámbito exclusivo de los líderes empresariales. Como ingeniero de software en la primera línea, en este momento crítico, estás en el corazón de lo que decidirá el futuro de la ingeniería de software. Desde herramientas hasta flujos de trabajo, desde prácticas de ingeniería hasta cultura de ingeniería, si puedes comprender los sistemas que están en funcionamiento, encontrarás palancas. Tienes más autonomía de la que crees; úsala para crear el futuro de tu organización, tu equipo y tú mismo.