# El cuello de botella de la IA ya no es escribir código > Business Insider llama parálisis al costo oculto del AI coding. La IA genera código más rápido de lo que un equipo alcanza a revisar y mantener. - URL: https://www.iqsource.ai/blog/revisar-es-el-nuevo-cuello-de-botella/ - Publicado: 2026-06-29 - Autor: Ricardo Argüello, IQ Source El lunes Business Insider publicó algo que va a incomodar a más de un director de tecnología: el costo oculto del auge del *AI coding* es humano, no técnico, y se parece bastante a una parálisis. Tim Paradis y Thibault Spirlet lo cuentan con la voz de ingenieros reales: la primera reacción ante cada herramienta nueva ya no es "qué emocionante", es "voy atrasado". Los lanzamientos de modelos pasaron de 18 en 2023 a 69 en 2025. Nadie alcanza a probar lo que salió la semana pasada antes de que salga lo de esta. Pero la parálisis no es culpa de la IA. Y la salida tampoco es otra herramienta. Es un sistema que tu equipo controla, con revisión y *ownership* adentro. Te explico por qué. ## El cuello de botella se movió, y casi nadie lo reorganizó Gergely Orosz, que escribe el boletín de ingeniería más leído de la industria, lo dijo sin rodeos: la velocidad de tecleo nunca fue el cuello de botella. Escribir el código siempre fue la parte rápida. Lo lento siempre fue entenderlo, revisarlo y decidir si entra a producción. Entonces llega la IA y resuelve justo la parte que ya era rápida. Genera código el doble de rápido que hace seis meses. ¿Y la parte lenta? Sigue igual de lenta, porque revisar exige que un humano cargue el contexto completo en la cabeza, y eso no se acelera con un modelo más grande. El resultado es predecible. CIO lo tituló "la IA mató la revisión de código": los PRs se acumulan o se aprueban a ciegas. La fila de revisión es el nuevo cuello de botella, y la mayoría de los equipos le echó más producción encima sin tocar la fila. Esto es lo mismo que vengo diciendo desde otro ángulo cuando hablo de [los cuatro loops que reemplazaron al prompt engineering](/blog/cuatro-loops-reemplazaron-prompt-engineering/): el valor no está en generar más rápido, está en cerrar el loop de revisión y corrección con criterio. Generar es el paso fácil. Siempre lo fue. ## Lo que la velocidad esconde Acá es donde el discurso de "la IA nos hizo 10x más productivos" se topa con los datos. METR realizó un estudio controlado con desarrolladores experimentados trabajando en repos reales de más de un millón de líneas. El resultado incomoda: fueron 19% más lentos usando IA. Y lo más revelador está en que ellos creyeron que habían sido 20% más rápidos. Una brecha de casi 40 puntos entre lo que sintieron y lo que pasó. Esa brecha es la parálisis en estado puro. El equipo no deja de trabajar. Trabaja con la sensación de ir volando mientras avanza menos, y nadie lo nota hasta que el calendario no cuadra. GitClear analizó 211 millones de líneas y midió la huella: el código copiado y pegado subió, los bloques duplicados se multiplicaron, y el código que se mueve o se refactoriza (la señal de que alguien está limpiando, no solo agregando) cayó a la mitad. Más volumen, menos cuidado. Y el reporte DORA 2024 de Google lo confirma a nivel de entrega: por cada aumento en el uso de IA, midieron una caída en el throughput de entrega y otra mayor en la estabilidad. La IA empuja el tamaño de cada cambio hacia arriba, y los lotes grandes son más difíciles de revisar y más fáciles de romper. Ninguno de estos tres números dice "la IA es mala". Dicen algo más incómodo: la IA es muy buena acelerando la mitad del trabajo que ya era rápida, y eso descompensa todo el sistema si no rediseñas la otra mitad. ## Deuda cognitiva no es lo mismo que deuda técnica En los comentarios de ese mismo artículo de Business Insider, Jean-François Bernier dejó la mejor frase de todo el hilo. Dijo que los ingenieros no están abrumados por la IA en sí, sino por la expectativa de absorber cada herramienta, agente y benchmark nuevo a medida que sale. Y le puso nombre: eso dejó de ser aprender y pasó a ser deuda cognitiva. Vale separar bien los dos tipos de deuda, porque se confunden y son muy distintos. La deuda técnica vive en el código. Es feo, está duplicado, no tiene pruebas. Un linter la detecta, un refactor la paga. La deuda cognitiva vive en el equipo. Es la comprensión que se pierde cuando delegas tanto que dejas de entender lo que entregas. No hay linter que la detecte. Se manifiesta el día que algo se rompe en producción y la persona que aprobó el PR no puede explicar por qué el código hacía lo que hacía, porque nunca lo cargó en la cabeza, solo lo dejó pasar. El MIT Media Lab publicó un estudio preliminar (todavía sin revisión por pares, así que tómalo como señal, no como prueba) que midió justo esto con electroencefalogramas: el grupo que se apoyó demasiado en el modelo mostró menor conectividad cerebral y peor recuerdo de lo que acababa de producir. Lo llamaron, con buen tino, deuda cognitiva. Esto conecta directo con la distinción que tracé entre [delegación cognitiva y rendición cognitiva](/blog/delegacion-cognitiva-no-rendicion/): delegar la ejecución está bien; rendir el criterio es donde empieza el problema. Un equipo que aprueba código que no entiende no está delegando, se está rindiendo, y lo hace de forma muy eficiente. ## Lo que hacemos diferente en IQ Source La lección apunta a construir un sistema en lugar de comprar otra herramienta, más que a "frena la IA" o "revisa más despacio", que es la misma tesis que expliqué cuando [Block construyó Builderbot en vez de comprar un chatbot](/blog/construye-el-sistema-no-compres-un-chatbot/). Un sistema, acá, significa cosas concretas. Significa loops de trabajo donde la revisión no es un paso opcional al final sino parte del loop. Significa que cada cosa que el agente entrega tiene un dueño humano que la entiende, no solo alguien que la aprobó. Significa criterios de calidad explícitos definidos antes de generar nada, para que revisar no sea leer ocho páginas a ciegas sino comparar contra una referencia que ya existe. Y significa cambiar la métrica. Mientras midas cuántas líneas o cuántos PRs genera tu equipo, estás midiendo lo fácil. La métrica que importa es cuánto del código que entra a producción tiene a alguien que lo entiende y responde por él. Eso mide coherencia, no volumen. Y la coherencia es lo que se rompe primero cuando la velocidad sube sin que el sistema cambie. Eso es lo que diseñamos en la primera fase de [AI Maestro](/ai-maestro/): no enchufamos un agente y te deseamos suerte. Mapeamos tus procesos reales, definimos los criterios con los que vas a evaluar lo que el agente produce, y construimos el sistema de revisión que convierte la velocidad de la IA en avance real en lugar de una fila de PRs sin abrir. Si tu equipo siente que produce más que nunca pero llega menos lejos, la IA no está fallando. Le pusiste un motor de carreras a un proceso de revisión que sigue caminando. Arreglemos la fila, no el motor. Arreglemos la fila de revisión, no el motor ## Preguntas frecuentes ### ¿Por qué el auge del AI coding causa parálisis en los equipos de ingeniería? Porque la IA genera código más rápido de lo que cualquier humano puede revisarlo. El cuello de botella se mueve de escribir a revisar, y la revisión no se acelera con otro modelo. Los equipos sin un sistema para absorber ese volumen acumulan código sin revisar, pierden contexto de lo que entregan y avanzan menos a pesar de producir más. ### ¿Qué dicen los estudios sobre la productividad real del AI coding en 2026? Un estudio controlado de METR midió que desarrolladores experimentados fueron 19% más lentos usando IA, aunque creyeron que habían sido 20% más rápidos. GitClear documentó más código copiado y menos refactorizado, y el reporte DORA 2024 asoció el uso de IA con menos throughput y menos estabilidad de entrega. La velocidad percibida no coincide con la medida. ### ¿Qué es la deuda cognitiva en el contexto de la adopción de IA? La deuda cognitiva es la pérdida de comprensión que acumula un equipo cuando delega tanto a la IA que deja de entender lo que entrega. A diferencia de la deuda técnica, no vive en el código sino en las personas. Un linter detecta la deuda técnica; nadie detecta la cognitiva hasta que algo falla y nadie sabe por qué. ### ¿Cómo evita una empresa el cuello de botella de revisión que genera el AI coding? Construyendo un sistema en lugar de comprar otra herramienta: loops de trabajo que el equipo controla, con revisión y propiedad del código integradas, y criterios de calidad explícitos para evaluar lo que el agente entrega. La métrica deja de ser cuánto código se genera y pasa a ser cuánto entiende y aprueba con criterio quien lo revisa.