La trampa del plano

Recientemente escribí sobre la fatiga de la IA, argumentando que lo que los ingenieros están experimentando no es una condición crónica, sino dolor de entrenamiento. Superarlo, adaptarse, salir más fuerte.

Eso es todo bueno y sensato, pero hay más en esa historia, y se está volviendo más obvio. El verdadero riesgo que enfrentan los equipos de ingeniería en este momento no es el agotamiento. Es el plano.

La nueva división

Casi todos los ingenieros senior utilizan la IA ahora. Copilot, Claude, Cursor, Codex, usted nombre. Esa parte está resuelta. Si lidera una organización de ingeniería, probablemente vea números de adopción generalizados y se sienta bien al respecto.

No debería.

El número de adopción es insignificante. Lo que importa es la división que ocurre debajo de él. Su equipo se está dividiendo silenciosamente en dos grupos. Hay ingenieros que obtuvieron un impulso de productividad y se establecieron, y ingenieros que siguen empujando cada semana. Nuevos flujos de trabajo, nuevas configuraciones de agente, nuevas formas de descomponer problemas para que la IA los maneje.

Ambos grupos aparecen en sus paneles de control como “adoptadores de IA”. Pero uno está en un programa de entrenamiento progresivo. El otro se detuvo en el primer peso que se sentía cómodo.

Hace seis meses, la brecha entre estos dos grupos era apenas visible. Ahora es obvio para cualquiera que esté prestando atención. En otros seis meses, será estructural.

Qué aspecto tiene el plano en realidad

El ingeniero que ha alcanzado un plano no está haciendo nada malo en el sentido tradicional. Es competente. Entrega. Utiliza su agente para trabajos simples y limpia después de él. Obtuvo maybe un 20-30% de aumento de productividad y lo consideró hecho.

El problema es que el ingeniero de al lado no se detuvo allí. Ese ingeniero ahora está ejecutando flujos de trabajo de multiagente, mejorando bucles de verificación, descomponiendo características enteras en fragmentos ejecutables por la IA, revisando a nivel arquitectónico en lugar de línea por línea, y entregando al doble o triple de su ritmo anterior. No porque sea más talentoso. Porque siguió entrenando mientras todos los demás tomaban un descanso que se convirtió en un descanso trimestral.

Esto no se trata de entusiasmo por la IA o de ser un adoptador temprano. La fase de adopción temprana ha terminado. Esto se trata de adaptación continua versus ajuste único. Y la diferencia compuesta entre esos dos enfoques se está volviendo imposible de ignorar.

La presión competitiva es real y está acelerando

Si sus equipos tuvieran el lujo de adaptarse a su propio ritmo, el problema del plano sería un problema de gestión del rendimiento. Molesto, pero manejable.

Pero si mira la situación más amplia en la industria del software, es probable que no tenga ese lujo.

La industria del software, en general, se creó para ayudar a los humanos con el trabajo digital: ayudar a los agentes de soporte a ver los casos de entrada, realizar un seguimiento de las respuestas a los clientes, gestionar flujos de trabajo. Ahora los agentes de IA están reemplazando todo el flujo de trabajo, y con él, están perturbando las plataformas de SaaS subyacentes. Además, con la IA volviéndose más capaz cada día, sus clientes están comenzando a hacer una pregunta: “¿Todavía necesitamos comprar esto, o podemos construirlo nosotros mismos ahora?” La IA ha comenzado a reducir la barrera entre “comprar” y “construir” para un conjunto cada vez mayor de casos de uso. La pegajosidad que solía proteger sus ingresos se está debilitando cada trimestre.

Sus ingenieros que han alcanzado un plano están operando a un ritmo calibrado para un entorno competitivo que ya no existe.

La cita que reformuló todo para mí

Lo he escuchado más de una vez ahora, de gerentes de producto que se remangaron y codificaron características, de líderes de ingeniería que rediseñaron arquitecturas fallidas, en diferentes empresas, en diferentes contextos:

“Fue más fácil para mí iterar sobre esto con mis agentes que con ese ingeniero.”

La primera vez que lo escuché, pensé que era una exageración. La tercera vez, me di cuenta de que era un indicador líder.

Así es como lo veo, hay ingenieros que prosperarán en este nuevo mundo y serán “multiplicadores” de las capacidades de la IA. Para hacer eso, necesitan ser fuertes en dos áreas, ambas de las cuales se pueden desarrollar con suficiente motivación intrínseca y curiosidad intelectual:

• Operan “en la misma onda” que sus partes interesadas (gerentes de producto, gerentes de ingeniería, etc.). Entienden lo que es bueno, así que no tienen que explicarles cosas a ellos. Porque si producen la misma cantidad de malentendidos que su agente de codificación, el agente siempre ganará esa batalla. Está disponible instantáneamente, las 24 horas del día, los 7 días de la semana, y es incansable.
• Mejoran constantemente sus configuraciones de IA, así que cuando les entregas algo, sabes que se hará no solo bien (ver el punto anterior), sino también lo suficientemente rápido como para mantener el ritmo del nuevo ritmo del mercado.

Por qué esto es un problema de liderazgo, no individual

Es tentador enmarcar esto como la responsabilidad de un ingeniero individual. “Mantente al día o quédate atrás.” Pero si lidera una organización de ingeniería, ese enfoque lo libera de la responsabilidad.

Sus ingenieros que han alcanzado un plano no lo hicieron en el vacío. Lo hicieron porque nada en su entorno los empujó más allá del ajuste inicial. Llegaron a un aumento de productividad razonablemente bueno y nadie los desafió a ir más lejos, y la inercia hizo el resto.

Los ingenieros que siguieron empujando! La mayoría de ellos están auto motivados. Lo harían de todos modos. Pero no puede personalizar una organización de ingeniería enteramente con buscadores de fronteras auto motivados. La pregunta para los líderes es: ¿cómo mueves al medio?

Esto es un problema de gestión del cambio, y uno de mis marcos favoritos para ello proviene del libro Switch de los hermanos Heath. La versión corta: necesitas darle a la gente una dirección clara, hacer que sientan por qué importa, y reformar el entorno para que el nuevo comportamiento sea el camino de menor resistencia. Aplicado a equipos de ingeniería, eso se ve así:

Encuentra tus puntos brillantes y hazlos visibles. Identifica a los ingenieros que han empujado más lejos en sus flujos de trabajo de IA y haz que demuestren al equipo regularmente. No sesiones de capacitación. Demostraciones en vivo de trabajo real. Cuando el medio de su equipo ve la diferencia entre su flujo de trabajo y el flujo de trabajo del adaptador superior, crea una incomodidad productiva que ninguna directiva puede igualar.

• Reduce el cambio. “Adoptar IA” es demasiado abstracto para actuar. Esta sprint, clava la prueba de agente de extremo a extremo, la próxima sprint lo despliega en toda la organización, y así sucesivamente. Pasos específicos y manejables superan programas de transformación ambiciosos cada vez, y las pequeñas victorias importan.
• Reforma los valores predeterminados. Codifica el proceso de verificación en habilidades de IA, y asegúrate de que se desplieguen en todo su equipo y en todos sus agentes. Define sus flujos de trabajo y utilice la herramienta que lo admite. Haz que la nueva forma de trabajar sea el camino de menor resistencia, para que la gente se dirija hacia allí en lugar de tener que luchar para llegar allí.

La ventana se está cerrando

Aquí está la parte que hace que esto sea urgente en lugar de simplemente importante.

En este momento, la brecha de adaptación es una diferencia de rendimiento. Sus ingenieros que han alcanzado un plano son más lentos que los adaptados, pero todavía son productivos. Todavía contribuyen. Puedes llevarlos.

Esa ventana se está cerrando. A medida que las capacidades de la IA aceleran y la presión competitiva se compone, el ritmo mínimo viable de trabajo de ingeniería está aumentando. El ingeniero “lo suficientemente bueno” de hoy no está garantizado para ser lo suficientemente bueno el próximo trimestre. No porque empeoraron, sino porque el piso subió.

Las organizaciones que figuren cómo mover a todos sus equipos hacia arriba en la curva de adaptación, no solo a los adoptadores tempranos, tendrán una ventaja estructural compuesta. Las que no lo hagan se encontrarán con personal para un ritmo de competencia que ya no existe.

Cada líder de ingeniería con quien hablo entiende esto intelectualmente. Muy pocos han cambiado la forma en que dirigen sus equipos en respuesta. La brecha entre la comprensión y la acción es su propia clase de plano.

No hay un ritmo cómodo

En el artículo sobre la fatiga de la IA, argumenté que el dolor es la prueba de que el entrenamiento está funcionando. Eso sigue siendo cierto. Pero la verdad subsiguiente es más dura: el peso sigue subiendo.

En un gimnasio normal, puedes elegir un peso cómodo y mantenerlo para siempre. Nadie agrega placas a tu barra sin preguntar. En el panorama actual del software, cada nuevo lanzamiento de modelo, cada nueva capacidad de agente, cada nuevo flujo de trabajo que alguien figura y comparte, la barra se mueve. Mantente quieto y el peso eventualmente te pinará.

No hay un espacio cómodo en la industria del software en este momento. No para los ingenieros individuales, no para los equipos en los que trabajan, no para las empresas que esos equipos construyen. La única posición segura es el movimiento continuo. Y la única pregunta que importa para los líderes de ingeniería es si todo su equipo se está moviendo, o solo los que se habrían movido de todos modos.