Lo que dicen los datos sobre programar con IA generativa
La conversación pública sobre inteligencia artificial generativa aplicada al desarrollo de software se mueve entre dos extremos igual de inútiles: el entusiasmo que promete construir sin saber nada, y el rechazo que descarta la herramienta por completo. Ninguno de los dos resiste una mirada a la evidencia.
Yo construyo con IA todos los días. Y precisamente por eso me interesa lo que miden los estudios, no lo que prometen los anuncios. Revisé cuatro investigaciones publicadas entre 2025 y 2026 —dos de ellas con metodología especialmente rigurosa— y el panorama que dibujan juntas es más interesante que cualquiera de los dos extremos.
1. La adopción ya no se discute. Los resultados, sí
El informe DORA 2025 de Google Cloud, titulado State of AI-assisted Software Development, encuestó a cerca de 5.000 profesionales de tecnología en todo el mundo y sumó más de 100 horas de datos cualitativos. Su primer hallazgo es de contexto: alrededor del 90% de los encuestados usa herramientas de IA en su trabajo, un aumento de 14 puntos frente al año anterior, con una mediana de unas dos horas diarias dedicadas a trabajar con ellas.
Pero el hallazgo que importa no es ese. Es este: la IA no arregla a un equipo, amplifica lo que ya es. Los equipos sólidos se vuelven más eficientes. Los equipos con problemas ven cómo esos problemas se intensifican.
Y hay un matiz que conviene no saltarse. La adopción de IA se asocia con mayor rendimiento individual y mayor volumen de entrega, revirtiendo un hallazgo negativo del año anterior. Pero al mismo tiempo se mantiene asociada a mayor inestabilidad en la entrega: más incidentes críticos, más despliegues no planificados. Se produce más software y se rompe más seguido.
La lectura de DORA es que el valor no está en la herramienta, sino en el sistema donde opera: la calidad de las plataformas internas, la claridad de los flujos de trabajo y la alineación de los equipos.
📄 Anuncio oficial del informe DORA 2025 — Google Cloud
2. El experimento que contradijo a todos, incluidos sus autores
En julio de 2025, la organización sin ánimo de lucro METR publicó algo poco común en este campo: un ensayo controlado aleatorizado, la misma metodología que se usa en ensayos clínicos.
El diseño fue deliberadamente realista. Dieciséis desarrolladores de código abierto con experiencia trabajaron sobre 246 tareas reales —correcciones, funcionalidades, refactorizaciones— en repositorios que ya conocían bien, con unos cinco años de experiencia previa en esos proyectos. Cada tarea se asignó al azar a una de dos condiciones: con IA permitida o sin ella.
Los autores esperaban encontrar una aceleración. Encontraron lo contrario: las tareas con IA permitida tomaron un 19% más de tiempo.
Y aquí está el dato que de verdad debería incomodarnos. Antes de empezar, los desarrolladores estimaban que la IA los aceleraría un 24%. Después de terminar —después de haber vivido la desaceleración en carne propia— seguían estimando que los había hecho un 20% más rápidos. La distancia entre percepción y medición fue de casi 40 puntos porcentuales.
Dos advertencias necesarias. Primero: es un estudio con 16 participantes en un contexto muy específico (repositorios maduros, desarrolladores expertos en su propio código). No es una ley general. Segundo, y más importante: el propio METR etiqueta el resultado como histórico —refleja herramientas disponibles entre febrero y junio de 2025— e indica haber publicado datos nuevos sobre herramientas de finales de 2025. Antes de citarlo como estado actual, conviene revisar esa actualización.
Lo que el estudio sí demuestra, y sigue vigente, es más sutil: la sensación de productividad no es evidencia de productividad. Y quien decide su forma de trabajar basándose en cómo se siente, está decidiendo a ciegas.
3. La deuda que no aparece hoy
GitClear aborda otra dimensión: qué le pasa al código con el tiempo. Su investigación analizó 211 millones de líneas de código modificadas entre 2020 y 2024.
Las señales van todas en la misma dirección. El código "movido" —el indicador que GitClear usa para rastrear refactorización y reutilización— cayó de cerca del 25% de las líneas modificadas en 2021 a menos del 10% en 2024. El código copiado y pegado subió del 8,4% al 12,3% en el mismo periodo. Y 2024 fue el primer año del conjunto de datos en que el código copiado superó al código refactorizado.
El dato más llamativo: durante 2024, los bloques con cinco o más líneas duplicadas se multiplicaron por ocho.
Un informe posterior de la misma organización extiende la serie hasta 2026 y reporta que la caída del código movido y el aumento de la duplicación continuaron. Conviene tomarlo como una tendencia observada, no como una relación causal probada: correlación con la adopción de IA no es lo mismo que causalidad demostrada.
La consecuencia práctica es directa. El código duplicado funciona, hasta que hay que cambiarlo: entonces cada copia es un sitio más donde aplicar la corrección, y cada copia olvidada es un error futuro. Es una factura que no se paga el día que se escribe el código, sino meses después.
📄 Investigación 2025 — GitClear · 📄 Informe 2026
4. Funciona, pero no es seguro
El informe 2025 GenAI Code Security Report de Veracode evaluó más de 100 modelos de lenguaje sobre 80 tareas de programación en Java, JavaScript, Python y C#, centradas en cuatro categorías de vulnerabilidad reconocidas.
El resultado: el 45% de las muestras de código generado introdujo vulnerabilidades del OWASP Top 10. No son fallas exóticas: son las categorías más comunes de la seguridad web. Cuando los modelos debían elegir entre una forma segura y una insegura de escribir algo, eligieron la insegura casi la mitad de las veces.
El desglose es revelador. Los modelos manejan bien lo que se resuelve con un patrón reconocible —consultas SQL parametrizadas, librerías de cifrado estándar— y fallan sistemáticamente en lo que exige seguir el flujo de datos entre varias líneas o archivos: cross-site scripting e inyección en registros mostraron tasas de fallo muy altas.
Y el dato que cierra el argumento: una actualización de Veracode publicada en 2026 reporta que, mientras la corrección sintáctica del código generado supera el 95%, la tasa de aprobación en seguridad sigue estancada en torno al 55% —prácticamente igual que dos años antes. La capacidad de escribir código que funciona avanzó. La de escribir código seguro, no.
📄 Informe GenAI Code Security — Veracode · 📄 Actualización 2026
Lo que estos cuatro estudios dicen juntos
Ninguno de estos trabajos concluye que la IA generativa sea un error. Lo que dibujan en conjunto es un patrón más útil:
La IA generativa desplazó el cuello de botella, no lo eliminó. Escribir código dejó de ser lo difícil. Lo difícil pasó a ser todo lo demás: verificar, entender, mantener, asegurar. Quien no traslade su esfuerzo a esas tareas termina produciendo más rápido un problema más grande.
La velocidad percibida no es velocidad real. Es la lección más transferible del ensayo de METR, y aplica más allá de la programación: cualquiera que evalúe su productividad por cómo se siente, está midiendo mal.
El costo se paga después. Duplicación, deuda técnica, vulnerabilidades. Nada de eso se nota el día del despliegue; todo se nota a los seis meses.
El criterio se volvió más valioso, no menos. Si el modelo elige mal casi la mitad de las veces en decisiones de seguridad, alguien tiene que saber distinguir. Ese alguien eres tú.
Y por eso la conclusión de DORA es la que mejor resume todo: la IA amplifica lo que ya hay. Si hay disciplina, revisión y criterio, amplifica eso. Si hay prisa y ausencia de verificación, amplifica eso también, y más rápido.
Cómo lo aplico
No publico nada que no pueda explicar línea por línea. Los secretos nunca van escritos en el código. Todo lo que la IA genera pasa por revisión antes de llegar a producción —en mi propio proyecto actual, un agente dedicado a calidad me bloqueó un despliegue por una validación de acceso mal ubicada, y esa fricción fue exactamente lo que evitó el problema.
Nada de eso me hace más lento. Me hace publicable.
La IA generativa es la mejor puerta de entrada que ha existido para construir tecnología. Los datos no dicen lo contrario. Dicen que la puerta se abrió, y que lo que hay del otro lado sigue exigiendo oficio.
Fuentes
- DORA / Google Cloud (2025) — State of AI-assisted Software Development. Encuesta a ~5.000 profesionales + 100 h de datos cualitativos. → https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- METR (julio 2025) — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Ensayo controlado aleatorizado, 16 desarrolladores, 246 tareas. Becker, Rush, Barnes y Rein. ⚠ Marcado como histórico por sus autores; existe actualización posterior. → https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- GitClear (2025 y 2026) — AI Copilot Code Quality y The Maintainability Gap. Análisis de 211 millones de líneas modificadas (2020–2024) y serie extendida a 2026. → https://www.gitclear.com/ai_assistant_code_quality_2025_research
- Veracode (2025, act. 2026) — GenAI Code Security Report. Más de 100 LLM, 80 tareas, cuatro lenguajes. → https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
Todas las cifras de este artículo provienen de las fuentes enlazadas. Verifica cada una antes de citarla: los informes se actualizan y algunos datos ya tienen versiones más recientes.