Generar código con IA es fácil; crear impacto, no tanto

Disparar el impacto del desarrollo con IA

Tiempo de lectura: 7 minutos

Generar código con IA es fácil. Conseguir que ese código cree verdadero impacto, no tanto. La IA ha convertido en trivial lo que durante décadas fue el cuello de botella —escribir software— y, al hacerlo, ha movido el problema a otro sitio. Este artículo recoge la charla Disparar el impacto del desarrollo con IA: qué se rompe, qué deja de tener sentido y cómo reorientar un equipo hacia el impacto en lugar de hacia producir sin control.

El espejismo de la velocidad

"Ya tengo la feature lista en una tarde." Es verdad, y es justo el problema. Cuando producir deja de ser caro, el riesgo no es ir lento: es ir muy rápido en la dirección equivocada. El cuello de botella se ha movido del delivery a la gestión de la demanda: decidir qué merece la pena construir, enmarcar el problema y decir que no.

La fábrica de features, con esteroides

Hay un dato que lo resume. Un estudio de MIT Sloan (Demirer, Musolff & Yang, 2026) midió cómo, con herramientas de IA, el código generado por desarrollador se multiplicaba por diecisiete mientras los outcomes validados apenas se movían. Más output no es más valor; muchas veces es más ruido y más deuda.

¿Qué eslabón de la cadena lógica acelera la IA?

El modelo lógico de Seiden encadena Recursos → Actividades → Outputs → Outcomes → Impacto. La IA dispara los Outputs y nada más. Y aparece un desfase de dos retardos: del código a poder medir su efecto, y de ahí a contrastar que la estrategia se está cumpliendo. Generar es instantáneo; validar el impacto, no. Por eso, cuanto más rápido vas, más brújula necesitas.

La pregunta que debería responder cada entrega deja de ser "¿está hecho?" (código en producción) y pasa a ser "¿qué hemos aprendido o validado?".

IA agéntica: un espectro de autonomía

No hay una única "IA agéntica"; hay un espectro:

• Asistido (vibe): el humano conduce, la IA teclea. Ideal para explorar; riesgo de deuda técnica.
• Dirigido por specs: el humano escribe especificaciones y la IA genera código de producción. Más difícil de empezar, más fácil de mantener.
• Agentes autónomos: el agente escribe, prueba, corrige y commitea; el equipo revisa y aprueba. Máximo apalancamiento, máxima exigencia de validación.

A más autonomía, más apalancamiento — y más necesidad de límites claros y validación madura.

De estar en el bucle a estar sobre el bucle

Con agentes, la coordinación cambia de naturaleza. Hay dos modos:

• In the loop: el humano aprueba cada paso. Seguro, pero no escala: la persona se convierte en el cuello de botella.
• On the loop: el humano supervisa el proceso, fija los límites y revisa los resultados, interviniendo por excepción. Escala — siempre que la validación automática sea sólida.

Aquí el papel del arquitecto se vuelve central: pasa de escribir el código crítico a diseñar el sistema, escribir las especificaciones que producen código de calidad y ser dueño de la Definition of Done. La IA ejecuta; el arquitecto juzga.

¿Qué cambia en gobernanza?

Cuando construir cuesta casi nada, controlar cuánto se produce deja de tener sentido. Lo que hay que gobernar es qué se construye y qué efecto tiene:

• La Definition of Done sube: tests, seguridad, observabilidad.
• Trazabilidad: de cada entrega a la hipótesis y al outcome que perseguía.
• Decidir, y decir que no, es el capital más escaso.

Y algunas prácticas envejecen: estimar el esfuerzo de teclear código, la velocity como métrica de éxito, los ciclos largos para "dar tiempo a programar". Importan más, en cambio, las hipótesis falsables, los ciclos cortos con señal real y validar outcomes en lugar de outputs.

¿Por qué la velocidad no es lo mismo que el valor?

Ir rápido no es ir bien. Dos señales para no confundirlos: la velocidad sube el número de releases mientras los outcomes siguen planos; el valor confirma o descarta una hipótesis con datos a tiempo, y decide parar o pivotar. Si solo miras lo primero, vas a toda velocidad sin saber hacia dónde.

¿Cómo alinear equipo, producto y estrategia con OKR?

La pieza que cierra el círculo es el alineamiento. Los OKR conectan toda la cadena: la estrategia (el impacto que persigue el negocio) se traduce en un OKR de producto (el outcome que lo mueve), que se traduce en las metas de iteración del equipo (las apuestas que lo validan). El OKR no es un artefacto de planificación: es el filtro que evita ir muy rápido en la dirección equivocada — y el hilo que une cada commit con la estrategia.

Dispara el impacto, no el output

La IA ya produce. Lo escaso es decidir bien y validar rápido. El equipo que gana no es el que más código envía: es el que convierte ese código en impacto — y lo demuestra.

Tres cosas para esta semana: escribe el outcome antes que la feature; pon a alguien on the loop en lugar de aprobar cada paso; y mide impacto, no velocity, conectando cada entrega a un OKR.