Acelerar el desarrollo es la promesa que cualquier proveedor te vende en 2026. Cursor, Claude Code, Copilot: el código sale más rápido y las demos lucen mucho en las reuniones. Pero un estudio publicado este año con 151 desarrolladores plantea una pregunta que nadie quiere oír en la fase de preventa: ¿quién va a entender ese código dentro de seis meses?
- 📉 Mantenimiento, no velocidad: entre el 50 y el 80 % del coste de un software se decide después de la entrega, no durante el desarrollo.
- ⚠️ El cuello de botella cambia de sitio: escribir sale más barato, verificar sale más caro que antes.
- 📊 DORA sigue siendo la referencia: frecuencia de despliegue, plazo, tasa de fallos y tiempo de recuperación. Cuatro indicadores, nada de impresiones.
- 🎯 El filtro de verdad es humano: un proveedor que acelera sin disciplina de verificación construye deuda, no un producto.
El mito de la velocidad: por qué "escribir rápido" casi no significa nada
Un software no es caro de escribir, es caro de mantener vivo. Dave Farley, ingeniero de software y autor reconocido del canal Modern Software Engineering, lo recuerda con cifras que deberían calmar a los vendedores de velocidad: el mantenimiento supone entre tres y cuatro veces el coste del desarrollo inicial, y entre el 50 y el 80 % del coste total de propiedad de un sistema se genera después de su primera puesta en producción.
Farley es coautor de un estudio controlado y prerregistrado, realizado en 2026 con 151 desarrolladores (el 95 % con perfil experimentado), para medir el efecto real de la IA sobre la mantenibilidad posterior, no sobre la velocidad de tecleo. Es el matiz que se les escapa a la mayoría de los benchmarks de marketing: contar líneas escritas no es ingeniería de software, es mecanografía.
¿Por qué la velocidad de escritura es un mal indicador de éxito?
Porque solo mide el primer tercio del ciclo de vida de un proyecto. Un módulo generado en una hora que seis meses después exige tres semanas de depuración no ha acelerado nada: simplemente ha desplazado el coste en el tiempo, a menudo hacia un desarrollador que no escribió ni la primera línea.
Optimizar el número de funcionalidades entregadas a corto plazo es una apuesta absurda si nadie puede mantenerlas. Es justo la trampa en la que caen los directivos con prisa que eligen proveedor por una demo espectacular y no por sus indicadores de mantenibilidad.
Lo que la IA cambia de verdad en el desarrollo, y lo que no cambia
La IA no elimina el coste del desarrollo de software, lo traslada. Es la tesis que defiende Ralf Klemmer, consultor que lleva 20 años acompañando a empresas como United Internet o Pro7 Sat 1, en su vídeo KI verändert die Softwareentwicklung: la pregunta ya no es "a qué velocidad puedes construir", sino "¿sabes siquiera qué hay que construir?".
Según un estudio recogido en la revista Science y citado por el canal Neurawork, cerca de tres cuartas partes del nuevo código que se produce en Google pasarían hoy por asistencia de IA. El razonamiento seductor que se deriva de ello, "software más rápido, luego más barato", es un error de cálculo. El precio no desaparece, simplemente cambia de partida: menos tiempo escribiendo, más tiempo verificando.
¿Cómo se convierte la validación en la competencia verdaderamente escasa?
Antes, cada línea de código costaba tiempo de escritura. Hoy, según Klemmer, la verificación se ha convertido en "el nuevo paso obligado". Un desarrollador senior que cree que su valor está en escribir mejor código que la IA se equivoca de batalla: su valor está en saber juzgar si lo que se ha construido tenía motivos para construirse.
Es precisamente la tesis que defiendo en GoLive Software desde hace varios años: producir código con IA no equivale a saber construir un producto de verdad. Alguien sin formación de ingeniero puede generar fragmentos de código que funcionan, pero no sabe gestionar la arquitectura, la seguridad, la deuda técnica ni los casos límite que nunca aparecen en una demo. El vibe coding es una herramienta excelente para prototipar. Es una herramienta peligrosa para construir un producto serio sin supervisión técnica, y ahí es exactamente donde se juega la elección de un buen proveedor.
DORA: los cuatro indicadores que separan una aceleración real de un espejismo
La única forma de comprobar objetivamente si un proveedor acelera tu desarrollo son los cuatro indicadores DORA (DevOps Research and Assessment), un programa impulsado por Google para estudiar qué distingue a los equipos de desarrollo de alto rendimiento del resto, como resume el canal Sleuth TV. Estos indicadores no miden a desarrolladores, miden un sistema.
| Indicador DORA | Qué mide | Señal de alerta que conviene preguntar en la reunión |
|---|---|---|
| Frecuencia de despliegue | Cuántas veces se entrega en producción | Menos de un despliegue por semana en un proyecto activo |
| Plazo de entrega | Tiempo entre una petición y su paso a producción | Más de 2 semanas para una funcionalidad sencilla |
| Tasa de fallos en los cambios | Porcentaje de despliegues que rompen producción | Por encima del 15 % sin un plan de corrección documentado |
| Tiempo medio de recuperación | Rapidez para volver a la normalidad tras un incidente | Ningún procedimiento escrito, respuesta tipo "lo vamos viendo caso por caso" |
FUENTE: DevOps Research and Assessment (Google), síntesis de Sleuth TV · ACT. 09/2026
¿Cuándo una frecuencia de despliegue alta es una señal real de calidad?
Hay una creencia muy arraigada según la cual desplegar más a menudo aumenta el riesgo. Es al revés: cuanto más pequeños y frecuentes son los cambios, mejor se entiende cada uno y menos errores se acumulan en silencio. Un proveedor que despliega una vez al mes no es más prudente, simplemente tiene menos herramientas para entregar con confianza.
Pídele a cualquier proveedor tecnológico que te enseñe su frecuencia de despliegue real en un proyecto comparable. La respuesta, o la falta de ella, dice más que una hora de discurso comercial.
El riesgo real: cuando un proveedor (o una IA) produce rápido, pero mal
Un hilo en r/developpeurs cuenta la historia de un desarrollador junior al que su equipo tuvo que desenganchar de la IA durante varios meses tras comprobar que "usaba demasiado la IA sin aprender ni entender de verdad lo que hacía". El autor del post, que también lleva 4 o 5 meses usando IA, describe un síntoma revelador: siente que se ha convertido en "lead dev de la IA el 70 %" de su tiempo y ha perdido la motivación para aprender a fondo lenguajes como Rust o Go.
Este testimonio coincide con un estudio comentado en r/AIBubble, realizado por Faros.ai (empresa que vende telemetría de desarrollo de software) sobre 22.000 desarrolladores repartidos en 4.000 equipos: documenta mejoras de rendimiento difusas, obtenidas a costa de un peaje enorme en la calidad del producto entregado. Un segundo estudio, menos sólido pero convergente, del National Bureau of Economic Research, apunta en la misma dirección en proyectos open source públicos.
Un producto generado a toda prisa sin control técnico suele costar más de reparar que de construir bien desde el principio. Es exactamente el mecanismo que describen en detalle estas señales de que un proveedor te está vendiendo humo: velocidad exhibida en la demo y silencio absoluto sobre quién arregla las cosas cuando se rompen en producción.
¿Hay que desconfiar de un proveedor que promete una entrega "ultrarrápida" gracias a la IA?
Sí, si la promesa de velocidad no va acompañada de una promesa de verificación. Un proveedor serio te hablará de sus tests automatizados, su revisión de código y su gestión de la deuda técnica tanto como de su velocidad de entrega. Si solo menciona la velocidad, está vendiendo un prototipo, no un producto mantenible. La pregunta que hay que hacer es la misma que he visto plantear sobre el código generado por IA en offshore y quién paga cuando falla en producción: ¿hay alguien en ese proveedor responsable del resultado, o solo del volumen de código producido?
La checklist antes de elegir quién va a acelerar tu desarrollo
Acelerar el desarrollo de tu producto no depende del número de desarrolladores movilizados ni de la potencia de su herramienta de IA. Depende de una disciplina de verificación medible, que cabe en cuatro indicadores DORA y un puñado de preguntas concretas.
Antes de firmar con un proveedor tecnológico o de encargar una auditoría informática, pregunta sin rodeos: ¿cuál es vuestra frecuencia de despliegue en un proyecto comparable al mío? ¿Cuánto tiempo pasa entre una petición y su paso a producción? ¿Qué porcentaje de vuestros despliegues falla y qué ocurre después? ¿Quién, en vuestro equipo, valida que una funcionalidad generada por IA tiene una arquitectura correcta, y no solo una demo que funciona?
En golivesoftware.co, en agosto de 2026, veo por ejemplo que el artículo sobre desarrollo de software offshore en Vietnam concentra casi todo el escaso tráfico orgánico del blog: 458 impresiones para 2 clics según Search Console. La misma paciencia vale para un artículo que para un proyecto de software: lo que acelera de verdad lleva tiempo construirlo, no anunciarlo. Como referencia externa sobre las tarifas diarias que se manejan en Francia, la federación profesional Syntec Numérique publica con regularidad benchmarks del sector.
Creo que un equipo senior pequeño, bien organizado y potenciado por la IA acelera realmente un desarrollo, siempre que la verificación siga en el centro del proceso. Es el modelo que defiendo en Vietnam con un equipo offshore y Claude Code: desarrolladores senior que usan la IA como multiplicador de criterio, no como sustituto de la arquitectura. La IA no mata este oficio, lo refuerza para quienes todavía saben verificar lo que produce.
Entonces, ¿de verdad hay que acelerar el desarrollo a cualquier precio? No. Hay que acelerar lo que se puede medir, con indicadores DORA y un proveedor que acepte enseñártelos, y frenar a propósito en la verificación, justo donde la mayoría de los equipos con prisa toman atajos. Un proveedor que se niega a darte su frecuencia de despliegue o su tasa de fallos en los cambios no acelera nada: solo aplaza la factura.
Preguntas frecuentes
¿Cuánto cuesta realmente un desarrollo "acelerado" por IA?
El coste de escritura baja, pero el de verificación sube, a menudo en proporciones similares. Según el estudio de Dave Farley con 151 desarrolladores, el mantenimiento sigue siendo la partida dominante del coste total, entre el 50 y el 80 % a lo largo de la vida de un proyecto. Un desarrollo presentado como rápido, sin datos de mantenibilidad posterior, no permite concluir que haya un ahorro real.
¿Qué indicadores DORA hay que pedirle a un proveedor tecnológico?
Los cuatro indicadores DORA son la frecuencia de despliegue, el plazo de entrega de los cambios, la tasa de fallos de los despliegues y el tiempo medio de recuperación tras un incidente. Un proveedor capaz de facilitarlos para un proyecto comparable al tuyo demuestra una disciplina operativa real, no solo una promesa comercial.
¿El vibe coding permite entregar más rápido sin riesgo?
El vibe coding, la práctica de generar código con IA sin una revisión técnica a fondo, es útil para prototipar una idea rápidamente. Se vuelve arriesgado en cuanto se trata de construir un producto para usuarios reales, porque deja de lado la arquitectura, la seguridad y la gestión de los casos límite que nunca se ven en una demo.
¿Puede un equipo offshore acelerar el desarrollo sin perder calidad?
Sí, siempre que el equipo esté formado por desarrolladores senior que usen la IA como herramienta de producción y no como sustituto de su criterio técnico. La ventaja de coste de un equipo offshore bien dirigido, combinada con la IA, permite a menudo entregar más rápido que un equipo local más caro sin sacrificar la mantenibilidad, siempre que la verificación siga siendo central en el proceso.
¿Conviene elegir un proveedor que promete una entrega ultrarrápida gracias a la IA?
Una promesa de velocidad sin mencionar tests, revisión de código ni gestión de la deuda técnica debería hacer saltar las alarmas. Un proveedor serio documenta su frecuencia de despliegue y su tasa de fallos en los cambios, no solo el plazo de entrega que anuncia en la preventa.
Fuentes
- We Studied 150 Developers Using AI (Here's What's Actually Changed...) , Modern Software Engineering
- Software Development with AI: What's Changing for Your Company Now , Neurawork
- KI verändert die Softwareentwicklung FÜR IMMER! , Ralf Klemmer
- DORA Metrics Explained , Sleuth TV
- Des devs ici qui ont arrêtés l'utilisation des IA après en avoir abusé ? , r/developpeurs
- LLMs Cause Software Development Teams to Underperform , r/AIBubble
- Accélérer le développement de logiciels , etas.com
- Comment accélérer le développement des applications d'entreprise avec une stratégie DevOps , informatiquenews.fr
