Construir más rápido con IA no sirve si construimos lo equivocado

Imaginemos una escena. Un equipo enseña al comité un prototipo funcional que ha construido en un par de días con herramientas de IA, algo que hace un año habría llevado un sprint entero. Hay aplausos. Entonces alguien pregunta qué métrica tiene que mover ese prototipo para darlo por bueno. Silencio.

La escena es hipotética, pero es una estructura que hemos visto repetirse en grandes empresas de sectores muy distintos. Resume mejor que cualquier definición uno de los debates que está provocando la IA en desarrollo de software y producto: la IA está reduciendo drásticamente el coste de construir, pero construir más rápido no garantiza crear más valor.

El output se ha abaratado hasta un punto que nadie había presupuestado. El outcome sigue siendo difícil, porque depende de saber qué queremos cambiar, por qué merece la pena hacerlo y cómo sabremos si lo hemos conseguido.

IA en desarrollo de software: por qué la velocidad no era el problema

Durante años, la queja más repetida en muchos comités de dirección ha sido la misma: producto pide, tecnología no da abasto y el roadmap se atasca. Con ese diagnóstico, incorporar IA para desarrollar más rápido parece la decisión obvia.

Y hay datos que respaldan parte de esa expectativa.

El informe DORA 2025 de Google Cloud observa una relación positiva entre la adopción de IA, el throughput de entrega y el rendimiento del producto. Pero también hay matices.

En 2025, METR, un laboratorio de investigación independiente, estudió a desarrolladores experimentados trabajando sobre sus propios repositorios. En ese experimento, utilizando IA tardaron un 19% más en completar las tareas. Lo más llamativo es que, aun así, seguían creyendo que la IA les había hecho aproximadamente un 20% más rápidos.

La velocidad percibida y la velocidad real no siempre coinciden. Pero aceptemos el escenario más favorable: imaginemos que un equipo consigue entregar el doble. ¿Qué cambia entonces en el negocio? En nuestra experiencia, poco, si lo único que ha cambiado es la velocidad.

El backlog se vacía más rápido y se vuelve a llenar más rápido. Las features llegan antes a producción y nadie sabe si han servido. Se construyen más prototipos, pero no necesariamente mejores decisiones.

El verdadero problema era otro: nadie había definido, antes de construir, qué tenía que cambiar en el negocio para considerar que esa entrega había funcionado.

Output vs outcome: qué cambia cuando el código sale más rápido

Output es lo que entregamos: features, pantallas, integraciones, funcionalidades o prototipos.

Outcome es el cambio que esas entregas provocan: en el comportamiento de un cliente, en una operación o en una métrica de negocio.

Pero la distinción no es nueva.

Marty Cagan ya planteaba en 2014 esta diferencia entre equipos centrados en lanzar cosas y equipos centrados en conseguir impacto: el éxito no debería medirse únicamente por haber entregado una funcionalidad, sino por el resultado que conseguimos con ella.

Lo nuevo es la asimetría que introduce la IA. La IA en desarrollo de software cambia esta relación porque reduce de forma radical el coste de convertir una idea en algo funcional. Antes, el coste de construir funcionaba como un filtro involuntario. Si una feature necesitaba tres meses de trabajo, alguien tenía que defender por qué merecía esa inversión. Era un filtro imperfecto, pero existía.

Cuando un prototipo cuesta dos días, ese filtro prácticamente desaparece. Y las ideas débiles pueden llegar a producción con casi la misma facilidad que las buenas.

Desde la ingeniería, Yuval Yeret ha descrito un fenómeno parecido: la IA puede aumentar la capacidad de producir código sin aumentar al mismo ritmo la atención, el contexto o el criterio disponibles para revisarlo y decidir sobre él.

La conclusión no es que programar con IA haya fallado. Es que la restricción se ha movido.

Nosotros vemos exactamente lo mismo desde producto: cuando construir deja de ser la principal limitación, el cuello de botella pasa a estar en las personas y sistemas que tienen que decidir qué merece construirse, qué evidencia necesitamos y cómo sabremos si ha funcionado.

El nuevo cuello de botella: criterio, evidencia y decisión

John Cutler lo explica desde otra perspectiva: la IA no corrige por sí sola el sistema de producto existente; tiende a amplificarlo.

Si una organización tomaba buenas decisiones con capacidad limitada, probablemente será capaz de aprovechar mejor una capacidad mayor.

Si decidía mal con capacidad escasa, ahora puede simplemente decidir mal más veces por trimestre.

En los equipos que acompañamos vemos que el nuevo cuello de botella aparece, sobre todo, en tres lugares.

Criterio

Cuando la capacidad de construir aumenta, la pregunta deja de ser: “¿Podemos hacerlo?” y pasa a ser: “¿Deberíamos hacerlo?”

Responder exige disponer de una estrategia de producto que permita contrastar cada idea con algo.

Y ahí aparece uno de los problemas habituales: en muchas organizaciones, la estrategia sigue siendo una lista de proyectos para el año, no un conjunto de criterios que permitan decidir qué hacer y qué no hacer.

Si todas las ideas caben en la estrategia, la estrategia no está ayudando a decidir.

Evidencia

Un prototipo construido en dos días sigue siendo una hipótesis. Que sea barato no significa que esté validado.

Parte del tiempo que la IA ahorra en construcción debería trasladarse a conseguir evidencia: hablar con usuarios reales, observar comportamientos, analizar datos de uso o contrastar alternativas antes de escalar.

De lo contrario, no estaremos acelerando el aprendizaje. Estaremos acelerando la fabricación de suposiciones.

Decisión

Alguien tiene que definir la métrica de éxito antes de construir, revisarla después y estar dispuesto a decidir si seguimos, iteramos o paramos. Y esa responsabilidad no siempre está clara. En muchos de los contextos empresariales con los que trabajamos, la decisión se diluye entre producto, negocio y tecnología.

Producto construye. Tecnología entrega. Negocio valida.

Pero nadie tiene explícitamente la responsabilidad de responder a una pregunta sencilla: ¿Ha funcionado?

Y lo que nadie tiene que decidir, normalmente tampoco termina midiéndose.

Cuando el sistema de gobierno sigue midiendo entregas

En muchas grandes empresas españolas con las que trabajamos vemos, además, una causa estructural. El presupuesto se aprueba una vez al año y frecuentemente se articula alrededor de proyectos. Eso hace que el sistema de gestión esté mucho mejor preparado para responder: “¿Está entregado?” que para responder: “¿Ha funcionado?”

Cuando la IA multiplica la capacidad de entrega, el sistema puede reaccionar aprobando más proyectos, porque esa es la unidad que sabe gestionar. La métrica de éxito no aparece porque nadie la solicita en el proceso de aprobación.

Que la IA haga visible esta limitación es una buena noticia. La mala noticia sería responder comprando únicamente más velocidad.

Cómo medir si la IA está generando valor, no solo output

Cuando hablamos de IA en desarrollo de software con nuestros clientes, lo primero que hacemos no tiene que ver con elegir herramientas. Antes de empezar a construir, intentamos que cada iniciativa tenga cuatro cosas claras.

1. Una métrica de éxito

Debe escribirse antes de la primera línea de código e incluir, siempre que sea posible, el punto de partida y el cambio que esperamos conseguir.

“Mejorar la experiencia” no es suficiente.

“Reducir el abandono durante el proceso de alta del 40% al 30% en ocho semanas” sí lo sería.

Las cifras son ilustrativas. Lo importante es que exista una definición observable de éxito.

2. Un umbral de evidencia proporcional al coste y al riesgo

No todas las decisiones necesitan el mismo nivel de validación. Si un prototipo cuesta dos días y es completamente reversible, unas pocas conversaciones con usuarios pueden ser suficientes para decidir si merece la pena seguir explorándolo.

Si la solución va a desplegarse para cien mil clientes, afecta a una operación crítica o resulta difícil de revertir, el nivel de evidencia necesario debería ser mucho mayor.

La velocidad que aporta la IA no debería reducir el rigor de la decisión. Debería permitirnos invertir más tiempo en conseguir evidencia.

3. Un dueño de la decisión

Alguien tiene que mirar la métrica en la fecha acordada y decidir.

• Seguir.
• Iterar.
• O parar.

No hablamos necesariamente de la persona que construye la solución ni de quien financia la iniciativa. Hablamos de quien tiene explícitamente la responsabilidad de evaluar el resultado. Cuando esa persona no existe, las iniciativas tienden a sobrevivir por inercia.

4. Un criterio de parada

También acordamos qué resultado haría que dejásemos de invertir en esa solución.

Es una pregunta incómoda: ¿Qué tendría que ocurrir para que retirásemos esta feature?

Si la respuesta es “nada”, probablemente no estamos ante una hipótesis. Puede tratarse de una obligación contractual, regulatoria, operativa o estratégica perfectamente legítima, pero debería gestionarse de otra forma.

Estas cuatro condiciones parecen sencillas. En la práctica son la parte difícil, porque obligan a escribir explícitamente muchas decisiones que antes permanecían implícitas. Y es precisamente ahí donde la IA puede aportar mucho más valor.

Puede ayudar a sintetizar entrevistas, analizar grandes volúmenes de feedback, explorar datos de uso, construir variantes para contrastar con clientes o reducir el coste de determinados experimentos.

Es decir, puede acelerar la obtención de evidencia, no únicamente la producción de output. El criterio y la decisión siguen siendo nuestros.

De usar IA para producir más a usar IA para aprender más rápido

Existe una diferencia importante entre estas dos preguntas:

¿Cómo podemos utilizar IA para construir esta solución más rápido?

y:

¿Cómo podemos utilizar IA para descubrir antes si esta solución merece ser construida?

La primera optimiza el output. La segunda optimiza el aprendizaje.

Probablemente necesitaremos las dos. Pero si solo hacemos la primera, corremos el riesgo de trasladar toda la productividad ganada a producir más inventario digital: más funcionalidades que mantener, más decisiones que revisar, más complejidad tecnológica y más cosas cuyo impacto nadie conoce. El verdadero reto de la IA en desarrollo de software no es producir más, sino aprender antes qué merece la pena producir.

El objetivo no debería ser simplemente que los equipos entreguen más. Debería ser que reduzcan más rápido la incertidumbre sobre qué merece la pena construir.

El filtro para tu próximo lunes

Si diriges producto o tecnología, hay una comprobación sencilla que puedes hacer esta semana sin cambiar ningún proceso. Coge las tres últimas features o prototipos que vuestros equipos hayan entregado con ayuda de IA. Y responded, para cada una, a dos preguntas:

• ¿Qué métrica tenía que mover?
• ¿Se movió?

Si podéis responder las dos preguntas en los tres casos, es una buena señal de que el aumento de throughput está conectado con resultados. Si podéis responderlas en uno o dos, probablemente ya podéis identificar dónde existe una cultura de outcome y dónde seguimos midiendo principalmente entregas.

Si no podéis responderlas en ninguno, quizá todavía no necesitéis más velocidad. Puede que la IA simplemente os haya enseñado dónde estaba el cuello de botella real.

La pregunta merece acompañar cada entrega, cada experimento y cada semana: ¿Qué tenía que cambiar y cambió?