El cuello de botella nunca estuvo en la programación

Otra vez! –> “El cuello de botella nunca estuvo en la programación. “

Esta afirmación era verdad en la era de los procesos, verdad en la era de las personas, y sigue siendo verdad en la conversación actual sobre los asistentes de desarrollo con IA — la era de las herramientas.

La promesa detrás de la adopción de la mayoría de los asistentes de programación con IA es sencilla: los desarrolladores van a escribir código más rápido, por lo tanto los equipos van a entregar más rápido, por lo tanto las organizaciones van a obtener más valor de su inversión en ingeniería. Esa cadena de lógica no es irrazonable. Pero descansa sobre un supuesto que no resiste demasiado escrutinio — que la velocidad de desarrollo es donde realmente vive la restricción.

En la mayoría de los equipos de software con los que trabajo, no es así. Los requerimientos necesitan clarificarse. Los stakeholders necesitan alinearse. Las decisiones arquitectónicas necesitan tomarse. El código necesita revisarse, testearse e implementarse. Cada una de esas etapas tiene su propia cola de trabajo, su propia variación, sus propias restricciones de capacidad.

Es justo reconocer que los agentes de IA son cada vez más capaces en más de esas etapas — no solo en programación, sino también en revisión de código, generación de tests y elementos de automatización del pipeline de deployment. Eso es un desarrollo significativo. Pero incluso concediendo eso, las etapas que siguen siendo más resistentes a la automatización son precisamente aquellas donde la restricción suele vivir con más frecuencia: la claridad de lo que se está construyendo, la alineación de las personas que necesitan ponerse de acuerdo, y los procesos organizacionales que gobiernan cómo se toman las decisiones. Acelerar las etapas técnicas en un sistema cuya restricción es organizacional no acelera el sistema. Cambia dónde se acumula la cola.

Esto no es una idea nueva. Es, en esencia, lo que Goldratt argumentó en la Teoría de las Restricciones: optimizar un no-cuello de botella produce eficiencia local y ruido a nivel del sistema. Lo que es nuevo es la escala a la que la industria está aplicando esta optimización en particular sin antes preguntarse dónde está la restricción real.

Una mirada desde la Teoría de las Colas

La teoría de colas me resulta una lente útil acá. La notación es más simple de lo que parece.

Un sistema de colas M/M/1 clásico describe:

• M — llegadas Markovianas (aleatorias): el trabajo llega a una tasa caracterizada, aunque impredecible
• M — tiempos de servicio Markovianos: el trabajo se procesa a una tasa caracterizada, aunque variable
• 1 — un único servidor: un recurso atendiendo la cola

En palabras simples: un sistema donde sabés más o menos qué tan rápido llega el trabajo, más o menos qué tan rápido se procesa, y por lo tanto podés modelar cómo se comporta la cola a lo largo del tiempo. Un equipo de desarrollo humano, con toda su variación, se aproxima a esto. Puede que no sepas exactamente cuándo se va a completar la próxima historia de usuario, pero tenés suficiente datos históricos para caracterizar la distribución. Podés modelar el throughput, predecir el crecimiento de la cola e identificar dónde se está acumulando la presión.

Ahora introducí asistentes de programación con IA — o reemplazá a los desarrolladores por agentes de desarrollo por completo — y pensá qué cambia. Ya no tenés una distribución de servicio caracterizada. Tenés marketing de adopción, resultados de benchmarks en condiciones controladas, y tus propios supuestos no testeados sobre cómo va a rendir la herramienta en tu base de código, con tus requerimientos, bajo tus restricciones. El sistema pasó de ser algo que podías modelar a algo que no podés. En términos de teoría de colas, saliste completamente del territorio M/M/1.

Ese cambio produce riesgos específicos que vale la pena nombrar. Si el throughput real del agente es menor que tu tasa de llegada de trabajo, la cola no solo va a crecer — va a crecer sin límite, y puede que no te des cuenta de que el sistema es inestable hasta que el backlog ya sea inmanejable. Un ingeniero humano con variación de rendimiento conocida tiene un escenario de peor caso acotado. Un agente de IA puede exhibir comportamiento de cola larga — rápido en tareas rutinarias, pero propenso a quedarse trabado en casos borde de maneras que no tienen un techo natural. Y si el rendimiento del agente se degrada a medida que aumenta la presión de la cola, el sistema se vuelve no estacionario: los supuestos estándar de modelado se rompen por completo.

Nada de esto argumenta en contra de usar asistentes de programación con IA. Argumenta a favor de entender tu sistema antes de reestructurarlo alrededor de una herramienta que todavía no caracterizaste. El cuello de botella nunca estuvo en el desarrollo. Y acelerar la programación, sin saber dónde está realmente el cuello de botella, te dice muy poco sobre si la entrega va a mejorar.

Si estás listo para ir un paso más allá, veamos cómo detectar y solucionar el verdadero cuello de botella de tu equipo puede funcionarle a tu organización. Contactanos hoy y asegurémonos de que los cambios en los que estás invirtiendo estén apuntando a la restricción correcta