Las afirmaciones sobre desarrollo asistido por IA suelen llegar en forma de multiplicadores. Dos o tres veces más rápido; diez para los más entusiastas. Tras haber aplicado esto en varios productos durante un tiempo, creemos que el marco del multiplicador es la razón por la que los números nunca sobreviven al contacto con un equipo real.
La forma más clara de decirlo: el coste de producir código cayó en un factor grande. El coste de sacar un producto no cayó en el mismo factor, porque producir código nunca fue el coste completo, y las partes que no se comprimieron son ahora proporcionalmente mayores.
Qué se aceleró de verdad
Las ganancias son reales y están concentradas en lugares concretos.
El trabajo de implementación convencional — una superficie CRUD, un flujo de formulario, una migración bien especificada, un cliente de API contra endpoints documentados — es dramáticamente más rápido. También lo es cualquier cosa donde la forma de la solución es conocida y el trabajo es volumen más que dificultad. El territorio desconocido también se beneficia, de otra manera: orientarse en una librería nueva o en una base de código ajena es mucho más rápido que leer documentación en frío.
El factor común es que en todos esos casos la respuesta está bien representada en lo que el modelo ha visto y la verificación es sencilla. Ambas condiciones importan. Donde falla cualquiera de las dos, las ganancias caen bruscamente.
Qué no se aceleró
Decidir qué construir no se aceleró. Tampoco acordar un modelo de datos que siga siendo correcto dentro de dos años, ni el trabajo de entender por qué un sistema existente se comporta como lo hace antes de cambiarlo.
La revisión no se aceleró en ningún sentido significativo, y esta es la que realmente gobierna el rendimiento. Si el código llega tres veces más rápido y la capacidad de revisión no cambia, la revisión se convierte en el cuello de botella casi de inmediato. Los equipos que reportan aceleraciones enormes normalmente o no han llegado aún a este punto o lo han resuelto revisando con menos cuidado, que es una decisión con un coste diferido e invisible.
Las operaciones tampoco se aceleraron. Incidencias, soporte, migraciones y la larga cola de mantener software vivo escalan con cuánto software existe y cuánta gente lo usa, no con la rapidez con que se escribió.
La medición que nos resultó útil
Dejamos de medir velocidad en cualquier forma, porque en este entorno mide sobre todo rapidez de generación, y la rapidez de generación ya no es escasa.
Dos cosas resultaron valer la pena. La primera es el tiempo de ciclo desde la decisión hasta producción: cuánto pasa entre comprometerse a construir algo y tenerlo funcionando para usuarios reales. Incluye revisión, pruebas y despliegue, así que captura la restricción en lugar de esquivarla, y es el número que efectivamente se movió para nosotros.
La segunda es la tasa de defectos que escapan: cuántos problemas llegan a producción por unidad de cambio publicado. Este es el contrapeso. Un equipo puede mejorar el tiempo de ciclo revisando menos, y el efecto es indistinguible de una mejora genuina durante aproximadamente un trimestre. Mirar ambas a la vez es lo que hace que cualquiera de las dos signifique algo.
Ninguna es novedosa. Ambas son anteriores a todo esto. En cierto modo ese es el punto: las métricas que sobrevivieron son las que ya medían lo correcto, y las que se rompieron son las que siempre fueron sustitutos del esfuerzo en lugar del resultado.
La contabilidad honesta
Para nosotros el efecto ha sido aproximadamente este: las funcionalidades convencionales y bien entendidas llegan sustancialmente más rápido, en algunos casos por un factor grande. El trabajo genuinamente nuevo, o que toca sistemas donde equivocarse sale caro, avanza algo más rápido pero no de forma dramática, porque ahí la restricción nunca fue teclear.
Promediado sobre una hoja de ruta real, eso da una mejora significativa y no una revolución. La parte revolucionaria está en otro sitio: no es que cada producto se volviera más rápido de construir, es que subió el número de productos que un equipo pequeño puede operar con responsabilidad. Esa es una afirmación distinta de un multiplicador de velocidad, y es la que sí defenderíamos.