Escribir Código Nunca Fue el Cuello de Botella

Hay una frase enterrada en un artículo de InfoQ de esta semana que debería hacer que todo PM deje de hacer scroll: "AI Coding Assistants Haven't Sped up Delivery Because Coding Was Never the Bottleneck."

Léela de nuevo. Hemos pasado los últimos dos años comprando suscripciones, incorporando herramientas y escribiendo prompts — todo para acelerar algo que en realidad no nos estaba frenando.

La Parte Que Todos Se Saltaron

La narrativa dominante de la industria sobre las herramientas de IA para programar ha sido simple: escribe código más rápido, lanza más rápido. Ciclos de feedback más cortos. Menos backlogs. Desarrolladores desbloqueados. Ha sido una historia lo suficientemente convincente como para que la adopción de herramientas se disparara en todos los frentes, desde los puestos de Copilot hasta configuraciones completas de programación agéntica.

Pero la velocidad de entrega — lo que realmente le importa a los PMs y a los stakeholders del negocio — no ha mejorado de manera significativa para la mayoría de los equipos. Y el análisis de InfoQ señala directamente el motivo: la restricción nunca estuvo en el IDE.

Los verdaderos cuellos de botella están donde siempre han estado. Ambigüedad en los requisitos. Alineación con los stakeholders. Criterios de aceptación poco claros. Los tres días de espera para una revisión de diseño. El ida y vuelta de dos semanas sobre un spec que debería haber tomado dos horas. La retrospectiva post-sprint donde todos admiten que no tenían claro qué significaba "terminado".

La IA puede escribir una función en segundos. No puede decirte qué función escribir.

Un Patrón Que Emerge en Múltiples Fuentes

Esta tensión está apareciendo en varios lugares al mismo tiempo, lo cual suele ser una señal que vale la pena seguir.

En dev.to, un post titulado "Agile or Winging It" pregunta si la mayoría de los equipos que practican "Agile" en realidad solo están improvisando con stand-ups. La brecha entre el ritual y la disciplina es enorme — y generar código más rápido no la cierra.

Mientras tanto, la comunidad de Lobste.rs está circulando un artículo llamado "Comprehension Debt — the hidden cost of AI generated code" de Addy Osmani, que le pone nombre a algo que los equipos están viviendo en silencio: código que funciona pero que nadie entiende del todo. Cuando un desarrollador genera código que no puede modelar mentalmente, ha cambiado una ganancia de velocidad a corto plazo por un pasivo de mantenimiento a largo plazo. La deuda de comprensión se acumula. Ralentiza al equipo de formas que no aparecen en las métricas de velocidad del sprint — hasta que de repente sí aparecen.

Y en el lado humano, está el post de dev.to que es, en silencio, una de las cosas más honestas publicadas esta semana: "52 Days, 711 Commits, Zero Users". El título es la historia. Alguien lanzó constantemente, construyó técnicamente y no produjo nada de valor. El cuello de botella nunca fueron los commits.

Qué Significa Esto para Cómo Defines el Alcance del Trabajo

Si el cuello de botella no es el código, los equipos de producto necesitan auditar honestamente dónde desaparece realmente el tiempo en un ciclo de entrega. No dónde asumen que va — sino dónde va realmente.

Algunos patrones que aparecen de forma consistente:

Arrastre de discovery a spec. La brecha entre "deberíamos construir esto" y "todos estamos de acuerdo en qué significa esto" generalmente se mide en semanas, no en días. La IA no reduce esto. Lo que sí lo reduce es una mejor facilitación, derechos de decisión más claros y ciclos de feedback más cortos con los clientes.

Fallos de alineación asíncrona. La mayoría de los retrasos en el sprint son causados por decisiones que no se tomaron, no por código que no se escribió. Cuando un diseñador y un PM tienen modelos mentales distintos de una funcionalidad, ninguna cantidad de autocompletado de Copilot arregla el retrabajo resultante.

Cuellos de botella en testing e integración. El análisis de InfoQ señala el trabajo de QA e integración como puntos de estrangulamiento persistentes. Los equipos que usaron IA para escribir más pruebas unitarias — en lugar de solo más código de funcionalidades — reportan una mejora real en la entrega.

Acumulación de capas de revisión. El post trending en Lobste.rs de apenwarr, "Every layer of review makes you 10x slower", ha estado circulando por una buena razón. Agregar IA a un proceso con demasiadas puertas de aprobación no acelera nada. Las puertas siguen ahí.

El Reencuadre Incómodo

La generación más rápida de código ha hecho, en algunos casos, que ciertos procesos lentos sean más visibles por contraste. Cuando un desarrollador puede producir el esqueleto de una funcionalidad en una tarde, de repente se vuelve dolorosamente obvio que después se queda en revisión durante cuatro días. La restricción no desaparece — se resalta.

Esto es información realmente útil si estás dispuesto a mirarlo con honestidad. La adopción de IA está llevando a cabo inadvertidamente un experimento natural sobre la salud real de los procesos de tu equipo. Los equipos que no están viendo mejoras en la entrega a pesar del uso intensivo de IA están aprendiendo algo importante sobre dónde está su fricción real.

Los equipos que sí están viendo mejoras tienden a compartir algunas características: ya habían invertido en specs claros antes de entregarle cualquier cosa a un desarrollador (humano o IA), tenían ciclos de feedback estrechos con los stakeholders, y tenían QA integrado en el flujo de trabajo en lugar de pegado al final.

En otras palabras, los fundamentos de proceso que hacían rápidos a esos equipos antes de las herramientas de IA también los hacen rápidos con ellas. Las herramientas amplificaron la calidad del proceso existente — no la sustituyeron.

Dónde Invertir Realmente

Si el análisis se sostiene, las inversiones de mayor apalancamiento para la mayoría de los equipos de producto ahora mismo no son más licencias de herramientas de IA. Están en:

• Calidad del spec. ¿Los specs escritos de tu equipo pueden entregarse a cualquiera — humano o IA — y producir el resultado correcto? Si no es así, ahí es donde está yendo el tiempo.
• Velocidad de decisión. ¿Cuánto tarda tu equipo en resolver una pregunta abierta sobre una funcionalidad? Reduce ese tiempo y verás mejorar la entrega más rápido que con cualquier cambio de herramienta.
• Cultura de comprensión. Antes de que el código generado por IA se lance, alguien en el equipo necesita entenderlo lo suficiente como para ser su dueño. El concepto de deuda de comprensión de Osmani vale la pena incorporarlo a tu definición de "terminado".
• Reducir capas de aprobación. Este es políticamente difícil, pero la evidencia se acumula. El teatro de revisión — revisiones que existen porque siempre han existido y no porque aporten valor — es un impuesto significativo sobre la entrega.

Lo más honesto que un PM puede decirle a su equipo de liderazgo ahora mismo: compramos herramientas que hicieron más rápida una parte del proceso, pero el proceso tiene más partes que esa. La buena noticia es que esas otras partes son abordables. Solo requieren un tipo diferente de inversión que otra suscripción SaaS.

El código nunca fue lo que te estaba frenando.