Opinión

La paradoja del desarrollo con IA: por qué en un proyecto desde cero la velocidad crece un 55% y en código maduro cae un 19%

Dos experimentos aleatorizados y rigurosos arrojaron resultados opuestos: en una tarea típica desde cero, el asistente de IA aceleró a los programadores un 55,8% (71 frente a 161 minutos), mientras que en repositorios maduros con un historial de 1,1 millones de líneas de código ralentizó a mantenedores experimentados en un 19%. El efecto más peligroso de la adopción de IA es la pérdida de calibración: los participantes del estudio de METR, en 246 tareas reales, se ralentizaron un 19%, pero en una encuesta retrospectiva estaban convencidos de haberse acelerado un 20% (la brecha entre percepción y realidad fue de 39 puntos porcentuales). Además de la velocidad, la generación de código sin control crea un punto ciego de seguridad: 14 paquetes declarados manualmente en un proyecto real se despliegan en 492 dependencias transitivas, y la proporción de nombres de paquetes alucinados por los modelos alcanza entre el 5,2% y el 21,7%.

La paradoja del desarrollo con IA: por qué en un proyecto desde cero la velocidad crece un 55% y en código maduro cae un 19%
Hamidun News.
Escuchar artículo
Ficha técnica y cifras clave
ParámetroDatos
Editor jefe
Dato clave #0Ralentización en código maduro (METR, 246 tareas): +19% de tiempo por tarea en desarrolladores con una antigüedad media de 5 años en el repositorio
Dato clave #1Error de autoevaluación (ceguera de calibración): brecha de casi 40 puntos porcentuales entre la sensación de aceleración (-20%) y la ralentización real (+19%)
Dato clave #2Aceleración en un proyecto desde cero (Microsoft/GitHub): -55,8% de tiempo (71,2 frente a 160,9 min) en un servidor HTTP típico creado desde cero
Dato clave #3Crecimiento oculto del árbol de paquetes y de las alucinaciones: 14 dependencias directas se despliegan en 492 paquetes (y hasta 1.442 en un proyecto web)
  • Ralentización en código maduro (METR, 246 tareas): +19% de tiempo por tarea en desarrolladores con una antigüedad media de 5 años en el repositorio
  • Error de autoevaluación (ceguera de calibración): brecha de casi 40 puntos porcentuales entre la sensación de aceleración (-20%) y la ralentización real (+19%)
  • Aceleración en un proyecto desde cero (Microsoft/GitHub): -55,8% de tiempo (71,2 frente a 160,9 min) en un servidor HTTP típico creado desde cero
  • Crecimiento oculto del árbol de paquetes y de las alucinaciones: 14 dependencias directas se despliegan en 492 paquetes (y hasta 1.442 en un proyecto web)

En algunas conferencias se muestran diapositivas sobre un aumento del doble en la velocidad con asistentes de IA, mientras que en otras se citan informes sobre cómo las redes neuronales ralentizan a los ingenieros sénior. La paradoja es que ambas afirmaciones se apoyan en ensayos controlados aleatorizados (RCT) rigurosos, con mediciones de tiempo al segundo, y ambas son ciertas.

En el experimento de Peng y colegas de Microsoft Research, GitHub y MIT Sloan (`arXiv:2302.06590`), a 95 desarrolladores se les asignó la tarea de escribir desde cero un servidor HTTP en JavaScript que pasara unas pruebas automatizadas predefinidas. Con autocompletado por IA, los participantes completaron la tarea en 71,2 minutos frente a 160,9 minutos del grupo de control, es decir, un 55,8% más rápido.

En julio de 2025, el equipo de METR (`arXiv:2507.09089`) llevó a cabo un RCT especular con 16 mantenedores experimentados y 246 tareas reales de producción en sus propios repositorios maduros (con una media de 1,1 millones de líneas de código, 10 años de historial del proyecto y 5 años de experiencia personal del participante, unos 1.500 commits).

Con herramientas de IA, los desarrolladores dedicaron un 19% más de tiempo a la tarea, y el 75% de los participantes terminó en números rojos.

¿Por qué los desarrolladores experimentados se equivocaron en la

evaluación de su propia velocidad en casi 40 puntos porcentuales?

La cifra más alarmante del informe de METR no es el propio +19% de tiempo, sino el colapso de la calibración humana. Antes de empezar, los expertos externos (34 economistas y 54 investigadores de machine learning) predijeron una aceleración del 38-39%, y los propios desarrolladores, del 24%. Pero tras terminar, después de completar las 246 tareas y registrar los tiempos, los participantes estaban sinceramente convencidos de que la IA les había ahorrado alrededor de un 20% del tiempo.

La sensación y el cronómetro difirieron en 39 puntos porcentuales (con una calibración normal de la predicción de duración de tareas de 0,64 y 0,59). La IA distorsiona la percepción del esfuerzo: sentarse en la silla del revisor y observar cómo corre el texto generado es psicológicamente más fácil que abrirse paso uno mismo por código heredado. De ahí la conclusión gerencial: cualquier informe sobre el «efecto de la adopción de IA» basado en encuestas a empleados mide dopamina, no productividad.

¿Dónde pasa la «frontera irregular» de las capacidades del modelo

entre el novato y el experto?

Si se combinan los datos de METR y Microsoft con los estudios de Harvard sobre 758 consultores de BCG (`Navigating the Jagged Technological Frontier`, 2026) y el trabajo de Brynjolfsson en QJE sobre 5.172 operadores de atención al cliente, se dibuja un cuadro unificado:

1. Efecto de novedad del contexto: en atención al cliente, la IA aportó en promedio +15%, pero en los novatos el incremento fue de +30-36%, mientras que en los veteranos resultó casi nulo. En un proyecto desde cero, cualquiera de nosotros es un novato, por eso ahí obtenemos un -55% de tiempo.

En un repositorio de cinco años, la mayor dificultad es mantener los invariantes tácitos de la arquitectura, que no están presentes en los pesos del modelo. 2. La trampa de la persuasión: dentro de la frontera de capacidades del modelo, los consultores con IA realizaron un 12,2% más de tareas y un 25,1% más rápido.

Pero fuera de esa frontera, la proporción de soluciones correctas cayó del 84,5% al 60-70,6%, mientras que los jueces externos calificaron la persuasión de esos textos erróneos un 17,9-25,1% más alta.

Para no caer en ese +19%, aplico cuatro reglas: nunca delegar la comprensión (indicar en la especificación el archivo exacto, la línea, la razón y el criterio de aceptación), bloquear mediante hooks `PreToolUse` solo los 25 comandos irreversibles entre 424 permitidos (desempaquetando wrappers como `ssh`, `python -c` y `base64`), mantener 93 KB de reglas modulares de arquitectura en disco y separar los niveles de delegación `Level 0-3`.

¿Cómo se convierten 14 paquetes declarados en 492 y qué peligro supone

el slopsquatting?

Según datos de USENIX Security 2025 (`arXiv:2406.10279`) sobre 576.000 fragmentos de código, los modelos inventan nombres de bibliotecas inexistentes en el 5,2% de los casos en LLM comerciales y en el 21,7% en los de código abierto (205.474 nombres fantasma únicos), algo que los atacantes aprovechan (`slopsquatting`). Comprobar el árbol real de dependencias de un proyecto propio puede hacerse en un segundo:

```python import json, sys

lock = json.load(open(sys.argv[1], encoding="utf-8")) root = lock["packages"][""] direct = len(root.get("dependencies", {})) + len(root.get("devDependencies", {})) total = len([k for k in lock["packages"] if k]) print(f"Declarados manualmente: {direct} | Reales en el árbol: {total}") ```

En mi bot, 14 bibliotecas declaradas se desplegaron en 492 paquetes, y en un proyecto web, en 1.442 paquetes. El mínimo obligatorio de higiene es hacer commit de los archivos lock, ejecutar `trufflehog`, `trivy fs --scanners vuln,secret` y `syft`.

Los hooks de seguridad, los niveles de delegación y el control de dependencias ya están integrados en el stack de [Nomad AI](https://nomadnet.ai) y en la plataforma [agent.nomadnet.ai](https://agent.nomadnet.ai). Es posible aprender vibe coding de ingeniería sin perder el control sobre la arquitectura en [Hamidun Academy](https://academy.hamidun.com) (72 horas de prueba gratuita), y las reglas y guardas de producción están disponibles en [Vibe Club](https://hamidun.com/club).

Historia

Preguntas frecuentes sobre la noticia

¿Dónde pasa la «frontera irregular» de las capacidades del modelo entre el novato y el experto?

Si se combinan los datos de METR y Microsoft con los estudios de Harvard sobre 758 consultores de BCG (`Navigating the Jagged Technological Frontier`, 2026) y el trabajo de Brynjolfsson en QJE sobre 5.172 operadores de atención al cliente, se dibuja un cuadro unificado: 1. Efecto de novedad del contexto: en atención al cliente, la IA aportó en promedio +15%, pero en los novatos el incremento fue de +30-36%, mientras que en los veteranos resultó casi nulo. En un proyecto desde cero, cualquiera de nosotros es un novato, por eso ahí obtenemos un -55% de tiempo. En un repositor

¿Cómo se convierten 14 paquetes declarados en 492 y qué peligro supone el slopsquatting?

Según datos de USENIX Security 2025 (`arXiv:2406.10279`) sobre 576.000 fragmentos de código, los modelos inventan nombres de bibliotecas inexistentes en el 5,2% de los casos en LLM comerciales y en el 21,7% en los de código abierto (205.474 nombres fantasma únicos), algo que los atacantes aprovechan (`slopsquatting`). Comprobar el árbol real de dependencias de un proyecto propio puede hacerse en un segundo: ```python import json, sys lock = json.load(open(sys.argv[1], encoding="utf-8")) root = lock["packages"][""] direct = len(root.get("dependencies", {})) + len(root.get("d

ZK
Zhemal Khamidun — CPO de Alpina Digital, product manager de AlpinaGPT. Crea productos de IA desde 2019. Hamidun News es un proyecto personal que creció hasta ser un agregador en producción con más de 6.000 lectores.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
¿Qué te parece?
Cargando comentarios…