Una agencia analizó 4 910 presupuestos: ahora para la autenticación se presupuestan 2,2 veces menos horas

Cuando los CEO dicen que la IA escribe el 20%, el 30% o incluso el 90% del código, al cliente le queda una sola pregunta: ¿cuánto cuesta ahora una aplicación? Serguéi Nikonenko, director de una agencia de desarrollo móvil y web, decidió responderla en horas y rublos. Usó datos internos: presupuestos, registros de tiempo de Jira y commits de GitLab. No tuvo en cuenta el porcentaje de código generado.

Qué mostraron los presupuestos

El archivo contiene 4 910 presupuestos, pero pocos sirvieron para comparar: hacen falta documentos con la misma estructura. La autenticación se pudo contrastar en 12 presupuestos de 2025 y en 19 de 2026. La mediana de horas presupuestadas bajó de 124 a 56, es decir, 2,2 veces. También se redujo la dispersión: el 50% central de las estimaciones iba de 64 a 178 horas y ahora va de 24 a 70.

El precio de la hora cambió de forma más modesta. En siete presupuestos de cada año, la tarifa mediana de desarrollo bajó de 3 900 a 3 600 ₽, alrededor de un 8%. El autor no multiplica las dos medianas para obtener el precio de una funcionalidad: las horas y las tarifas provienen de muestras distintas, y para ese cálculo harían falta pares de los mismos presupuestos.

En la práctica, esto significa que ya es hora de revisar las tareas conocidas en las plantillas de presupuestos. Pero no se puede fijar en la plantilla un mínimo de 12 horas para la autenticación: bajo un mismo nombre de épica se esconden implementaciones distintas en cada producto.

Jira y GitLab: donde las cifras son más escurridizas

Con los datos reales la cosa se complica. Ajustarse al presupuesto, por sí solo, dice poco. Una aplicación móvil con panel de administración cumplió el presupuesto al 100% (1 359 de 1 360 horas). Un producto de desarrollo personal con IA llegó al 101% (520 de 515), aunque el proyecto sigue en marcha. Pero ya se estimó contando con agentes: el ahorro esperado pudo restarse de antemano, y el 101% no demuestra si la IA ayudó o no. Un proyecto con ampliación de alcance llegó al 182%, pero acumula 23 reestimaciones, y para la comparación conviene tomar el presupuesto inicial.

Hay otro problema de registro: en el servicio de expediciones, Jira recogía 311 horas, mientras que unas 120 horas de trabajo no llegaron al tracker. El autor las añadió de forma estimada. Sin esa corrección, el ahorro habría lucido mejor, pero el cálculo habría sido peor.

GitLab sirve para ver la participación de los agentes a través del trailer Co-Authored-By: Claude en el mensaje del commit. En el sitio de cosmética, el 92% de 802 commits lleva la marca de coautoría de la IA, y los hizo un solo desarrollador en 37 días laborables. En la aplicación móvil el cuadro es más revelador: hasta junio de 2026 no hay marcas, y en otoño aparecen en casi todos los commits.

Aun así, el trailer solo indica una coautoría declarada. No permite saber cuántas líneas escribió la IA ni cuántas horas ahorró. Y si un desarrollador usó IA pero no puso la marca, su trabajo queda fuera de la imagen.

Por eso los proyectos sin trailers no pueden considerarse desarrollo sin IA.

Coeficientes finales y sus límites

El resultado principal es este: se divide el presupuesto entre las horas reales. En el sitio de cosmética sale alrededor de 2,5× (594 horas de presupuesto frente a 240 reales). Pero 594 es el 80% de las 742 horas iniciales, y ese 80% de avance lo indicó el dueño del proyecto; no hay una verificación independiente basada en las tareas cerradas. En el servicio de expediciones, 1 627 horas de presupuesto frente a unas 431 reales dan alrededor de 3,8×. En sus conclusiones, el autor redondeó con cautela a 3×; es una decisión suya, no un límite estadístico.

Él mismo enumera las limitaciones:

• Los proyectos no se asignaron al azar entre trabajo con agentes y sin ellos.
• Solo hay dos casos AI-first comparables con presupuestos antiguos. Ambos son web, con Next.js y Nest.js.
• Se excluyó a los project managers, así que son horas de desarrollo, no el coste total.
• No se compararon los plazos de entrega en calendario.

También hay un contraargumento. En un experimento aleatorizado de METR, desarrolladores con experiencia que usaron herramientas de IA en tareas conocidas de código abierto trabajaron un 19% más despacio. El autor no afirma haber refutado ese estudio: su tipo de comparación es distinto, y sus datos no explican por qué los resultados divergen.

Qué hacer con esto

Para los equipos que elaboran presupuestos, la conclusión es pragmática. Primero: revisen las normas de horas para tareas típicas como la autenticación y no arrastren automáticamente las cifras antiguas a los proyectos nuevos. Segundo: no prometan al cliente que todo será varias veces más barato, porque el precio de la hora se mueve mucho más despacio. Tercero: implanten un registro adecuado. Si parte del trabajo no llega al tracker, cualquier coeficiente de aceleración saldrá embellecido. Cuarto: no tomen la proporción de commits con marca de IA como medida de productividad. Es solo una huella en el historial del repositorio.

El estudio es honesto, porque muestra abiertamente sus puntos débiles. Para el sector resulta útil como ejemplo de cómo contrastar con datos propios las afirmaciones sobre una «aceleración de varias veces» sin hacer pasar una comparación con presupuestos por un experimento controlado.