Saltar al contenido
SwankyForge
SwankyForge
Todos los insights
Artículo10 min de lectura

La IA abarató escribir código. No abarató por sí sola los proyectos de software.

Las mediciones controladas muestran aceleraciones modestas o negativas con herramientas de IA para programar, y programar ocupa una parte minoritaria del proyecto, así que un descuento honesto por IA es pequeño y se puede ubicar fase por fase.

En julio de 2025 la organización de investigación sin ánimo de lucro METR publicó un ensayo aleatorizado de herramientas de IA para programar sobre trabajo real. Dieciséis desarrolladores open source con experiencia completaron 246 tareas en sus propios repositorios, y cada tarea se asignó al azar a «IA permitida» o «IA no permitida». Con IA, las tareas tardaron un 19% más. Antes del estudio, esos mismos desarrolladores esperaban que la IA los acelerara un 24%. Después, seguían creyendo que los había hecho alrededor de un 20% más rápidos.

Esa brecha entre la velocidad percibida y la medida es lo útil para quien compra software. Los proveedores ya anuncian entregas aceleradas por IA y lo incluyen en el precio. Parte del ahorro es real. La mayor parte de la promesa trata sobre teclear, aplicada a un presupuesto que en su mayoría no es teclear.

Esta nota cubre qué dicen los datos de 2025, a dónde van las horas en un proyecto de machine learning y qué preguntar a un proveedor que ofrece un descuento por IA.

Qué dicen los datos de 2025

Cuatro fuentes, cuatro métodos. Ninguna respalda la idea de que un proyecto cueste la mitad porque el código se escribió con un asistente.

Fuente Método Resultado
METR, julio de 2025 Ensayo aleatorizado: 16 desarrolladores, 246 tareas, repositorios con una media de más de 22k estrellas y más de 1M de líneas de código 19% más lentos con IA; los desarrolladores creían ser alrededor de un 20% más rápidos
Stack Overflow Developer Survey, julio de 2025 Encuesta, 26k–34k respuestas por pregunta El 84% usa o planea usar herramientas de IA; el 46% desconfía de su exactitud, el 33% confía; el 66% señala «casi bien, pero no del todo» como la principal frustración
Informe DORA de Google, septiembre de 2025 Encuesta a casi 5.000 profesionales de tecnología El 90% usa IA en el trabajo; la adopción de IA se asocia a mayor throughput de entrega y, aun así, a menor estabilidad de entrega
Bain Technology Report, septiembre de 2025 Investigación sectorial Los equipos con asistentes ven mejoras de productividad del 10–15%; escribir y probar código es el 25–35% del tiempo desde la idea hasta el lanzamiento

El resultado de METR tiene límites que sus autores declaran sin rodeos: una muestra pequeña, desarrolladores con experiencia sobre grandes bases de código que ya conocían, y herramientas de principios de 2025 (Cursor Pro con Claude 3.5 y 3.7 Sonnet). No demuestra que la IA ralentice a todo el mundo. Demuestra dos cosas más acotadas. Las aceleraciones autodeclaradas no son evidencia. Y en código maduro y complejo, el tiempo dedicado a escribir prompts, esperar, revisar y corregir puede anular el tiempo ahorrado al escribir.

Las encuestas apuntan en la misma dirección desde otro ángulo. El uso es rutinario: el 51% de los desarrolladores profesionales de la encuesta de Stack Overflow usa herramientas de IA a diario, y los encuestados de DORA pasan una mediana de dos horas al día con ellas. La confianza no lo es: el 45% de los encuestados de Stack Overflow dice que depurar código generado por IA lleva más tiempo, y el 30% de los encuestados de DORA declara poca o ninguna confianza en el código generado por IA. La conclusión de DORA es que la IA amplifica lo que un equipo ya es. Los equipos sólidos van más rápido. Los equipos con tests débiles y feedback lento despliegan más cambios y rompen más de ellos.

Por qué teclear más barato no significa un proyecto más barato

Las dos cifras de Bain bastan para ver el techo. Si escribir y probar código es el 30% del tiempo desde la idea hasta el lanzamiento, y un asistente hace esa parte un 30% más rápida, el proyecto entero va un 9% más rápido: 0,30 × 0,30 = 0,09. Si el código fuera gratis e instantáneo, el otro 65–75% del trabajo seguiría ahí. Los ingenieros lo conocen como la ley de Amdahl: acelerar una etapa de un pipeline está limitado por la fracción de tiempo que ocupa esa etapa.

El resto de un proyecto es especificación, trabajo con datos, integración, revisión, testing, evaluación, despliegue y operación. Cada una tiene su propio motivo para no reducirse al mismo ritmo.

  • La especificación es una conversación con las personas dueñas del problema. Un asistente puede redactar el documento. No puede decidir que la métrica es el margen y no los ingresos.
  • El trabajo con datos consiste sobre todo en averiguar qué significa una columna, quién es responsable de la tabla y por qué hay filas duplicadas. Escribir el SQL nunca fue la parte lenta.
  • El tiempo de integración se va en la API de otro equipo, credenciales, límites de peticiones y ventanas de release.
  • La revisión se vuelve más pesada. Más código generado al día significa más código que leer al día, y el código casi correcto es el más caro de revisar porque parece terminado.
  • La evaluación y la operación siguen un calendario. Hay que esperar una semana de tráfico, un cierre de mes o a que un grupo de control acumule suficientes datos.

El hallazgo de DORA sobre estabilidad es la versión medida del punto sobre la revisión. Los equipos despliegan más cambios y, sin tests automáticos sólidos y ciclos de feedback rápidos, una mayor parte de esos cambios falla.

A dónde van las horas en un proyecto de ML

La tabla siguiente es ilustrativa. Es nuestro reparto aproximado para un proyecto de machine learning de tamaño medio, como un sistema de recomendación o de previsión conectado a un producto existente, junto con nuestras suposiciones sobre cuánto ahorra la asistencia de IA en cada fase. Los porcentajes son opiniones de planificación, no mediciones. Sustitúyalos por los suyos y rehaga la suma.

Fase Proporción de horas Horas de 600 Ahorro supuesto por IA Horas ahorradas
Discovery: métrica, baseline, especificación 10% 60 0% 0
Acceso a datos, limpieza, pipelines de features 25% 150 15% 22,5
Modelado y experimentos 15% 90 20% 18
Integración con sus sistemas 15% 90 20% 18
Testing, evaluación, revisión de código 15% 90 0% 0
Despliegue, monitorización, rollback 10% 60 10% 6
Demos, aceptación, traspaso 10% 60 0% 0
Total 100% 600 64,5, alrededor del 11%

El razonamiento detrás de cada fila:

  • Discovery no obtiene nada porque su resultado son decisiones, y las decisiones vienen del negocio.
  • El trabajo con datos obtiene un ahorro modesto. Los asistentes escriben consultas, parsers y validaciones rápido, pero la mayoría de las horas se van en esperar accesos y entender los datos.
  • El modelado y la integración obtienen el mayor ahorro porque contienen más código de patrón: bucles de entrenamiento, clientes de API, serialización, configuración.
  • Testing y revisión quedan en cero neto. Los asistentes escriben el andamiaje de tests rápido, y el código generado adicional añade tiempo de revisión. Los equipos con suites de tests sólidas pueden ganar aquí; los equipos sin ellas pueden perder.
  • El despliegue ahorra un poco en plantillas de configuración. Esperar a que un canary release recoja tráfico no se acorta.

Con nuestra tarifa publicada de ingeniero de ML de 50 € por hora, 600 horas son 30.000 € y 64,5 horas son unos 3.200 €. Ese es el orden de magnitud de un descuento honesto por IA en un proyecto de esta forma: real, útil, y muy lejos de la mitad. Además cae dentro del rango del 10–15% de Bain, lo cual es una comprobación de cordura y no una prueba.

La otra cifra de Bain es la más interesante. Las empresas que rediseñaron todo el proceso en torno a la IA, en lugar de limitarse a repartir asistentes, declararon mejoras del 25–30%. Ese ahorro viene de cambiar lo que ocurre entre las líneas de código: cómo se escriben las especificaciones, cómo funciona la revisión, cómo se prueban los releases. Es un cambio de proceso, y cuesta esfuerzo antes de rendir. Bain también señala que tres de cada cuatro empresas dicen que lograr que la gente cambie su forma de trabajar es la parte más difícil.

Cómo cambió el trabajo del desarrollador

El trabajo pasó de escribir a especificar y comprobar. Un desarrollador con un asistente dedica menos tiempo a la primera versión y más tiempo a tres cosas.

  1. Instrucciones precisas. El asistente hace lo que dice la especificación, así que una especificación vaga ahora produce más rápido código plausible pero incorrecto.
  2. Leer y corregir el resultado. Aquí vive la frustración del «casi bien». El código incorrecto que falla de forma evidente es barato. El código que pasa el test obvio y falla en el caso límite es caro.
  3. Las comprobaciones que hacen segura la velocidad. Tests, conjuntos de evaluación, comprobación de tipos, despliegues escalonados.

En el trabajo de machine learning el tercer punto es el que más pesa. Un cambio de modelo que parece correcto en un notebook puede empeorar una métrica de negocio en producción. Un asistente puede escribir el arnés de evaluación. No puede decidir qué debe contener el conjunto de evaluación, ni cuánto le cuesta al negocio una regresión.

Dónde aparece el ahorro

Nuestra visión, que es una opinión y no una medición: los asistentes recortan tiempo real en

  • prototipos y análisis desechables, donde casi correcto basta para aprender algo;
  • código con un patrón claro: clientes de API, clases de datos, configuración, migraciones de esquema;
  • librerías desconocidas, donde el asistente sustituye una hora de leer documentación;
  • primeros borradores de tests y documentación, que luego corrige una persona.

Ahorran poco en decisiones, esperas, coordinación y revisión. Un descuento por IA creíble debería ser coherente con ese reparto.

Qué preguntar a un proveedor que promete un descuento por IA

  • ¿Dónde exactamente recortó horas la IA? Pida la estimación por fase, con y sin asistencia. Un descuento que no se puede ubicar en una fase es un descuento comercial. No pasa nada, pero debería llamarse así.
  • ¿Quién revisa el código escrito por IA, y cómo? Pregunte si una persona revisa cada cambio, qué comprueba y si el tiempo de revisión está en la estimación.
  • ¿Cómo se mide la calidad? Tests en los caminos críticos, un conjunto de evaluación para el comportamiento del modelo, una tasa de fallos por cambio. Si la respuesta es que el código funciona, pregunte cómo lo saben.
  • ¿Qué pasa cuando el código generado falla en producción? La monitorización, el rollback y un responsable de guardia van en el plan, no en una solicitud de cambio posterior.
  • ¿Dónde vive el repositorio? Si el código está en la cuenta del proveedor hasta la factura final, no puede comprobar nada de lo anterior mientras todavía importa.

Cómo lo gestionamos

Nuestra tabla de tarifas está publicada por rol y por hora, así que cualquier estimación que demos se puede comprobar como horas por tarifa, fase por fase. Ve una demo funcional cada semana, el repositorio vive en su organización desde el primer día y cada hito se factura solo después de que lo acepte. Los rangos típicos de proyecto están publicados junto a la tabla de tarifas, y un teardown presupuesta por separado discovery, prueba de concepto y producción. Si la asistencia de IA acelera una fase, se nota en menos horas en la factura, no en una promesa en la propuesta.

Fuentes

¿Tiene un proceso que cuesta demasiado?

Cuéntenoslo. La primera llamada es gratuita y, si la IA no es la respuesta, se lo decimos.

Hablar de su tarea