Hay una idea cómoda circulando: los proyectos con IA son rápidos porque la IA escribe código muy rápido. Es cierta y es secundaria. Un desarrollador humano competente también escribe rápido la parte fácil.
Cuando llevamos un sistema a producción en menos de tres semanas, lo medimos con calma: la diferencia no estuvo en la velocidad de tecleo. Estuvo en lo que dejó de existir alrededor del tecleo.
A dónde se va el tiempo en un proyecto tradicional
Piensa en el último proyecto de software que viviste de cerca y pregúntate qué fracción del calendario fue escribir código. En proyectos con múltiples especialistas y proveedores, la escritura suele ser minoría. El resto es coordinación: conseguir que la persona correcta esté disponible, explicar el contexto por tercera vez, esperar la cotización del cambio, la reunión para revisar la minuta de la reunión anterior, el malentendido que se descubre dos semanas después de nacer.
Nada de eso es incompetencia. Es el costo natural de repartir un problema entre varias cabezas: cada frontera entre dos personas cobra peaje en tiempo, contexto y fidelidad. Los métodos de gestión de proyectos existen, en buena medida, para administrar ese peaje. No para eliminarlo, porque no se podía eliminar.
Qué cambia con un equipo de agentes
En nuestro proyecto, el ciclo decisión → tarea → implementación → revisión ocurría dentro de la misma sesión de trabajo. Una observación de arquitectura se convertía en tarea concreta en minutos. La tarea se implementaba, se probaba y regresaba para revisión el mismo día, muchas veces la misma hora. Si la propuesta no cumplía, se descartaba sin desgaste: un agente no necesita una reunión para aceptar que su enfoque se va a la basura, ni queda resentido para el siguiente sprint.
Las fronteras siguen existiendo (por diseño: roles separados, revisión cruzada, autoridad única por dominio), pero el peaje de cada frontera cayó de días a minutos. El contexto no se pierde en el traspaso porque vive escrito en el repositorio, no en la memoria de las personas. Y la disponibilidad dejó de ser un cuello de botella: el "especialista" no está en otra junta.
Ese es el hallazgo que nos parece honesto reportar: la velocidad no vino de acelerar el trabajo, vino de eliminar la espera entre trabajos. La mayor parte de un calendario de dieciocho meses no es trabajo; es fila.
El nuevo trabajo del Project Manager
Aquí viene la parte incómoda para quienes gestionamos proyectos: buena parte del oficio tradicional del PM administra la fila. Minutas, seguimiento de pendientes, cazar respuestas, coordinar agendas. Cuando la fila desaparece, ese trabajo no se vuelve más fácil: se vuelve innecesario.
Lo que no desaparece (y se vuelve el cuello de botella real) es la capacidad de decidir. Cuando la implementación tarda minutos, el sistema avanza a la velocidad a la que el humano al frente puede evaluar propuestas, detectar el hueco, y decir sí o no con fundamento. El PM deja de administrar tiempos ajenos y pasa a administrar el suyo: qué merece su atención, qué evidencia exige antes de aprobar, cuándo detener una línea de trabajo que "se ve bien" pero huele mal.
Dicho sin rodeos: el rol migra de coordinador a director técnico con comité de cambios. Quien disfrutaba el oficio por la coordinación tiene un problema; quien lo sufría por la coordinación acaba de recibir el mejor regalo de su carrera.
Los límites honestos
Primero: la fricción no muere, se muda. Ahora vive en la frontera humano-agente. Si la dirección es ambigua, el equipo de agentes produce basura con una eficiencia extraordinaria — más rápido que nunca se produjo basura en la historia de la ingeniería. La claridad de la especificación se vuelve el insumo más caro del proyecto.
Segundo: esto funcionó en un equipo donde una sola persona concentraba dirección, arquitectura y autorización. En organizaciones grandes, parte de la fricción de coordinación es entre humanos (legal, compras, seguridad, dirección), y esa no la elimina ningún agente. La ganancia real de cada organización depende de cuánta de su fricción era técnica y cuánta era política.
Tercero: comprimir el calendario comprime también el tiempo para arrepentirse. Cuando algo llegaba a producción en dieciocho meses, los errores de concepto tenían meses para ser descubiertos. A esta velocidad, los controles (revisión cruzada, ambientes de prueba, autorización humana) no son burocracia: son los frenos de un vehículo que ahora sí corre.
Conclusión práctica
Si estás evaluando desarrollo asistido por IA, no calcules el beneficio como "código más rápido". Haz el otro cálculo: toma tu último proyecto y estima cuánto calendario fue espera, coordinación y retrabajo por malentendidos. Esa es la magnitud real en juego. Y luego pregúntate si tienes a la persona con el criterio para dirigir a esa velocidad — porque la fila ya no va a esconder las decisiones lentas.