Cuando el código es casi gratis, el cuello de botella se va a requisitos, integración, verificación y alineación

Cuando producir código es casi gratis, el cuello de botella de la entrega de software se desplaza a otro sitio: definir el problema correcto, ensamblar los fragmentos en un conjunto que funcione, verificar que efectivamente es correcto y alinear a la organización. Es la Teoría de Restricciones (Theory of Constraints) reeditada en el software. La manufactura recorrió este camino hace 40 años: cada vez que una operación se abarata, el cuello de botella no desaparece, solo se traslada a la siguiente operación más cara. Entender esto explica una perplejidad común: se ha desplegado IA para programar en toda la empresa, el código se escribe claramente más rápido, y la velocidad de entrega apenas se ha movido.

Un CIO de un grupo industrial me enseñó los datos del último semestre. Su equipo de TI, más de 80 personas, había adoptado herramientas de programación con IA en toda la línea. Mirando solo la producción de código, los commits por persona y la velocidad de merge habían subido más de un 30 %. Pero la percepción del negocio era otra: una funcionalidad pequeña de planificación inteligente de producción seguía tardando, desde la aprobación hasta producción, tres meses o más. Él contaba con que las herramientas le darían un multiplicador de dos. Lo que compró fue “código escrito más rápido”. Su frase fue directa: “Me gasté cientos de miles en licencias y lo que conseguí fue desarrollo más ocupado y negocio con más prisa”.

Supuso mal dónde estaba el cuello de botella. El suyo era otro: cada funcionalidad nueva tiene que cruzar MES, ERP, el sistema de calidad, los terminales de planta y además un flujo de reporte regulatorio. La integración y las pruebas conjuntas se comían la mayor parte del calendario; y el código que generaba la IA no tenía ninguna puerta formal de aceptación que se interpusiera entre él y el entorno de producción. Por mucho que el código se escribiera rápido, solo se acumulaba en cola detrás del cuello de botella equivocado.

1. La manufactura lo sabía hace 40 años: el cuello de botella se mueve

Para entender el momento actual, conviene ponerse las gafas que la manufactura lleva usando 40 años.

En 1984, el consultor israelí de formación física Eliyahu Goldratt publicó una novela, The Goal (La Meta), sobre un director de planta al borde de la quiebra que rescata su fábrica. El núcleo del libro cabe en una frase: la salida de cualquier sistema la determina su eslabón más estrecho (la restricción, es decir, el cuello de botella). Ensanchar los eslabones que no son cuello de botella no aporta nada a la salida total; solo ensanchando el cuello de botella mismo se acelera el conjunto. Y en cuanto lo ensanchas, el cuello de botella se traslada de inmediato al siguiente punto más estrecho. Esa es la Teoría de Restricciones (Theory of Constraints, TOC).

Los 40 años de automatización que siguieron en la manufactura son, casi, una “historia del cuello de botella mudándose”. Cuando el control numérico abarató el mecanizado, el cuello de botella se fue al cambio de utillaje y a la inspección. Cuando las líneas flexibles aceleraron el cambio de utillaje, se fue a la planificación y a la coordinación con la cadena de suministro. Cuando el MES hizo más precisa la planificación, se fue a la previsión de demanda y a la coordinación entre plantas. Cada vez que se automatiza un tramo, el siguiente aflora. La automatización nunca elimina el cuello de botella: solo le cambia de sitio.

Esto está más cerca del software de lo que parece. En 2013, Gene Kim trasladó casi intacta la historia de fábrica de Goldratt a las operaciones de TI y escribió The Phoenix Project (El Proyecto Phoenix): cómo un CIO usa la Teoría de Restricciones para rescatar un departamento de TI que está arrastrando a toda la empresa. Así que “mirar el software con la lente del cuello de botella de la manufactura” es un camino ya validado, no una metáfora improvisada.

2. De vuelta al software: escribir código se está convirtiendo en el eslabón más barato

Tres cifras lo dejan claro: el coste de producir código tiende a cero.

Copilot. La investigación propia de GitHub midió que, en los ficheros con Copilot activado, alrededor del 46 % del código lo escribe Copilot. Ojo con la lectura: es la proporción “dentro de los ficheros habilitados”, no el 46 % de todo el código de GitHub.
Stripe. Su agente de codificación interno, “Minions”, produce y mergea cada semana más de 1.300 PR (empezaron en 1.000 y sigue subiendo). Hay un detalle que conviene retener: cada PR pasa por revisión humana antes de mergearse. Stripe automatizó “escribir” y dejó “aceptar” en manos de personas. En la sección 4 se usa esto.
NVIDIA. Jensen Huang ha dicho públicamente que el 100 % de los ingenieros de NVIDIA usan herramientas de programación con IA tipo Cursor; en NVIDIA “trabajar sin IA” ya no se acepta.

Superponiendo las tres, la conclusión es contundente: el coste unitario de producir una línea de código se acerca a cero a buen ritmo.

De ahí sale una pregunta incómoda: si escribir código ya casi no cuesta, ¿por qué el software sigue siendo tan caro, tan lento y tan difícil de entregar? La respuesta es la que da la Teoría de Restricciones: ensanchaste la operación “escribir código” y el cuello de botella simplemente se mudó. ¿A dónde?

3. El cuello de botella se va a cuatro sitios

Esta vez el cuello de botella se concentra en cuatro operaciones. Ninguna está al alcance de la IA a corto plazo.

Primera: definir el problema correcto. La IA puede escribir en segundos “la funcionalidad que dijiste en voz alta”, pero no “la funcionalidad que de verdad necesitas”. La mayoría de los proyectos de software fracasan por la raíz: lo que sale no lo usa nadie, porque al principio no se pensó a fondo qué problema se estaba resolviendo. Con la producción de código abaratada, “tomar una molestia difusa del negocio y descomponerla en una especificación clara, resoluble y que merezca ser resuelta” (problem formulation) se ha vuelto la capacidad más escasa y más cara. Los colegas de manufactura no lo tienen nuevo: si la ruta de proceso y el plano de ingeniería están mal, por eficiente que sea el taller, se está fabricando chatarra en serie.

Segunda: integración de sistemas. La IA es buena generando “un trozo de código”, “una función”, “una página”. Pero un sistema que puede salir a producción es la integración de cientos de fragmentos: tienen que intercambiar datos, manejar bordes, mantener consistencia y aguantar excepciones. Generar fragmentos es barato; ensamblarlos en un conjunto fiable es caro. El coste de raíz está en el alineamiento organizativo y de arquitectura, justo lo que ocupan la ley de Conway y Team Topologies (los dos artículos anteriores de la serie). Volviendo al CIO del principio: su calendario no se le fue en escribir código, se le fue en la integración conjunta de MES, ERP, calidad y reporte.

Tercera: verificación. El volumen de código explota y su fiabilidad es desigual. ¿Quién firma que “es correcto”? Pruebas, code review, observabilidad y despliegues progresivos: el peso de esta “verificación” no baja, sube. Es el cuello de botella más infravalorado y también el que más se refleja en el espejo de la manufactura. La sección 4 lo trata en solitario.

Cuarta: alineación organizativa. Cuando el equipo incorpora agentes de IA, ¿quién decide qué hacer, quién revisa y quién responde por el resultado? Otra vez la extensión de Conway y Team Topologies: la alineación misma se convierte en cuello de botella. El artículo 11 de la serie lo trata: cuando los nodos de la organización no son todos humanos, cómo se convierte la gobernanza en ventaja competitiva.

4. El corte más hondo: verificación, y qué enseña de verdad el “jidoka” de Toyota

De los cuatro cuellos de botella, el que más se malinterpreta es verificación. Mucha gente lo lee como “si la IA escribe rápido, pues haremos más rondas de pruebas”. Eso solo acierta por la mitad. Para ver por qué la verificación se encarece, primero hay que poner derecho el concepto de manufactura más citado y peor explicado: el jidoka (自働化).

Primero, corregir una lectura muy extendida. El jidoka no es “sustituir a las personas con IA o máquinas”, ni “convertir a la persona en máquina, para que trabaje como una máquina sin parar”. Las dos direcciones son equivocadas.

La propia palabra lo dice. En japonés, “自動化” es la automatización corriente. Toyota escribe “自働化”, con el kanji “働” que lleva el radical de persona, para subrayar “automatización con toque humano” (automation with a human touch). Su significado preciso: cuando la máquina o la línea detecta una anomalía, se para automáticamente, deja que la persona intervenga, resuelva la causa raíz y luego reanuda la producción. Tiene dos mecanismos en paralelo: la máquina lleva su propio detector de anomalías y se para sola; y cualquier persona de la línea que ve algo raro tira de la cuerda andon y toda la línea se detiene al instante. La calidad no se inspecciona al final, sino que se incrusta en cada operación y se resuelve en el sitio.

Aquí hay una conclusión contraintuitiva, y es la que conecta directamente con el software: cuanto más profunda es la automatización, más crece — no mengua — el peso de las puertas de calidad y de la intervención humana. El jidoka saca a la persona del “operar repitiendo” y la recoloca en “detectar la anomalía, parar la línea y resolver la causa raíz”. Toyota da a un operario de primera línea el poder de parar toda la línea precisamente porque sabe que, por fuerte que sea la automatización, alguien tiene que poder gritar “alto” cuando algo falla. Esa es la frase “dar inteligencia a las máquinas”: que la máquina sea capaz de parar y llamar al humano. La persona sigue presente, encargada de la causa raíz.

El software está recorriendo este camino, y deprisa. El estudio de GitClear sobre la calidad del código asistido por IA ya observa señales de bloques duplicados en aumento y de código con alta rotación a corto plazo (churn): la IA escribe rápido, pero también escribe “cosas que parecen correctas”. Cuando una parte importante del código nadie la escribió línea a línea, el mecanismo de confianza tradicional — “el desarrollador sabe lo que hay aquí” — se rompe. Lo que hace falta entonces es la versión software de la cuerda andon y del mecanismo de parada:

Las pruebas (unitarias, de integración, extremo a extremo) suben de “en lo posible” a umbral duro: si no pasan, no se mergea.
El code review desplaza el foco de “revisar cómo está escrito” a “revisar la intención y los bordes”: qué quiere resolver este código y si cubre los casos límite.
La observabilidad (monitorización, logs, trazas) se vuelve estándar: el comportamiento en producción dice más que el propio código.
El despliegue progresivo / feature flag deja que lo generado por IA se valide primero en un alcance pequeño y, sin problemas, se abra.

Volvamos a los 1.300 PR de Stripe en la sección 2: los escribe el agente, pero la puerta de merge se la deja entera a la revisión humana. Ese es el jidoka viviente en el software: automatizar la producción y dejar la aceptación en manos de personas, con el poder de “frenarlo”. La producción se abarató y el control de calidad se encareció: una regla de 40 años que no ha cambiado.

5. La prima de “definir el problema”: una capacidad que vale más que el prompt

Si la verificación es el cuello de botella infravalorado, “definir el problema” es la capacidad gravemente infravalorada.

El prompt engineering tuvo su momento y bastante gente cree que “saber escribir prompts” es la capacidad central. Pero el prompt es la técnica de “expresar el problema”. Lo realmente escaso está un paso antes: problem formulation, tomar una molestia difusa del negocio y descomponerla en un problema claro, resoluble y que merezca ser resuelto. Eso, a corto plazo, la IA no lo hace — porque tiene que esperar a que tú le digas “cuál es el problema”.

Los veteranos de manufactura son los que mejor calibran este paso. Un plano de ingeniería o una ruta de proceso equivocados hacen que, por eficiente que sea el downstream, se fabrique el error en serie. El software es igual: con la especificación de requisitos equivocada, la IA te fabrica a diez veces la velocidad un montón de cosas que nadie quiere.

El juicio es directo: deja de competir en “velocidad de escribir código” y entrena la “claridad para descomponer problemas”. En la organización, eso significa poner “definición de requisitos” y “verificación y aceptación” como puestos formales, y no dejar que los desarrollos los hagan de paso. Una vez que la IA abarató la implementación, la rentabilidad de estos dos puestos es la que más sube.

6. Cómo es de verdad el cuello de botella en cuatro sectores

Llevemos el “desplazamiento del cuello de botella” a cuatro sectores. En ninguno el cuello de botella está en escribir código.

Manufactura. El hilo es el CIO del principio. Planificación inteligente de producción, trazabilidad de calidad y optimización energética son funcionalidades técnicamente accesibles, con modelos en buena parte ya disponibles. El cuello de botella está en la integración conjunta de MES / ERP / calidad / reporte y en la validación sobre el terreno de los terminales de planta. El código de estos proyectos se escribe rápido; la integración de MES y ERP se come varias veces el tiempo de escribirlo. Solo cuando se coloca la aceptación en el terminal de planta y en la integración, los defectos se cortan in situ, en vez de aflorar en producción. Inditex, con su flujo de diseño-tienda alimentado por sistemas de reposición ajustada, y El Corte Inglés en su integración de logística y puntos de venta, viven el mismo patrón: la integración entre sistemas de planta y comerciales es donde se acumula el WIP.

Telecom / operador. Un cambio de tarifa o la apertura de una línea corporativa atraviesa canal, facturación, CRM, activación de red y planificación de instalación. La IA acelera el desarrollo en cada dominio; lo que se lleva el calendario es la integración extremo a extremo entre dominios y la verificación de consistencia. Telefónica y Movistar, con su petición de líneas corporativas, viven exactamente esto. El operador tiene además un cuello de botella propio: cumplimiento y conciliación. Un céntimo de diferencia en facturación ya es un incidente, así que el peso de la verificación aquí es mayor que en cualquier otro sector. En la apertura de una línea corporativa, la IA acelera cada dominio, pero la integración extremo a extremo más la conciliación de facturación se siguen llevando la mayor parte del calendario.

Finanzas. Un ajuste de riesgo crediticio o de una regla antimoney laundering cruza App, sistema central, motor de riesgo, data lakehouse y reporte regulatorio. Aquí la verificación pesa enormísimamente, porque un error en una operación es un incidente de cumplimiento. El cuello de botella está en explicabilidad, auditabilidad y trazabilidad: por precisa que sea la regla que escriba la IA, si no pasa el “¿por qué decidió así?” del regulador, no sale a producción. La iteración de reglas antimoney laundering es el caso típico: la IA acelera la redacción de la regla, pero la auditoría de explicabilidad del modelo y la alineación con el reporte regulatorio, juntos, se comen más de la mitad del ciclo. Santander y BBVA, con sus motores de riesgo y de prevención de blanqueo, operan bajo exactamente esta restricción.

E-commerce. Una promoción o una función de campaña cruza catálogo, transacciones, marketing, almacén y atención al cliente. La IA hace que las páginas y las APIs se escriban volando; el cuello de botella se va a pruebas de carga, consistencia de inventario, control de fraude y conciliación. Lo que cae la noche de campaña nunca es el código que se escribió lento, es el borde que no se verificó. La preparación de campaña lo resume: la IA genera la página de promoción enseguida, pero las pruebas de carga extremo a extremo y la verificación de consistencia de inventario se llevan la mayor parte de las horas de preparación. MercadoLibre, con sus campañas de Hot Sale y los picos de tráfico que implican, vive esta dinámica cada temporada.

El patrón de los cuatro sectores es nítido: la IA acelera “escribir”; lo que atasca es “ensamblar, verificar y alinear”. Invertir la capacidad de desarrollo ahorrada en estas tres cosas es donde está la mejora real.

7. Qué pasa si te equivocas: los tres desajustes más comunes

Primero: confundir “código escrito rápido” con “entrega más rápida”. Es la ilusión más común. El código es solo un eslabón de la cadena de entrega; ensancharlo no acelera la cadena, solo apila más trabajo en curso detrás del cuello de botella. La Teoría de Restricciones llama a esto inventario; en el software son PR sin aceptar y ramas sin integrar. El resultado es desarrollo más ocupado, negocio con más prisa y entrega sin cambiar — justo la situación del CIO del principio.

Segundo: acelerar la producción y, de paso, quitar puertas de calidad. Es el error típico contra el jidoka. Hay quien razona: “la IA escribe rápido y bien, así que se puede simplificar el code review y recortar pruebas”. Al revés: cuanto más rápida la producción, más crítica es la cuerda andon. Quitarse las puertas de aceptación equivale a dejar una línea sin personas al mando, girando a toda velocidad: los defectos llegan a producción más rápido todavía.

Tercero: gastar en lo que no es cuello de botella. Si el cuello de botella es integración, compras más licencias de programación con IA; si es verificación, contratas más desarrollo. La Teoría de Restricciones lo dejó claro: invertir en un eslabón que no es cuello de botella aporta cero a la salida total y solo deja los números peor. El orden correcto es localizar el cuello de botella y después volcar los recursos sobre él.

8. Lecciones para el decisor

Lección uno: antes de comprar herramientas, dibuja un mapa de cuello de botella. Desmenuza tus tres últimas entregas atascadas y mira dónde se fue el tiempo. ¿A escribir código, o a no poder ensamblar, no tener quién verificara, o no tener los requisitos claros? Lo que no puedes marcar en el mapa es adivinar desde lo técnico. Un mapa de cuello de botella vale más que cualquier lista de compra de herramientas: bloquea al menos la mitad de la inversión inútil en TI de una gran empresa.

Lección dos: invierte la capacidad ahorrada en requisitos y verificación. La IA acelera el desarrollo, lo que te permite liberar manos. Pon a esas personas formalmente en “definición de requisitos” y “verificación y aceptación”, y no a seguir escribiendo más código. La rentabilidad de estos dos puestos es la que más sube en la era de la IA.

Lección tres: ponle al software una cuerda andon. La aplicación más directa del jidoka es poner umbrales duros en tu CI/CD: si las pruebas no pasan, no se mergea; el review tiene que mirar intención y bordes; el despliegue progresivo se hace primero en alcance pequeño; la observabilidad es estándar. Cuanto más automatizada la producción, más firme tiene que ser esta puerta. Se trata de evitar que “código gratis” se convierta en “incidentes gratis”.

Lección cuatro: recoloca a las personas, no las retires. El jidoka apunta a la misma conclusión: cuanto más profunda la automatización, más hay que poner a la persona en “juzgar, aceptar y resolver la causa raíz”. Sacar a la persona del operar repitiendo y recolocarla en verificación y alineamiento es el movimiento central del diseño organizativo en la era de la IA, y es lo que los próximos artículos de la serie desplegarán.

9. Quizá te lo estés preguntando

“Solo estamos pilotando IA en un punto, ¿hace falta dibujar un mapa de cuello de botella de toda la empresa?” También un piloto tiene que ver claro: ¿el eslabón que pilotas es de verdad el cuello de botella? Si el atasco está en integración o verificación, pilotar IA en “escribir código” es gastar en lo que no es cuello de botella — justo el tercer desajuste de la sección 7. Un diagnóstico de cuello de botella, aunque sea pequeño, hace que el dinero de la herramienta se gaste bien.

“¿Las puertas de verificación no frenarán la entrega?” A corto plazo habrá fricción; a largo plazo es aceleración. La “rapidez” sin puertas de aceptación es rapidez para empujar defectos a producción, con coste de retrabajo desde diez veces arriba. La experiencia del jidoka es que resolver un defecto in situ cuesta una fracción de lo que cuesta dejarlo llegar downstream.

“¿Qué tiene que ver esto con la transformación con IA que ya estamos corriendo?” Relación directa. El hoyo más común de la transformación con IA es suponer que el cuello de botella está en “escribir código / capacidad” y comprar herramientas para ensanchar ese eslabón. Primero diagnostica el cuello de botella y luego decide dónde gastar. Es la razón por la que en el Marco de coaching en 7 pasos para la transformación con IA pongo la “evaluación de capacidades” y la “identificación de escenarios de valor” al principio: primero dónde está el cuello de botella, luego las herramientas.

Autochequeo inverso (responde sin maquillaje): en tu última entrega atascada, ¿el tiempo se fue en escribir código o en ensamblar, verificar y alinear? Tu herramienta de IA produce un montón de código — ¿cuánto sale a producción de forma estable y la gente usa de verdad? En tu CI/CD, ¿hay un umbral duro de “si las pruebas no pasan, no se mergea”? Si alguna de las tres te deja incómodo, deja de comprar más herramientas de IA y encuentra primero tu cuello de botella.

Lo que viene

Este es el tercer artículo de la serie “La transformación de la ingeniería de software en la era de la IA”, 15 en total. Hemos ido de Conway (la organización decide la arquitectura) a Team Topologies (cómo diseñar la organización), y ahora al desplazamiento del cuello de botella (cuando el código es casi gratis, a dónde se va el cuello de botella). El siguiente (n.º 4) cambia a una perspectiva más práctica: cómo elegir entre las herramientas mainstream de programación con IA. La conclusión puede ser contraintuitiva: la elección de herramienta es, en el fondo, una decisión organizativa que depende de tu madurez y de tu nivel de gobernanza, no de “quién escribe el código más llamativo”.

Nota de la serie: esta serie sigue rastreando la evolución más reciente de las herramientas de programación con IA, la arquitectura organizativa y los paradigmas de ingeniería de software — por ejemplo, cómo cambia la ley de Conway en la era de los agentes de IA en 2026, o la madurez del ecosistema de herramientas más reciente. Sigue la serie para obtener insight que se actualiza de forma continua.

Sobre esta serie

“La transformación de la ingeniería de software en la era de la IA” es una serie de investigación profunda dirigida a CIO, CDO, CTO y líderes digitales de sectores como telecom, finanzas, manufactura y e-commerce — 15 artículos en total. Construida sobre más de 200 artículos académicos e informes de sector, ofrece referencias de decisión anotadas con nivel de evidencia.

Soy ex ingeniero de IBM, coach certificado por ICF, con experiencia de campo entregando proyectos de IA y digitales para operadores y grandes empresas. Lo que escribo aquí es el juicio de campo forjado acompañando a empresas a salir de los hoyos.

Fuentes de referencia (verificadas)

Goldratt, E. M. (1984). The Goal: A Process of Ongoing Improvement. (fuente original de la Teoría de Restricciones, TOC; novela ambientada en una fábrica — fuente primaria)
Kim, G., Behr, K. & Spafford, G. (2013). The Phoenix Project. IT Revolution Press. (traslada la TOC de Goldratt a las operaciones de TI; el puente manufactura → software — fuente primaria)
Toyota. Toyota Production System — Jidoka. toyota-global.com (jidoka = automatización con toque humano; parada ante anomalía + intervención humana en la causa raíz; sistema andon — fuente primaria)
GitHub (2022/2024). The Economic Impact of the AI-Powered Developer Lifecycle. (Copilot completa ~46 % del código en ficheros habilitados; la lectura es “dentro de ficheros habilitados” — fuente primaria)
Stripe (2025/2026). Minions: Stripe’s one-shot, end-to-end coding agents. stripe.dev/blog; InfoQ reporta 1.300+ PR por semana, todos con revisión humana (primaria + secundaria)
NVIDIA / Jensen Huang. Declaración pública de que el 100 % de los ingenieros usa herramientas de programación con IA tipo Cursor (fuente de primera mano)
GitClear (2025). AI-Assisted Code Quality Research. (observa aumento de código duplicado / churn a corto plazo bajo asistencia de IA; sostiene “verificación se encarece” — secundaria)
Forsgren, N., Humble, J. & Kim, G. (2018). Accelerate. IT Revolution Press. (el rendimiento de entrega lo deciden cultura, flujo y feedback, no la velocidad individual de codificación — fuente primaria)