- Se dice que las herramientas de coding con IA aumentan la velocidad de desarrollo, pero el cuello de botella real no está en escribir código, sino en los procesos ineficientes de la organización
- Aumentar el volumen de código producido profundiza los atascos en etapas no relacionadas con el desarrollo —como la espera de reviews, retrasos en despliegues y requerimientos poco claros—, y el cycle time real incluso termina aumentando
- Según la Teoría de Restricciones (Theory of Constraints) de Eli Goldratt, optimizar una etapa que no es el cuello de botella no acelera el sistema: lo empeora
- Cuando ni siquiera quien “escribió” el código generado por IA lo entiende por completo, aparece un riesgo estructural: se amplía la superficie de respuesta ante incidentes y disminuye la cantidad de personas capaces de razonar sobre el sistema
- La ventaja competitiva no es para el equipo que escribe código más rápido, sino para el equipo que entiende qué debe construir y lo pone en manos de los usuarios
El inicio de una optimización equivocada
- Han aparecido anuncios de que, tras adoptar asistentes de coding con IA, la producción de código aumentó 40%
- Pero falta la pregunta de “¿velocidad hacia qué?”
- Si inviertes recursos en una etapa que ya es rápida (escribir código), el sistema completo se vuelve más lento
- Acelerar una parte que no es el cuello de botella hace que se acumule inventario de código sin terminar, y genera caída de calidad y confusión
Si optimizas donde no está el cuello de botella, el sistema empeora aún más
- La idea central de la Teoría de Restricciones (Theory of Constraints) presentada por Eli Goldratt en la novela The Goal de 1984: en todo sistema existe exactamente un cuello de botella, y el throughput total del sistema lo determina la capacidad de ese cuello de botella
- Si optimizas una etapa que no es el cuello de botella, el sistema no se acelera; solo se acumula inventario de trabajo sin terminar, lo que aumenta el lead time, genera confusión y reduce la calidad
- Como analogía: aunque la estación A produzca widgets más rápido, si la estación B —que es el cuello de botella— mantiene la misma velocidad, lo único que ocurre es que se acumula una pila de widgets sin procesar entre A y B
Lo que realmente provoca “triplicar la producción de código”
- Los developers generan PRs más rápido que nunca, pero como la cantidad de reviewers sigue siendo la misma, los PRs se quedan esperando en la cola de review uno, dos o siete días
- La persona autora ya cambió de contexto a la siguiente funcionalidad asistida por IA, así que cuando responde a comentarios sobre código escrito hace 8 días, casi no lo recuerda
- Como hay demasiados reviews, aparecen los reviews de sello de goma, donde se aprueba sin leer de verdad
- El CI tarda 45 minutos y, tras fallar por tests flaky, hay que relanzarlo; el pipeline de despliegue queda esperando la aprobación manual de alguien que está en reuniones, y la funcionalidad se queda 3 días abandonada en staging
- El developer ya abrió 2 PRs más, el WIP (Work In Progress) se dispara y todo el mundo lleva 6 cosas al mismo tiempo sin terminar ninguna
- Se produce más código, pero se libera menos software; el cycle time empeoró, pero el dashboard muestra una mejora de productividad del 40%
- Riesgo adicional del código generado por IA: la persona que supuestamente lo “escribió” no lo escribió realmente, sino que lo generó con un prompt y apenas lo revisó, así que ante un incidente en producción a las 2 a. m., ni quien está on-call ni quien escribió el prompt pueden explicar ese código
- Más código y menos entendimiento no es un aumento de productividad, sino una bomba de tiempo con un dashboard más bonito
Cuello de botella real 1: no saber qué hay que construir
- El PM no ha hablado con usuarios reales en dos meses, y los requerimientos llegan como tres líneas en un ticket de Jira y un link de Figma
- Los ingenieros toman por adivinación, sin especificación alguna, 50 microdecisiones al día sobre comportamiento, edge cases y manejo de errores
- Un equipo pasó 6 semanas desarrollando una funcionalidad basada en lo que un vendedor dijo por Slack que un prospecto quizá comentó en una llamada; ese prospecto no compró, y la funcionalidad solo la usaron 11 personas (9 de ellas del QA interno)
- Escribir código más rápido solo aumenta la velocidad a la que construyes lo equivocado; no es más que automatizar la adivinación
- El cuello de botella es entender el problema en sí, y eso no se resuelve tecleando más rápido
Cuello de botella real 2: todo lo que pasa después de que el código está “terminado”
- En la mayoría de las organizaciones, escribir código representa apenas alrededor del 20% del recorrido total; el otro 80% es tiempo en el que el código espera en distintas colas
- Hay casos de funcionalidades que tomaron una tarde en desarrollarse, pero 2 meses en llegar a producción
- Review de PR, CI, staging, QA, review de seguridad, aprobación de producto, ventana de despliegue, rollout canary: una larga cadena de handoffs, esperas y colas
- La mayor parte del tiempo el código no se mueve; está esperando a que alguien lo vea, a que corra el pipeline, a recibir permiso para existir
- Si quieres liberar más rápido, tienes que encontrar dónde espera el trabajo y medir la proporción entre tiempo real de trabajo y tiempo de espera en cola
Cuello de botella real 3: el círculo vicioso de la desconfianza en los despliegues
- Cuando los tests son flaky, la observabilidad es deficiente y nadie confía en el proceso canary, los equipos le temen a desplegar
- Ese miedo lleva a agrupar cambios en releases más grandes; eso aumenta el riesgo, hace que desplegar dé todavía más miedo y vuelve a impulsar releases más grandes: un círculo vicioso del miedo
- Si a eso le sumas una producción de código más rápida: hay más código, pero la cultura de despliegue sigue dominada por el miedo, así que los lotes crecen y la frecuencia de release cae
Cuello de botella real 4: falta de feedback después del lanzamiento
- Se crea y se lanza una funcionalidad, pero no hay analítica adecuada ni entrevistas con usuarios después del release, y nadie verifica si esa funcionalidad realmente resolvió el problema
- La siguiente funcionalidad también se basa en adivinación, y la siguiente igual; todo el roadmap del producto se convierte en una cadena de suposiciones sin feedback
- Una producción de código más rápida solo acelera el ciclo de “construir, lanzar y encogerse de hombros”
Cuello de botella real 5: el calendario es un muro de carga
- A veces el cuello de botella no es técnico, sino reuniones para tomar decisiones, acordar contratos de API entre 3 equipos que no hablan entre sí desde hace un mes, o el backlog acumulado de dos semanas de un arquitecto que es el único punto de aprobación para todos los diseños importantes
- Un proceso de planeación trimestral que tarda 6 semanas hace que hasta el trabajo urgente tenga que esperar 5 semanas para empezar
- También existen casos reales donde una funcionalidad no se lanzó porque “estamos esperando una reunión con alguien que está de vacaciones”
- Eso es un problema de coordinación, humano y político, y no tiene nada que ver con la velocidad al escribir código
Qué hacer en su lugar
- Value stream mapping: seguir una funcionalidad desde la idea hasta producción y registrar cuánto tarda cada etapa y cuánto tiempo espera entre etapas
- Medir el cycle time: en lugar de líneas de código, cantidad de PRs mergeados o story points, hay que medir cuánto tiempo pasa desde el commit hasta que el usuario puede usarlo en producción
- Eliminar estados de espera: si el review de PR tarda 2 días, resolverlo con pair programming, PRs pequeños, bloques de tiempo dedicados a review o normas de review asíncrono. Si el despliegue espera una aprobación manual, automatizarlo o al menos cambiarlo por un botón en Slack
- Dejar de empezar y enfocarse en terminar: por algo existen los límites de WIP; es mejor tener 3 cosas terminadas que 10 en curso. Todo elemento en progreso tiene costo de cambio de contexto
- Hablar con quienes hacen el trabajo: los developers ya saben dónde están los cuellos de botella; lo dicen en el standup y hacen memes en Slack desde hace meses. Solo pensaban que nadie los estaba escuchando
Conclusión clave
- En lugar de anunciar “la producción de código subió 40%”, un VP debería decir: “el análisis del value stream mostró que una funcionalidad espera en promedio 9 días entre etapas, y vamos a reducir eso a la mitad”
- La ventaja competitiva no es para el equipo que escribe código más rápido, sino para el equipo que entiende qué construir, lo construye y lo pone en manos de los usuarios
- El cuello de botella no es el teclado
4 comentarios
> Ese cliente potencial no compró, y esa función solo la usaron 11 personas (9 de ellas eran QA interno)
jajaja
La canalización sigue igual
pero parece que los desarrolladores simplemente se volvieron irresponsables
Me dan ganas de ser un artesano del software
Opiniones en Hacker News
Cuando mi equipo adoptó en serio el desarrollo basado en agentes, nos preocupaba que la velocidad de programación aumentara pero también creciera el tiempo de revisión
Por ahora no hay un cambio claro, y como todos siguen aprendiendo el nuevo flujo de trabajo, todavía no hay suficientes datos
Pero sí hay casos donde programar más rápido es especialmente útil: probar ideas, trabajo repetitivo complejo, implementaciones simples pero intensivas en mano de obra, o manejar casos límite después del happy path
En particular, los agentes funcionan muy bien cuando extienden una rama o un PR existente tal como está
La mayor mejora de productividad es que mientras el agente programa, yo puedo hacer otra cosa. Por ejemplo, reviso un PR y cuando regreso ya hay un resultado
Al principio era escéptico, pero ahora tengo expectativas cautelosas. Un aumento de 10x suena irreal, pero incluso una mejora de 2x sería enorme
Este enfoque solo sirve cuando el costo del error es bajo o el alcance del cambio es pequeño. Si no, bajan la calidad y la satisfacción, y lo único que se comprime es el calendario
Al final no recuperas tiempo en paralelo; apenas logras posponer un poco menos lo que ya venías aplazando
Pero hacer otra cosa mientras el agente programa produce una fatiga extraña
La IA es productiva, pero es un tipo de trabajo totalmente distinto a programar como artesano humano
Una refactorización que me habría costado abandonar si la hubiera hecho yo mismo, es más fácil evaluarla honestamente y decir “esto no estuvo tan bien” cuando la hizo la IA
Estar en multitarea todo el tiempo lleva rápido al burnout. Es una lástima que el factor humano quede fuera de la discusión
Yo no quiero trabajar siempre en un estado de ‘optimización máxima’
Alguien dijo que “entender el problema es el cuello de botella”, pero yo preguntaría por qué teclear rápido no podría ayudar a entenderlo mejor
¿No podría ser que construir algo equivocado rápidamente te ayude a encontrar antes la dirección correcta?
Yo muchas veces descubro lo que realmente quiero mientras construyo algo. Cuanto más barato es prototipar, más fuerte se vuelve esa tendencia
Claro, al final suele terminar en la conclusión de que “había que hablar más con el usuario”, pero ese ya es otro problema
En lugares como bancos, con suerte puedes experimentar una vez por semana
Pero la mayor parte del software no es así. Escribir código es solo una parte del trabajo total
Así como un cirujano no solo ‘corta’, un ingeniero tampoco se limita a escribir código
Si solo estás puliendo código a solas, eso no hace más que crear una confusión más grande
A veces es mucho mejor hablar una hora con el PM o con el cliente
La actual fiebre por los LLM da la impresión de que apareció primero la solución y después el problema
Si de verdad quieres aumentar la velocidad, primero hay que preguntar: “¿Cuál es el cuello de botella?”
Que la gerencia vea una presentación sobre IA y crea “esto nos hará más rápidos” no pasa de ser gestión por vibra (vibe management)
Programar es la parte más intensiva en trabajo y más automatizable de todo eso
Los LLM pueden aliviar bastante esa parte. Especialmente para escribir tests, la IA funciona bien
Los desarrolladores humanos todavía no logran soltar su obsesión con el código
En realidad, el código no es más que una representación intermedia (IR) de la solución
Así como GCC no se preocupa por las optimizaciones internas al convertir a ensamblador, si un agente genera el código, nosotros solo deberíamos mirar la corrección del resultado
Si hay una especificación clara y un proceso iterativo de revisión, tanto un humano como un agente pueden producir la misma implementación
Un LLM no. Puede malinterpretar cosas o alucinar (hallucination)
Por eso sigue haciendo falta revisión humana
Los agentes suelen elegir patrones equivocados o acumular deuda técnica
Tal vez algún día desaparezcan los lenguajes de programación como tal, pero todavía falta mucho
El significado se expande, se comprime o incluso desaparece
Muchas empresas en realidad no quieren buen código
La evaluación interna se hace con base en “cuánto se desplegó”, y si señalas problemas te responden que “eres demasiado detallista”
Al final, los interesados internos solo quieren el pretexto para decir que ‘fue un éxito’
Los técnicos tienen la responsabilidad de explicar ese riesgo
Desde la adopción de la IA ya se está viendo un deterioro de la calidad real
En mi empresa aprueban los PR a la ligera, el CI tarda 45 minutos, los despliegues se retrasan días
Además, está prohibido usar IA. Se supone que casi todo el código lo escriben humanos, aunque lo dudo
Lo que este texto pasa por alto son dos cosas: (A) que usar agentes y optimizar procesos son compatibles, y (B) que en algunos tickets el cuello de botella sí es realmente el código
Al final, lo importante no es si hay IA o no, sino mejorar el proceso para eliminar cuellos de botella
Soy desarrollador independiente. La velocidad de programación sí es un problema real. Me quita tiempo que podría usar en otras cosas
Hoy configuré Claude Code, y ahora gasto menos tiempo buscando en Google o escribiendo tests
No me va a volver 10x más productivo, pero como tecnología para ahorrar trabajo vale bastante la pena. Como un lavavajillas
Ahora la IA también escribe tests y me advierte sobre casos límite
No es perfecta, pero la velocidad para lanzar nuevas funciones aumentó y también tengo más tiempo
Decir “no se puede confiar en la IA” me suena como decir “no se puede confiar en el compilador”
Al final es un proceso donde el humano marca la dirección, mejora los prompts y crece junto con la herramienta
En startups o en entornos de VC, lo central no es programar sino resolver problemas de negocio
Aunque aumente la cantidad de código producido, no hay garantía de que mejore el resultado del sistema completo
Como con las plantillas o los generadores de código, la velocidad sube, pero si la recolección de requisitos no se acelera 10x, una productividad 10x es imposible
Como analogía, queda un poco fuera de lugar
¿Cómo evitamos que la IA cometa errores que las personas normalmente no cometen?
Los humanos revisan el código de forma lógica y paso a paso, pero la IA no
Incluso si, como en Amazon, un ingeniero senior revisa el cambio, una revisión no existe para atrapar todos los bugs
Además, cuanto más senior eres, más reuniones tienes y menos contexto de código manejas. ¿Qué tan efectiva puede ser esa revisión?
Pensar que el humano es perfecto es una ilusión
Le estamos exigiendo a la IA un estándar más alto que al humano
Al final, lo importante es fortalecer el proceso de QA. No debería dejarse el testing en manos de los desarrolladores
Esto me recuerda al libro The Goal, que leí hace años. Si automatizas una etapa de un proceso, la siguiente se vuelve el cuello de botella
En software pasa lo mismo: aunque la generación de código se acelere, no sirve de mucho si el proceso completo no acompaña
Al final, todo está subordinado al objetivo de generar ganancias. La calidad del código también es solo un concepto subordinado a ese objetivo
La velocidad al escribir código no es el cuello de botella cuando el riesgo es alto
A veces es mejor planear despacio y reflexionar bien sobre el resultado
Por ejemplo, si en una industria como la de la IA se construyen sistemas enormes demasiado rápido, eso puede crear un riesgo civilizatorio en la dirección equivocada
En cambio, si se trata de un jueguito pequeño hecho solo el fin de semana, da igual. Al final, es la magnitud del riesgo lo que determina la velocidad