El ahorro de costes es solo el primer nivel. La oportunidad estratégica está en hacer más, llegar antes y acertar mejor con el mismo talento.
El lema olímpico —más rápido, más alto, más fuerte— encaja sorprendentemente bien con el momento que vive el desarrollo de software. La inteligencia artificial ya no es una curiosidad de laboratorio ni un simple autocompletado: está entrando en análisis, diseño, codificación, pruebas, documentación, revisión, mantenimiento y operación. La cuestión importante ya no es si la IA puede ahorrar tiempo de desarrollo, sino qué hacemos con ese tiempo ahorrado cuando aparece.
Ahí está la diferencia entre una adopción táctica y una transformación real. Una empresa puede utilizar la IA como una tijera y convertir cada mejora de productividad en una reducción de coste de capacidad. O puede utilizarla como un multiplicador: mantener el talento, liberar capacidad y reinvertirla en más producto, más experimentación, menos deuda técnica y un time-to-market más corto. La segunda opción es más exigente, porque obliga a medir, priorizar y cambiar el sistema de trabajo. Pero también es la que puede crear una ventaja competitiva difícil de copiar.
| Idea central La IA no crea valor por producir más código. Crea valor cuando permite entregar antes resultados relevantes para clientes y negocio, con calidad y riesgo controlados. La unidad de medida debe pasar de “líneas de código” a “valor entregado”. |
1. El 50 % de productividad es una cifra tentadora… y una mala regla de gestión
Durante los últimos años se ha repetido una idea sencilla: “la IA puede aumentar la productividad del desarrollo en torno al 50 %”. Hay estudios que justifican cifras de ese orden en tareas concretas, pero convertirlas en una ley universal sería un error. En un experimento temprano con 95 desarrolladores, GitHub observó que el grupo con Copilot completó una tarea acotada un 55 % más rápido. McKinsey estimó ahorros de tiempo del 35–45 % en generación de código, del 20–30 % esn refactorización y del 45–50 % en documentación, con ganancias mucho menores en tareas de alta complejidad. [6][10]
La evidencia más reciente es más rica —y más incómoda para los titulares fáciles—. Un conjunto de tres experimentos de campo en Microsoft, Accenture y una compañía Fortune 100, con 4.867 desarrolladores, encontró un aumento medio del 26,08 % en tareas completadas al usar un asistente de código. En cambio, un ensayo de METR con desarrolladores open source muy experimentados, trabajando sobre repositorios que conocían bien, encontró que las herramientas disponibles a comienzos de 2025 les hicieron tardar un 19 % más. [9][12]
No son resultados incompatibles. Están midiendo personas, tareas, herramientas y contextos distintos. Y esa es precisamente la conclusión útil para una empresa: el impacto de la IA es heterogéneo. Puede ser enorme en boilerplate, documentación, tests, migraciones o búsqueda de información; moderado en desarrollo estándar; y nulo o incluso negativo en ciertos trabajos complejos, con mucho contexto tácito o con costes altos de verificación.
Por eso el business case no debería empezar con “vamos a ahorrar un 40 %”. Debería empezar con una hipótesis mucho más concreta: “en este flujo de valor, para estos equipos y estas tareas, esperamos reducir estos tiempos o este retrabajo; lo mediremos contra una línea base y reinvertiremos la capacidad liberada donde tenga mayor retorno”. Esa formulación es menos vistosa, pero muchísimo más gestionable.
2. Dos maneras de capturar el valor: IA como tijera o IA como multiplicador
La primera decisión no es tecnológica. Es económica y estratégica: ¿qué destino tendrá la productividad adicional?
| Enfoque | IA como tijera | IA como multiplicador |
| Objetivo primario | Reducir coste unitario y capacidad | Aumentar valor entregado con la capacidad existente |
| Decisión típica | “Si hacemos lo mismo más rápido, necesitamos menos personas” | “Si hacemos lo mismo más rápido, ¿qué más podemos construir o adelantar?” |
| Métrica dominante | Ahorro de coste | Time-to-market, alcance, calidad, ingresos, retrabajo evitado |
| Riesgo | Ahorrar hoy y perder capacidad de innovación mañana | Generar más trabajo del que testing, revisión u operaciones pueden absorber |
| Palanca clave | Licencias + reducción de estructura | Nuevo sistema de desarrollo, priorización y medición del valor |
Ambas estrategias pueden convivir. Es razonable capturar eficiencia en tareas de poco valor o evitar crecimiento innecesario de costes. El problema aparece cuando la reducción de plantilla se convierte en el único mecanismo para “materializar” el ROI. DORA, en su informe de 2026 sobre el ROI del desarrollo asistido por IA, recomienda explícitamente pensar en la capacidad recuperada como una oportunidad de reinversión y no limitar el análisis a reducción de headcount. [1]
En otras palabras: si una organización llevaba años diciendo que no podía abordar determinados productos, modernizaciones o mejoras porque “no había capacidad”, la IA puede cambiar esa frontera. Y ahí entran nuestros tres ejes: Citius Altius y Fortius.
3. Citius: la ventaja de llegar antes
En mercados digitales, la velocidad no es una cuestión estética. Un mes menos de desarrollo puede significar un mes más de ingresos, una respuesta más rápida a un competidor, una corrección temprana de un problema regulatorio o, simplemente, aprender antes si una idea funciona. El valor de la IA crece cuando reduce el tiempo transcurrido desde la idea hasta la evidencia de cliente.
Citius: acelerar un engranaje sirve de poco si el resto de la cadena sigue siendo el cuello de botella.
Pero aquí aparece otro error clásico: confundir “codificar más rápido” con “entregar más rápido”. Si el código se genera en la mitad de tiempo, pero las historias siguen esperando días para ser aclaradas, la revisión se congestiona, los tests tardan horas y producción tiene ventanas de despliegue rígidas, la mejora local se evapora. DORA ya observó en 2024 que un mayor uso de IA se asociaba con mejoras en documentación, calidad de código y velocidad de revisión, pero también con señales negativas en rendimiento de entrega. El aprendizaje es claro: hay que optimizar el sistema completo, no un solo puesto de trabajo. [4][5]
Por eso la IA debe aplicarse a lo largo del ciclo de desarrollo: discovery y análisis; especificación; diseño; coding; test; revisión; despliegue; observabilidad y mantenimiento. Cuando una fase acelera, el cuello de botella se mueve. El programa de adopción debe seguirlo. Si aparece en QA, se automatiza más QA. Si aparece en revisión, se reducen lotes, se mejora el pre-check automático y se refuerzan estándares. Si aparece en arquitectura, se mejora el acceso de la IA a documentación y contexto interno.
La velocidad también exige disciplina de tamaño. DORA destaca el trabajo en lotes pequeños como contrapeso a la inestabilidad que puede producir la generación masiva de código. Más capacidad de producir cambios debería conducir a cambios más pequeños, verificables y frecuentes, no a pull requests gigantes. [18]
Esta cuestión se aborda más adelante en el punto 6. Del “copilot para todos” a un nuevo sistema de desarrollo”
4. Altius: más alcance con el mismo presupuesto
En muchas áreas de tecnología el presupuesto se consume por capas. Primero hay que pagar lo necesario: regulación, mantenimiento correctivo, integraciones obligatorias, continuidad, ciberseguridad. Después llega el evolutivo: mejoras operativas, automatizaciones, cambios en ERP o CRM. Y solo con la capacidad restante aparece la innovación: nuevos canales, experiencias personalizadas, nuevos productos o experimentos que pueden fallar.
Altius: la oportunidad no es solo abaratar el backlog existente, sino ampliar la frontera de lo que cabe en el mismo presupuesto.
La IA puede elevar esa frontera de varias formas. Puede acelerar la generación de pruebas y documentación; ayudar a comprender bases de código legacy; proponer refactorizaciones; convertir especificaciones en esqueletos de implementación; asistir en migraciones; generar datos de prueba; resumir incidencias; o acelerar la investigación técnica. Ninguna de esas mejoras, por sí sola, garantiza que aparezcan nuevos productos. Lo que sí hacen es liberar minutos y horas en muchas etapas. Cuando esa capacidad se agrega y se protege, se transforma en espacio para iniciativas que antes no competían con éxito por presupuesto.
Aquí conviene evitar una trampa frecuente: llenar inmediatamente cada hueco con más backlog. “Más alcance” no significa producir más funcionalidades indiscriminadamente. DORA insiste en que la IA actúa como un amplificador: una organización con buen foco de cliente, datos internos accesibles, prácticas sólidas de versionado y trabajo en lotes pequeños puede amplificar resultados positivos; una organización atrapada en una “feature factory” puede simplemente producir más deprisa software de poco valor. [2][3][20]
El verdadero Altius, por tanto, es selectivo. La capacidad liberada debería dirigirse a aquello que antes quedaba fuera: reducción de deuda técnica con impacto, mejora de resiliencia, automatización de pruebas, experimentos de negocio, nuevos journeys digitales, personalización, mejoras de NPS o pequeños productos que permitan validar una oportunidad antes de comprometer una gran inversión.
5. Fortius: más robusto, más certero y con mejor retorno
En este caso vamos a traducir Fortius como más rentable y robusto con mayor calidad de producto terminado. La cuestión de la rentabilidad se aborda el punto 7. de este artículo Medir en serio: del “parece que vamos más rápido” al ROI”. Ahora nos enfocamos en la cuestión de robustez y calidad ya que la productividad que termina en retrabajo, incidencias o vulnerabilidades no es productividad: es deuda diferida.
Fortius: el objetivo no es disparar más flechas; es aumentar la probabilidad de acertar.
También aquí la evidencia obliga a abandonar simplificaciones. Un estudio de GitHub publicado en 2024, con 202 desarrolladores y evaluación mediante tests y revisiones ciegas, encontró mejoras estadísticamente significativas en funcionalidad, legibilidad, fiabilidad, mantenibilidad y concisión del código producido con Copilot; los desarrolladores con acceso a la herramienta tuvieron una probabilidad un 53,2 % mayor de superar los diez tests del ejercicio y el código fue un 5 % más probable de ser aprobado en revisión. [7]
Pero el dato no autoriza a “confiar y fusionar”. La encuesta de Stack Overflow de 2025 muestra precisamente la tensión del momento: el 84 % de los encuestados usa o planea usar herramientas de IA en el desarrollo y el 51 % de los desarrolladores profesionales las usa a diario, pero el 46 % desconfía de la precisión de sus resultados frente a un 33 % que confía. La frustración más citada es recibir soluciones “casi correctas”, seguida del tiempo extra necesario para depurar código generado por IA. [14]
La respuesta empresarial no es prohibir ni aceptar a ciegas. Es industrializar la verificación. Test automático, análisis estático, revisión de dependencias, escaneo de seguridad, políticas de secrets, observabilidad y revisión humana siguen siendo parte del proceso. El NIST SSDF ofrece un marco útil para integrar prácticas de desarrollo seguro en todo el ciclo de vida; la IA debe entrar en ese sistema de controles, no saltárselo. [17]
6. Del “copilot para todos” a un nuevo sistema de desarrollo
Entregar licencias a los equipos puede generar mejoras rápidas, pero rara vez captura todo el potencial. DORA 2025 resume bien el salto de madurez: la IA es un amplificador del sistema organizativo existente. Si el sistema es bueno, lo potencia; si está lleno de esperas, documentación obsoleta, arquitectura frágil y prioridades cambiantes, también puede amplificar esos problemas. [2]
Para pasar de experimentos aislados a una capacidad empresarial, propondría seis componentes de un “AI Development Operating Model”:
- Casos de uso y value streams prioritarios. No empezar por la herramienta, sino por los flujos donde tiempo, calidad o coste tienen impacto económico claro.
- Toolchain estándar y reglas de juego. Herramientas aprobadas, política de datos, propiedad intelectual, seguridad, modelos permitidos, trazabilidad y criterios de revisión.
- Contexto interno de calidad. Una IA genérica conoce programación; una IA conectada de forma segura a arquitectura, documentación, estándares, repositorios y APIs internas puede conocer cómo desarrolla tu empresa. DORA identifica el acceso de la IA a datos internos como una capacidad clave. [19]
- Capacitación y cambio de rol. El desarrollador pasa de producir cada línea a especificar, orquestar, revisar, probar y decidir. Saber pedir ayuda a la IA importa; saber detectar cuándo se equivoca importa más.
- Feedback loops rápidos. CI/CD, test automatizado, observabilidad, small batches y revisión temprana deben absorber el aumento de velocidad sin aumentar el riesgo.
- Gobierno del valor. La capacidad liberada debe asignarse explícitamente a innovación, deuda técnica, resiliencia o aceleración de iniciativas prioritarias. Si no se decide, el ahorro se dispersa en más WIP y más reuniones.
7. Medir en serio: del “parece que vamos más rápido” al ROI
La adopción de IA tiene un peligro adicional: la sensación de productividad puede no coincidir con la productividad real. El estudio de METR es un recordatorio contundente: los desarrolladores esperaban ser un 24 % más rápidos y, después de trabajar con IA, seguían creyendo que habían sido un 20 % más rápidos, aunque el tiempo observado había aumentado un 19 %. [12]
Por eso un programa de desarrollo necesita disponer
Business case que justifique el ROI en términos de indicadores numéricos (Fase de Exploración)
Sistema de medición antes de escalar.
- En el caso de Negocio se requiere una solución básica de medida de los indicadores.
- En el caso de la productividad del desarrollador conviene combinar varios niveles, porque la productividad del desarrollador no cabe en una sola métrica. El marco SPACE y la literatura DevEx advierten precisamente contra medir productividad con un indicador aislado como commits, líneas de código o tickets cerrados. [15][16]
| Nivel | Qué medir | Ejemplos |
| Adopción | Si la capacidad se usa realmente | Usuarios activos, frecuencia de uso, aceptación de sugerencias, casos de uso por fase |
| Experiencia y flujo | Si reduce fricción cognitiva | Tiempo buscando información, satisfacción, flow, espera por revisiones, onboarding |
| Entrega | Si llega antes a producción | Lead time, frecuencia de despliegue, tiempo de ciclo, throughput |
| Calidad y estabilidad | Si acelerar empeora o mejora el resultado | Change fail rate, defectos, rollback, MTTR, cobertura de test, vulnerabilidades |
| Negocio | Si la mejora técnica se convierte en valor | Time-to-market, ingresos adelantados, conversión, NPS, ahorro operativo, deuda evitada |
| Economía | Si compensa el coste total | Licencias, infraestructura/modelos, formación, plataforma, control, tiempo de verificación |
El ROI, además, debe distinguir capacidad económica de ahorro contable. Si un equipo ahorra 1.000 horas al año y esas horas se reinvierten en construir producto, la empresa ha ganado capacidad; no ha reducido automáticamente 1.000 horas de coste en la cuenta de resultados. La monetización correcta depende de lo que esa capacidad permita evitar, adelantar o producir.
| Una fórmula útil para el business case ROI de IA = (valor de capacidad reinvertida + ingresos adelantados + retrabajos evitados + costes evitados − coste total de adopción) / coste total de adopción. El “coste total” debe incluir licencias, consumo de modelos, integración, plataforma, formación, gobierno, seguridad y tiempo de verificación; no solo la licencia del asistente. |
La recomendación práctica es empezar con una línea base de 4–8 semanas, lanzar pilotos sobre flujos comparables, medir 8–12 semanas y revisar resultados por tipo de tarea y perfil. Después se escala lo que funcione y se abandona lo que no. La pregunta “¿cuánto mejora la IA?” es demasiado genérica; la pregunta útil es “¿dónde mejora, ¿cuánto, para quién y a cambio de qué?”.
8. ¿Qué haría mañana una empresa que quiera tomárselo en serio?
Un programa ambicioso no necesita empezar con una gran transformación corporativa. Puede comenzar de forma muy concreta:
- Seleccionar 2–3 value streams con volumen suficiente y métricas disponibles.
- Definir una línea base: tiempo de ciclo, calidad, retrabajo, coste, satisfacción de desarrolladores y resultado de negocio.
- Elegir 5–8 casos de uso recurrentes de IA a lo largo del SDLC, no solo generación de código.
- Establecer un estándar de herramientas, seguridad, datos y revisión humana.
- Formar a los equipos en prompting, context engineering, testing de outputs y patrones de trabajo asistido.
- Automatizar gates de calidad para que el aumento de output no desborde la revisión.
- Medir semanalmente adopción y fricciones; mensualmente resultados de entrega; trimestralmente impacto económico.
- Crear un mecanismo explícito para reinvertir capacidad en innovación, deuda técnica o aceleración del portfolio.
Este último punto es el que suele separar un programa transformador de un simple rollout de licencias. Si la capacidad liberada no tiene un destino estratégico, se pierde. Si se captura, la IA deja de ser una herramienta individual y se convierte en una palanca de portfolio.
Conclusión: el ahorro no es la meta; es el combustible
La IA ya ha demostrado que puede acelerar muchas tareas del desarrollo de software, pero no existe un porcentaje mágico aplicable a todos los equipos. Los resultados observados van desde mejoras muy relevantes hasta ralentizaciones en contextos concretos. La madurez consiste precisamente en dejar de discutir una cifra genérica y construir evidencia propia.
La oportunidad más interesante tampoco es “hacer lo mismo con menos”. Es utilizar la capacidad adicional para mover tres fronteras a la vez: más alcance donde antes no llegaba el presupuesto; más velocidad desde la idea hasta el cliente; y más robustez económica y técnica mediante mejores pruebas, menor retrabajo y decisiones más informadas.
Escenario conceptual del artículo original. Las cifras del gráfico (30 % de alcance, 33 % antes y +5 % ROI) deben tratarse como ilustrativas, no como un benchmark universal. Cada empresa debería sustituirlas por los resultados de su propio business case y sistema de medición.
Así que la pregunta estratégica no es si la IA permitirá ahorrar costes de desarrollo. Eso, en muchos casos, ocurrirá incluso en nuestras corporaciones más arcaicas y antediluvianas. La pregunta es qué hará la empresa con ese ahorro: ¿reducirá su capacidad de construir o la convertirá en una ventaja para llegar más lejos, más rápido y con mayor precisión?
Fuentes y lecturas recomendadas
La evidencia disponible evoluciona rápido. Se han priorizado fuentes primarias, investigación académica y estudios con metodología explícita. Cuando una fuente procede de un proveedor de herramientas, conviene interpretarla junto con estudios independientes y con datos internos de la propia organización.
[1] DORA / Google Cloud (2026). ROI of AI-assisted Software Development report. https://dora.dev/ai/roi/report/
[2] DORA / Google Cloud (2025). State of AI-assisted Software Development. https://dora.dev/research/2025/dora-report/
[3] DORA / Google Cloud (2025). DORA AI Capabilities Model. https://dora.dev/ai/capabilities-model/report/
[4] DORA / Google Cloud (2024). Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/2024-dora-accelerate-state-of-devops-report.pdf
[5] Google Cloud (2024). Announcing the 2024 DORA report. https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report
[6] GitHub (2022). Research: quantifying GitHub Copilot’s impact on developer productivity and happiness. https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/
[7] GitHub (2024, actualizado 2025). Does GitHub Copilot improve code quality? Here’s what the data says. https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/
[8] GitHub (2024). Quantifying GitHub Copilot’s impact in the enterprise with Accenture. https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/
[9] Cui, Z. et al. / Microsoft Research (2025). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/
[10] McKinsey & Company (2023). The economic potential of generative AI: The next productivity frontier. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier
[11] McKinsey & Company (2023). A coding boost from AI. https://www.mckinsey.com/featured-insights/charts/a-coding-boost-from-ai
[12] METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[13] METR (2026). We are Changing our Developer Productivity Experiment Design. https://metr.org/blog/2026-02-24-uplift-update/
[14] Stack Overflow (2025). Developer Survey 2025 — AI. https://survey.stackoverflow.co/2025/ai
[15] Forsgren, N. et al. (2021). The SPACE of Developer Productivity. ACM Queue. https://doi.org/10.1145/3454122.3454124
[16] Noda, A.; Storey, M.-A.; Forsgren, N.; Greiler, M. (2023). DevEx: What Actually Drives Productivity? Communications of the ACM. https://doi.org/10.1145/3610285
[17] NIST (2022). Secure Software Development Framework (SSDF) Version 1.1 — SP 800-218. https://csrc.nist.gov/pubs/sp/800/218/final
[18] DORA. Working in small batches. https://dora.dev/capabilities/working-in-small-batches/
[19] DORA. AI-accessible internal data. https://dora.dev/capabilities/ai-accessible-internal-data/
[20] DORA. User-centric focus. https://dora.dev/capabilities/user-centric-focus/
Nota editorial sobre las cifras
Las cifras cuantitativas del texto se presentan con su contexto metodológico y no deben interpretarse como una promesa de productividad aplicable a cualquier organización. En especial, los porcentajes incluidos en la imagen final se conservan por formar parte del artículo original, pero se han etiquetado como escenario conceptual. Para publicación externa, conviene reemplazarlos por datos propios o mantener explícitamente su carácter ilustrativo.