La IA nos ha hecho más rápidos. Y luego nos hizo más lentos.

Durante el último año, hemos escuchado la misma historia de los clientes, de nuestros propios equipos y de todo el sector. Los ingenieros adoptan una herramienta de codificación de IA y se sienten como unos codificadores sobrehumanos. Envían características a una velocidad récord, las solicitudes de extracción se disparan y luego, misteriosamente, unos meses más tarde, el trabajo se ralentiza a un ritmo por debajo del que estaba antes de que llegara la herramienta. La base de código se ha vuelto más difícil de gestionar y de cambiar, porque nadie recuerda exactamente lo que cambió durante esa explosión sobrehumana. El sector ahora tiene un nombre para esa brecha: la deuda cognitiva, que es la distancia creciente entre la cantidad de código que contiene un sistema y la cantidad que el equipo aún entiende. Nadie tenía los datos para mostrarlos. Ahora lo hacemos.

Un estudio de la Universidad Carnegie Mellon (CMU) de 807 repositorios de código abierto cuantifica lo que hemos escuchado. La adopción de un asistente de codificación de IA produjo una gran pero temporal ganancia de velocidad: las líneas añadidas aumentaron un 281% en el primer mes, pero luego se volvieron estadísticamente indistinguibles de los proyectos de control en el tercer mes. No solo se trata de una pérdida de velocidad, sino también de una disminución persistente de la calidad. Las comprobaciones automatizadas del código marcaron un 29,7% más de problemas y el código obtuvo una puntuación un 40,7% más alta en una medida estándar de lo difícil que es leer. Los modelos del documento muestran que la complejidad acumulada suprime la velocidad futura. Y un resultado que creemos que merece destacar, el código generado por IA, resulta ser intrínsecamente más complejo que el código escrito por humanos, incluso después de controlar la rapidez con la que crece un proyecto. Creemos que la causa principal es un problema de entrenamiento. Los modelos están optimizados para lo que es barato verificar (¿se ejecuta el código?) en lugar de por lo que hace que las bases de código sean resilientes (arquitectura, legibilidad, coherencia). La manera de corregir los efectos posteriores es doble. La solución de herramientas es proporcionar el contexto, la memoria y las barreras de la IA. La solución de práctica es que sus técnicos, y no la IA, escriban el documento de especificaciones y diseño antes de la primera línea de código.

Los investigadores midieron los cambios en el código, no la productividad autonotificada

El estudio es «Velocidad a costa de la calidad: Cómo la IA Cursor aumenta la velocidad a corto plazo y la complejidad a largo plazo en los proyectos de código abierto» de He, Miller, Agarwal, Kästner y Vasilescu. Sin embargo, la productividad autodeclarada es un instrumento poco fiable. Un estudio controlado por separado de 2025 descubrió que los desarrolladores de código abierto experimentados que usaban herramientas de IA no eran mediblemente más rápidos en tareas reales, a pesar de creer que lo eran. Así que el equipo de CMU midió los repositorios en lugar de encuestar a los desarrolladores. Encontraron 807 proyectos de GitHub que adoptaron Cursor entre enero de 2024 y marzo de 2025 (la adopción es visible en la historia de Git una vez que un equipo comete los archivos de configuración del Cursor) y los compararon con 1380 proyectos similares, con el mismo lenguaje de codificación y trayectorias de actividad comparables, que nunca los adoptaron durante el estudio.

El diseño experimental significa que la pregunta no es «los proyectos asistidos por IA han ido rápidamente», sino «fueron más rápidos de lo que lo harían de otro modo, en comparación con sus gemelos no adoptivos». Enmarcarlo de esta manera acaba con cualquier cosa que haya afectado a todo el sector a la vez (por ejemplo, mejores modelos básicos o un trimestre de vacaciones lento), porque estos afectan a ambos grupos por igual.

Se ha detectado la adopción en este estudio, no se ha impuesto. El compromiso de un archivo de configuración del cursor demuestra que un equipo empezó a usar la herramienta, no que todos los desarrolladores la usaban a diario. Esta es una analogía que llevaremos a cabo en el REST de esta publicación. Imagine estudiar si el café hace que las personas sean más productivas, haciendo un seguimiento de todos los que compraron una máquina de café casera. Algunos de esos compradores elaboran una olla cada mañana y otros dejan que la máquina recoja polvo, pero el estudio cuenta lo mismo con cada propietario (los investigadores lo llaman diseño por intención de tratar y tiende a reducir el efecto medido). Lo que refuerza el estudio es un patrón llamado dosis-respuesta. La idea es sencilla. Si el café es realmente lo que está impulsando el efecto, los bebedores más pesados deberían mostrar el mayor efecto. El equipo de CMU comprobó el mismo patrón en los repositorios y lo encontró. Cuando se limitaron a los fabricantes de cerveza diarios (es decir, proyectos con pruebas de un uso pesado y sostenido de la herramienta Cursor), cada efecto se hizo más fuerte, no más débil, que es exactamente la señal que esperaría si la propia herramienta estuviera causando los cambios.

El grupo de control no estaba necesariamente libre de café. La adopción de Cursor deja un rastro en el repositorio, pero el uso de Copilot o ChatGPT no deja nada, por lo que no hay manera de saber qué proyectos de control utilizaban esas otras herramientas. En la analogía, el grupo de control es todo el mundo sin una máquina en casa y las personas sin una máquina son difíciles de rastrear. Algunos van a un café todas las mañanas, otros nunca beben café y, desde el exterior, parecen idénticos. No todas las personas del estudio beben café, pero lo que separa a los grupos es la fricción. Por lo tanto, el estudio mide la propiedad de la máquina frente a esa combinación desconocida. Sigue siendo una comparación significativa, porque una máquina de su cocina convierte el café en un hábito que dura todo el día de una manera que una carrera de café ocasional nunca hará. Del mismo modo, un agente que vive dentro del editor produce mucho más código que una ventana de chat en la que tiene que escribir manualmente. Pero eso significa que la referencia no está libre de cafeína, así que, en cualquier medida en que los proyectos de control ya estuvieran usando IA, los efectos notificados subestiman los reales.

Por lo tanto, los autores descubrieron que la adopción del Cursor hace que los proyectos sean más rápidos… pero no durante mucho tiempo.

En el primer mes después de la adopción, las líneas añadidas aumentaron un 281% y los compromisos aumentaron un 55% en relación con los controles emparejados. El segundo mes cayó hasta +48% de líneas y +14% de compromisos y, en el tercer mes, los adoptantes eran estadísticamente indistinguibles del grupo de control. Promediado durante todo el periodo posterior a la adopción, las líneas añadidas aumentaron un 28,6% y el efecto medio sobre los recuentos de compromisos no fue significativo en absoluto. Todo el beneficio de la velocidad de adopción de la herramienta se concentra en las primeras ocho semanas.

Figura 1: La codificación de IA con Cursor acelera la entrega al principio, pero ralentiza a los equipos dos meses más tarde y aumenta la complejidad del código. Fuente. 

Donde va la velocidad

Para entender por qué el aumento de la productividad desaparece, tenemos que volver a la analogía del café. La primera copa que bebió golpeó inmediatamente. Tuvo un zumbido; se sintió con energía y preparado para afrontar el día. Unos meses más tarde, esa misma taza de café apenas se registra. Ya no le eleva por encima de lo normal; simplemente le lleva a la normalidad. Lo que importa para nuestra historia es que el café nunca ha cambiado. Su cuerpo lo hizo, adaptándose en segundo plano, creando la resistencia que redujo el zumbido de la cafeína.

Los proyectos de software que adoptan herramientas de codificación de IA siguen una transformación similar. El estudio muestra que la complejidad del código es lo que desempeña el papel de la resistencia del cuerpo. La herramienta sigue generando código al mismo ritmo que siempre lo ha hecho, pero cada mes de salida asistida por IA hace que la base de código sea un poco más difícil de leer y seguir para los humanos, y el código difícil de leer ralentiza a todos los que lo tocan después. Los autores pudieron cuantificar este efecto concluyendo que duplicar la complejidad de una base de código reduce la velocidad de desarrollo futura en aproximadamente dos tercios. En otras palabras, la herramienta que acelera el progreso en el primer mes también está aumentando la complejidad que dificulta la gestión seis meses después.

La pregunta de seguimiento natural es si la IA escribió peor código. La calidad del código tiene dos dimensiones: si está escrito con un estilo que tiene menos probabilidades de generar errores y si hace el trabajo de un modo sencillo o complejo. Una medida común de la primera es con advertencias de análisis estático (que surgen mediante herramientas que escanean una base de código y señalan errores probables, brechas de seguridad y patrones difíciles de mantener) y la segunda con medidas de complejidad del código (también generadas por herramientas). El documento examina cada uno por separado.

La IA no escribió código estilísticamente peor (medido por advertencias de análisis estático). Código línea por línea asistido por IA recogido aproximadamente el mismo número de indicadores que el código escrito por el ser humano. Lo que ha cambiado es la cantidad de código. Los proyectos crecieron mucho más rápido y una base de código con el doble de líneas tiene aproximadamente el doble de indicadores, sin importar quién los escribiera. El recuento de problemas aumentó porque el recuento de código aumentó, no porque el código empeoró.

Sin embargo, la IA escribió un código más complejo. Tome dos proyectos que crecen al mismo ritmo, uno usando la herramienta de IA y otro no. Los autores realizaron un seguimiento de los 2187 proyectos mes a mes, puntuaron su código con la misma herramienta automatizada y lo ajustaron al tamaño y la tasa de crecimiento de cada proyecto. Incluso entonces, los proyectos asistidos por IA acabaron con un código que era aproximadamente un 9% más difícil de leer. La misma cantidad de código, solo un código más difícil de leer. Y el código más difícil de leer es más difícil de revisar, más difícil de depurar y más difícil de cambiar, que es exactamente el tipo de resistencia que elimina las ganancias de velocidad que mencionamos anteriormente.

Lo que las empresas pueden hacer para evitar la ralentización

La recomendación del artículo es sencilla. Si la IA escribe el doble de código, necesita el doble de comprobaciones. Hemos notado dos maneras de seguir el ritmo, una de herramientas y otra de práctica.

Corregir#1: Proporcione el contexto, la memoria y las barreras de la IA

Estas tres correcciones de herramientas suponen mostrar las cosas de IA que no puede descubrir por sí sola. Las herramientas de contexto crean un índice de búsqueda de su repositorio, por lo que en lugar de reinventar el trabajo que su equipo ya ha terminado, el modelo lo encuentra y se basa en él. Los archivos de memoria (.cursorrules, CLAUDE.md, AGENTS.md) son instrucciones permanentes que la IA lee al inicio de cada sesión, en las que le dice cómo funciona su equipo, por ejemplo, que todo el acceso a la base de datos pasa por una capa. Hay un detalle importante en el método del estudio, ya que los investigadores de la CMU identificaron a los adoptantes escaneando exactamente estos archivos. Los equipos que adoptaron lo primero ya estaban siguiendo las buenas prácticas de ingeniería de software y llevaron esos hábitos al mundo de la codificación de IA.

Sin embargo, algunas reglas son demasiado importantes para dejarlas en un archivo de memoria, porque un archivo de memoria es solo una instrucción y las instrucciones pueden pasarse por alto o ignorarse. Reglas como esta pertenecen al pipeline en sí, como parte de sus pruebas automatizadas. Piense en la diferencia entre una señal de límite de velocidad y un bache de velocidad. El letrero le pide que cumpla, pero la aceleración lo hace cumplir. Una barandilla conectada a pruebas automatizadas es un obstáculo para la velocidad. La IA no puede acabar con ella por muy confusa que esté y tampoco lo pueden hacer los colaboradores humanos.

Ninguna de estas herramientas se detiene en la base de código porque un agente no solo escribe código, sino que lee y produce datos empresariales con la misma rapidez. Y los problemas de datos tienen un gemelo de código equivalente. 

Empiece con el índice de contexto. Un índice de repositorio impide que un agente reinvente el código que su equipo ya escribió. Un catálogo de datos impide que reinvente o malinterprete los datos que su empresa ya posee. Eso es lo que hace Everpure Data Intelligence. Descubre datos continuamente en toda la propiedad. Apunte a un modelo capaz de datos dispersos, no clasificados y despojados de contexto y volverá a tener confianza y a tener un sentido bien redactado. Son los datos equivalentes al código que se ejecuta y que nadie puede mantener. 

Los archivos de memoria también tienen un gemelo de datos. CLAUDE.md le dice a un agente cómo trabajar con una base de código. Una ontología empresarial le dice lo que significa su empresa por «cliente», «usuario activo» o «ingresos». 

Lo mismo ocurre con las barreras y, honestamente, esta es la que la mayoría de las empresas no implementan. Un marco de evaluación es un bajón de velocidad en nuestra analogía anterior. Por lo que se refiere a los datos, eso significa una clasificación y una política que viajan con los propios datos, para que un agente no pueda alcanzar datos regulados o inadecuados, sin importar cómo se exprese la indicación. La salida de IA necesita auditar de la misma manera que el código de IA necesita pruebas. 

Entender sus datos es solo la mitad de la solución. Everpure Data Stream toma lo que ahora entiende y lo convierte en algo que un agente puede usar, automatizando el camino de los datos brutos de la empresa al contexto vectorizado, gobernado y preparado para la IA. La inteligencia de datos le proporciona el contexto en el que la IA puede confiar. Data Stream le proporciona la forma que la IA puede usar. 

Las apuestas en el lado de los datos también son mayores. Una base de código que conlleva deuda cognitiva ralentiza a su equipo y todo el mundo la ve en los números de sprint. Una propiedad de datos que tiene deuda cognitiva no ralentiza nada. El agente sigue respondiendo a toda velocidad y las respuestas vuelven equivocadas, con la misma voz segura y bien redactada que nadie vuelve a comprobar.

Corregir#2: Escriba primero las especificaciones

La segunda solución toma prestada una idea del diseño del plan de estudios llamada diseño retroactivo. Un buen profesor escribe primero el examen final y luego desarrolla el plan de estudios y el plan de estudios que prepara a los estudiantes, porque el examen es donde usted decide lo que realmente importa. Un documento de especificaciones o diseño desempeña el mismo papel en un proyecto asistido por IA. Es aquí donde los ingenieros deciden lo que importa antes de escribir la primera línea de código: qué características crear, qué modos de fallo anticipar, qué concesiones aceptar —la previsión que separa una base de código de producción de un prototipo codificado por vibraciones—. Escribe el examen al final y probarás a los estudiantes el material que el plan de estudios nunca ha cubierto. Revise el código al final y tendrá el mismo problema. 

Hay una razón más por la que el documento es más importante ahora que antes. En un equipo humano, un documento de diseño puede leerse una docena de veces durante la vida de un proyecto, siempre que alguien compruebe que el trabajo sigue cumpliendo el plan. Un agente de IA lo lee cada vez que toca la base de código, cientos de veces en un solo sprint. Un documento que solía ser una referencia ocasional ahora guía casi todas las líneas de código escritas. Esto también significa que el nivel de atención que hay que prestar por escrito también tiene que aumentar.

Mantenga la máquina de café

El estudio de CMU confirma la historia que los clientes siguen contando. Una herramienta de codificación de IA proporciona una verdadera ráfaga de velocidad, de unos dos meses de velocidad, al tiempo que genera la deuda cognitiva que finalmente reduce la ganancia, de manera similar a como una taza de café diaria genera la tolerancia que reduce el zumbido. El código no es más flexible que lo que escriben los humanos; simplemente hay mucho más de él y es más difícil de leer para las personas. Una precaución sobre el alcance es que los datos proceden de proyectos de código abierto, en los que la revisión del código es famosamente incoherente. Una empresa con una revisión y una prueba obligatorias puede debilitar el efecto, pero nadie debe asumir que es inmune.

Nada de esto es una razón para devolver la máquina de café de IA. Es una razón para mover el juicio humano aguas arriba, hacia las especificaciones que consume la IA, los archivos de memoria que lee y las reglas de prueba automatizadas que no puede romper, en lugar de gastar ese juicio aguas abajo revisando miles de líneas generadas. El impulso del primer mes le indica que la capacidad es real. Si todavía tiene ese impulso seis meses más tarde, depende de la ingeniería que ponga en la herramienta. Implemente esas prácticas cuando las adopte, no cuando las cosas empiecen a ralentizarse.