Productividad 10x: Lo que la promesa deja sin contabilizar

Los desarrolladores con los que hablo parecen estar cada vez más orgullosos de decir que agotaron al máximo el uso de su asistente de programación con IA. Surge casi como un alarde — gasté toda mi asignación el miércoles — una manera de señalar un compromiso genuino con la herramienta, evidencia de que la inversión finalmente está rindiendo sus frutos.

Me parece una reacción interesante, porque el evento subyacente es, financiera y operacionalmente, más ambiguo de lo que el orgullo alrededor sugiere — y las implicancias van considerablemente más profundo que el output de cualquier desarrollador individual.

Una nueva clase de variación, disfrazada de finanzas

Durante años, el costo del tooling para desarrolladores era casi insignificante. Los IDEs eran gratuitos o casi gratuitos. La economía del desarrollo de software descansaba sobre una única línea de costo grande y predecible: el salario. Como comenté en un post anterior sobre la Era de las Herramientas, este es el tercer cambio que vivió nuestra industria — de los procesos, a las personas, a las herramientas — y la era de las herramientas ya cambió cómo presupuestamos una vez, con el paso de IDEs gratuitos a licencias pagas por puesto. Ese fue un ajuste manejable. Un número fijo, conocido.

Lo que está pasando ahora es un segundo cambio, más abrupto, que llega pisándole los talones al primero. Las licencias por puesto están cediendo paso al consumo basado en uso, medido en tokens. Y las ganancias genuinas de productividad que algunos equipos reportan — el tan discutido equipo 10x, la tierra prometida de la entrega acelerada por IA — crean una tentación que creo merece más escrutinio del que recibe actualmente: las organizaciones empiezan a planificar, comprometerse y re-baselinar como si esa capacidad elevada fuera una característica estable y permanente del sistema.

En resumen, esta capacidad 10x no es estable, y no aguanta el escrutinio. Una de las razones se conecta directamente con el argumento de teoría de colas que planteé antes en esta serie.

Pensemos en lo que realmente pasa cuando se consumen las asignaciones de uso. No es un único desarrollador, en un cronograma predecible, quien vuelve al baseline. Los agotamientos ocurren estocásticamente, a lo largo de todo el equipo, en distintos momentos del sprint, con ventanas de reseteo que son en sí mismas impredecibles — un reloj de tokens puede resetearse en cinco horas, o considerablemente más, dependiendo de cómo el proveedor contabiliza el uso. En cualquier momento dado, no sabés cuántos de tus desarrolladores están operando a la capacidad elevada asumida y cuántos volvieron silenciosamente al trabajo sin asistencia.

Esto significa que el estado de alta capacidad al que una organización puede haberse adaptado — compromisos de sprint ajustados, cadencia de planificación acelerada, flujo de requerimientos upstream sintonizado para seguir el ritmo de una entrega más rápida — no es un estado estable en absoluto. Es uno fluctuante, y la fluctuación está, en la mayoría de las organizaciones que encuentro, completamente sin modelar. El riesgo no es que el throughput de un desarrollador baje. Es que la capacidad efectiva del equipo se mueva de forma impredecible entre algo cercano a la promesa 10x y algo más cercano al baseline, múltiples veces dentro de un único sprint, sin visibilidad sobre en qué estado se encuentra realmente el sistema en ningún momento dado.

Cada proceso upstream que re-baselinó alrededor del número más alto hereda ahora esa varianza. Ciclos de planificación construidos para un throughput acelerado. Pipelines de requerimientos sintonizados para seguir el ritmo de un equipo más rápido. Cadencias de revisión con stakeholders ajustadas para hacer match. Ninguno de estos procesos fue diseñado para absorber a un equipo cuya capacidad efectiva oscila estocásticamente — fueron diseñados, en el mejor de los casos, para un tipo diferente y más indulgente de variación: la irregularidad acotada y bien estudiada de desarrolladores humanos trabajando a una tasa más o menos conocida, el tema del artículo de apertura de esta serie.

Por qué el riesgo sigue siendo invisible

Hay un paralelo útil, aunque incómodo, con el trabajo de Daniel Kahneman y Amos Tversky ¹: las personas tienden a pesar las ganancias visibles e inmediatas mucho más que los riesgos menos visibles asociados a ellas. Encuentro algo similar ocurriendo con el consumo de tokens a nivel de equipo: la ganancia — un sprint genuinamente más rápido, una sensación de momentum organizacional — es saliente y se celebra. El riesgo correspondiente — un sistema entero re-baselineado alrededor de una cifra de capacidad que en realidad no puede sostenerse de forma continua, porque el mecanismo que la produce es en sí mismo intermitente e impredecible — permanece en gran medida invisible, porque nadie está rastreando la capacidad y el presupuesto como un único sistema conectado.

Nada de esto es un argumento en contra de las herramientas basadas en uso, ni en contra de las ganancias genuinas de productividad que algunos equipos están experimentando. Es un argumento de que la ingeniería de software no ha sido, de hecho, resuelta por el desarrollo asistido por IA — y que el trabajo de mejora sigue siendo tan relevante en esta era como en cualquier otra. El cuello de botella nunca estuvo en la programación; el desarrollo asistido por IA no elimina esa verdad, simplemente produce una nueva generación de cuellos de botella, esta vez en la interacción impredecible entre presupuesto, capacidad y entrega. Identificar y resolver cuellos de botella de cualquier tipo siempre requirió prácticas de mejora con trayectoria probada, no código más rápido. Ese trabajo no se vuelve innecesario porque las herramientas cambiaron. Si acaso, se vuelve más necesario, porque el sistema que produce el cuello de botella ahora es más difícil de ver.

(1) Kahneman, D. (2011). Thinking, Fast and Slow.

Si estás listo para ir más lejos, exploremos juntos cómo conectar tus modelos financieros y de entrega puede funcionar para tu equipo. Contactate hoy, y hagamos visible el riesgo invisible antes de que aparezca en un sprint fallido.