La velocidad que sí conviene: comprimir tiempos de MVP, análisis y revisión de código sin saltarse pasos

Tres historias que —vistas por separado— parecen anécdotas menores, pero que juntas cuentan algo que nos interesa mucho como estudio: la velocidad dejó de ser una excusa para saltarse el criterio.

Un análisis publicado esta semana muestra que los tiempos para construir un MVP se están comprimiendo de meses a semanas. Grab, la superapp del sudeste asiático, contó cómo liberó a su equipo de analistas del trabajo mecánico sin perder el control sobre las decisiones importantes. Y GitHub lanzó una función que, en el fondo, resuelve un problema muy simple: cómo revisar bien el código cuando se escribe más rápido de lo que se puede leer.

Tres frentes distintos —prototipado, operación de negocio y práctica de ingeniería— contando la misma idea: ir rápido y hacerlo bien no son objetivos opuestos, siempre que el equipo diseñe el proceso para que convivan.

Los MVP ya no se miden en meses, se miden en semanas

Un artículo publicado por European Business Review esta semana documenta algo que muchos equipos de producto vienen intuyendo: los ciclos de construcción de un primer producto viable se acortaron de forma dramática. Donde antes un MVP tradicional tomaba entre tres y seis meses, los equipos que integran herramientas de IA en cada etapa del proceso —no como un agregado al final, sino desde el descubrimiento— están completando el ciclo completo en seis a diez semanas. Los MVP de validación más simples, los que solo buscan confirmar si una idea tiene sentido antes de invertir en ella, se están lanzando en dos a cuatro semanas.

El desglose por etapa es el dato que más nos interesa. El descubrimiento, que solía tomar entre tres y seis semanas de entrevistas, investigación y definición de alcance, se está comprimiendo a una o dos semanas. El diseño pasó de dos-cuatro semanas a apenas una. La construcción, que era la etapa más larga —entre diez y veinte semanas—, ahora se resuelve en tres a seis. Los rangos de costo también bajaron: un MVP web que antes costaba entre 15.000 y 40.000 libras se sigue moviendo en ese rango, pero con mucho más alcance construido dentro del mismo presupuesto.

Nada de esto significa que el trabajo desapareció. Significa que se redistribuyó. Los equipos que reportan estas mejoras coinciden en algo que nosotros repetimos seguido: la IA reduce el trabajo repetitivo y de bajo criterio —escribir el boilerplate, generar variaciones de una pantalla, armar la primera versión de un endpoint—, pero no reemplaza la parte que realmente decide si un producto tiene sentido: entender el problema, priorizar qué construir primero y validar con usuarios reales si la solución resuelve algo que les importa.

Ahí está, para nosotros, la diferencia entre construir rápido y construir bien rápido. Un MVP que se arma en dos semanas pero nadie valida con usuarios reales no es una ventaja, es un riesgo con mejor marketing. La velocidad solo vale la pena cuando se usa para aprender más rápido, no para lanzar más rápido algo que nadie pidió.

Grab le devolvió tiempo a sus analistas, pero no las decisiones

La segunda historia de la semana viene de Grab, la superapp de transporte, delivery y pagos que opera en el sudeste asiático. Según reportó InfoQ esta semana, el equipo de analítica de Grab redujo la proporción de "tickets mecánicos" —solicitudes rutinarias de preparación de datos, alertas y reportes— del 44% al 30% de su carga de trabajo total entre febrero y junio de este año, gracias a un sistema de agentes construido internamente.

El sistema tiene nombre propio. Spartan es el agente que recibe solicitudes en lenguaje natural directamente desde Slack y las enruta usando más de 50 habilidades y 120 marcos de análisis distintos. Scarlet hace diagnóstico de causa raíz cuando un pipeline de datos falla, y puede corregir el problema o escalarlo si no puede resolverlo solo. Detrás de ambos hay un sistema de contexto —ContextIQ— que mantiene más de 5.000 tablas certificadas y 4.000 documentos de contexto organizacional, para que los agentes no trabajen a ciegas.

Los números de adopción son elocuentes: entre marzo y mayo, el porcentaje de solicitudes de métricas resueltas sin intervención humana subió de 53% a 67%; las extracciones de datos, de 63% a 90%; las consultas SQL, de 50% a 81%. El 85% de las solicitudes recibe una primera respuesta en menos de un minuto.

Pero el dato que más nos interesa no es de velocidad, es de gobierno. Grab diseñó un modelo de autonomía de cinco niveles para decidir qué puede hacer un agente solo y qué necesita revisión humana. En el nivel 3, un analista revisa los resultados antes de que se usen. En el nivel 4, supervisa puntos de control definidos. Recién en el nivel 5 el agente puede fijar objetivos y reglas de escalamiento propias. La definición de métricas, la interpretación causal y los supuestos de negocio siguen siendo, en todos los niveles, responsabilidad humana.

Maanas Prabhakar, líder de analítica en Grab, lo resumió con una pregunta que nos parece más honesta que cualquier anuncio triunfalista: "la pregunta difícil es qué hace un analista cuando un agente se encarga de la preparación de datos, del análisis y de todo lo demás". No es una pregunta retórica. Es exactamente el tipo de conversación que cualquier empresa debería tener antes de automatizar un proceso, no después.

Lo que más valoramos de este caso es que Grab no automatizó para reducir personas, sino para redistribuir su tiempo hacia preguntas que un agente no puede responder: qué significa realmente un cambio en una métrica, qué decisión de negocio hay detrás de un número. Automatizar sin hacerse esa pregunta primero es la forma más rápida de terminar con un sistema veloz que toma decisiones que nadie entiende del todo.

Cuando escribir código rápido no es el problema, sino revisarlo

La tercera historia es más pequeña en alcance, pero conecta directamente con las otras dos. GitHub llevó a vista previa pública su función de Stacked Pull Requests, según reportó InfoQ el 18 de agosto: una forma de dividir un cambio grande en una serie de pull requests más pequeños y dependientes entre sí, que se pueden revisar y fusionar de forma independiente, en lugar de esperar a que todo el cambio esté terminado para empezar a revisarlo.

La motivación detrás de la función es directa: la capacidad de generar código creció mucho más rápido que la capacidad de los equipos para revisarlo con cuidado. Cuando un cambio llega como un solo pull request gigante, el revisor pierde contexto, se cansa, y termina aprobando por agotamiento más que por convicción. Dividir ese mismo cambio en piezas lógicas más pequeñas reduce la carga cognitiva de cada revisión y permite que el trabajo siga avanzando sin bloquearse esperando una aprobación monolítica.

La práctica no es nueva —Meta la usa internamente desde hace años bajo el nombre de "stacked diffs", y empresas como Graphite construyeron plataformas enteras alrededor de esta idea—, pero que llegue como función nativa de GitHub confirma algo que ya intuíamos: la revisión humana de código sigue siendo, y probablemente seguirá siendo por mucho tiempo, el cuello de botella real de cualquier equipo que escribe software en serio. La investigación citada en el artículo es clara en ese punto: la integración exitosa de código generado con asistencia de IA sigue dependiendo, en la mayoría de los proyectos, de que una persona con experiencia valide cada contribución antes de que llegue a producción.

Lo que estas tres historias tienen en común

Ninguna de las tres es una noticia grande por sí sola. Pero leídas juntas, dibujan un patrón que nos parece más honesto que la promesa genérica de "hacer todo más rápido con IA": la velocidad real no viene de eliminar pasos, viene de rediseñar el proceso para que el criterio humano se aplique exactamente donde más vale la pena aplicarlo, y en ningún otro lugar.

Los equipos que están comprimiendo sus ciclos de MVP no dejaron de investigar ni de validar con usuarios: comprimieron el tiempo que toma construir la primera versión, no el tiempo que toma decidir qué construir. Grab no eliminó a sus analistas: les devolvió tiempo para las preguntas que un agente todavía no puede responder. Y GitHub no resolvió el problema de escribir menos código: resolvió el problema de poder revisarlo bien sin que la revisión se convierta en el freno de todo el equipo.

Esa es, en el fondo, la misma lógica que aplicamos cuando acompañamos a una empresa desde la idea hasta el producto en producción. Validar rápido no significa saltarse la validación: significa diseñar el experimento correcto para aprender lo esencial en el menor tiempo posible. Prototipar rápido no significa prototipar sin criterio: significa saber qué parte del producto vale la pena construir primero y cuál puede esperar. Y desarrollar rápido no significa desarrollar sin revisión: significa construir procesos de ingeniería —de código, de datos, de decisiones— que sostengan esa velocidad sin que se rompan la primera vez que algo sale mal.

Si tu equipo está por lanzar un primer MVP y no sabe por dónde empezar a comprimir el proceso sin perder rigor, o si ya está construyendo rápido pero sospecha que la validación y la revisión no están creciendo al mismo ritmo que la velocidad de desarrollo, conversemos. Preferimos ayudarte a diseñar ese equilibrio desde el principio, no a corregirlo después de que se convierta en un problema de producción.