La variación que conocés vs. la variación que no conocés

Adoptar asistentes de programación con IA no elimina la variación en la entrega de software. En la mayoría de los casos que observo, lo que hace es intercambiar una fuente de variación conocida por una desconocida. Esa distinción importa más de lo que actualmente se le está dando a entender.

El argumento a favor de la adopción no es irracional. El desarrollo de software humano siempre tuvo variación. Dos programadores a quienes se les asigna la misma tarea la van a enfocar de manera distinta, van a tardar tiempos diferentes y van a producir soluciones diferentes. Eso no es un defecto — es la naturaleza del trabajo del conocimiento, algo que exploré en detalle en el artículo anterior de esta serie. El punto acá es que esa variación humana, con toda su frustración, es al menos una cantidad conocida. Décadas de investigación en ingeniería de software, psicología organizacional y pensamiento sistémico nos dieron herramientas para observarla, caracterizarla y trabajar con ella. Sabemos más o menos qué puede entregar un equipo. Sabemos cómo tiende a comportarse la variación bajo presión. Hemos construido enfoques de planificación y estimación — imperfectos, pero fundamentados — en base a ese entendimiento.

Los asistentes de programación con IA — herramientas como GitHub Copilot, Claude o Cursor — introducen un tipo de variación diferente. No menor. No necesariamente mayor. Diferente en su naturaleza y, fundamentalmente, todavía sin caracterizar.

Pensemos en los efectos a largo plazo: ¿conocemos algún sistema creado con asistentes de IA que haya sido mantenido por más de cinco años? El comportamiento a largo plazo de las bases de código generadas con IA — cómo envejecen, cómo acumulan complejidad, cómo responden al tipo de cambio incremental que constituye la mayor parte del mantenimiento real de software — sigue siendo genuinamente desconocido. Estamos, como industria, llevando adelante un experimento cuyos resultados no van a ser legibles por años.

Esto importa para cómo pensamos la variación a nivel de equipo. Un equipo de desarrollo que trabaja a un ritmo conocido — con fluctuaciones comprendidas alrededor de ese ritmo — representa un sistema cuyo comportamiento puede modelarse, aunque sea de forma aproximada. Cuando introducís asistentes de programación con IA sin antes caracterizar cómo se desempeñan en tu contexto, en tu base de código, bajo tus restricciones, no estás reduciendo la variación. Estás intercambiando una fuente de variación conocida por una desconocida. La distribución de resultados no se achicó — simplemente se volvió opaca.

Hay un punto relacionado que vale la pena mencionar sobre la naturaleza de la asistencia en sí. El mismo prompt, enviado a un asistente de programación de IA de frontera, no va a producir de forma confiable el mismo resultado. Los modelos no son determinísticos de la manera en que lo es un compilador. Esa es una propiedad de ingeniería que vale la pena entender antes de integrar la herramienta en un pipeline de entrega del que sos responsable.

La pregunta que vale la pena hacerse no es si adoptar asistentes de programación con IA — la mayoría de los equipos ya lo hizo, o lo va a hacer. No estoy argumentando en favor de una adopción más lenta. Estoy argumentando a favor de una adopción informada: entender qué hace realmente la herramienta en tu entorno específico, en tu base de código, bajo tus restricciones, antes de que se tomen las decisiones de escala. Lo que encuentro igualmente digno de examinar es la imagen espejo de la trampa de la certeza con la que comenzó esta serie. Sabemos que los humanos prefieren la certeza de un mal resultado conocido antes que la incertidumbre del cambio. Pero hay un riesgo igual y opuesto — esos momentos en que la incertidumbre se presenta como certeza, y la adoptamos a escala antes de habernos ganado el derecho a esa confianza.