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: 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: 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.

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: 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