¿Cuánto acelera la IA el desarrollo en realidad? Lo he medido

Desarrolladores, managers de otras empresas, compañeros: la pregunta que más me han hecho este año es siempre la misma: ¿cuánto te acelera la IA en realidad? Siempre tuve una respuesta, pero era una sensación. Como desarrollador, claramente me volví más rápido. Quería contrastar esa sensación con números.

Tenía un escenario ideal para hacerlo. Durante el último año he sido el único desarrollador iOS de GrowDiaries, una red social para cultivadores escrita en SwiftUI puro y The Composable Architecture. El proyecto se divide limpiamente en dos mitades: en la primera trabajé como siempre lo había hecho, y en la segunda fui construyendo poco a poco un flujo de trabajo con IA alrededor de mi desarrollo. Como todo el historial vive en un único repositorio git y cada commit en main es una build entregable, las dos mitades se pueden comparar directamente.

El resultado

Dos ventanas idénticas de seis meses: junio–noviembre de 2025, antes del flujo, frente a febrero–julio de 2026, con él. Mismo producto, misma arquitectura, mismo nivel de code review.

Mi intuición decía «aproximadamente una vez y media». Los números salieron incluso más altos: la delivery cadence creció un 48 %, el feature throughput un 38 % y el code output bruto un 81 %. Sinceramente, no esperaba tanto.

Una salvedad antes de los detalles. Estos números miden la parte del trabajo que consiste en escribir código. Los desarrolladores también dedican mucho tiempo a discutir funcionalidades, planificar y coordinar, y cuánto ocupa eso en tu semana depende por completo de la empresa. En este proyecto pude dedicarme casi por completo al desarrollo, así que lo que ves aquí es sobre todo la aceleración de construir funcionalidades, no de todo lo que hace un desarrollador.

Cómo es el flujo de trabajo

Como la mayoría de los desarrolladores, empecé conversando con ChatGPT y, a medida que apareció la codificación agéntica, la fui incorporando a mi trabajo paso a paso. Con el tiempo aprendí en qué es bueno mi harness y dónde falla, y la mayor parte de mi esfuerzo fue a una sola cosa: cerrar el ciclo de feedback. No el prompt ni la generación, sino la última parte: probar el código que produce el agente.

El ciclo de feedback

La mejor decisión que tomé al principio fue elegir TCA como arquitectura. Está construida en torno a la testabilidad, y eso resultó importar mucho más con un agente que con una persona al teclado.

Empecé por lo más barato: generar tests unitarios. Eso cubre la lógica de negocio, pero solo la lógica de negocio. Así que fui más allá e hice que el agente ejecutara autotests completos: al terminar una funcionalidad, la verifica él mismo. Escribí guías para derivar casos de prueba de mi especificación original, de modo que cada ticket viene con su propia lista de comprobación. Y el paso final de cada ticket es el agente ejecutando la funcionalidad en el simulador y recorriendo esos casos.

Afinar este ciclo llevó trabajo de verdad y me enseñó mucho sobre cómo estructurar el testing para un agente. Pero es exactamente lo que elevó la calidad del código generado, y una mayor calidad del primer borrador es lo que se convirtió en entregas más rápidas. También cambió mi forma de pensar la arquitectura: ahora valoro aún más los tests y una estructura amigable para el agente, porque son la forma más rápida de detectar errores y alucinaciones antes de que cuesten algo.

La entrada de datos

El lado de entrada fue sorprendentemente sencillo de montar con MCP. La documentación se recoge de donde vive, y el MCP de Figma le da al agente la especificación de diseño completa de una pantalla, hasta los márgenes y los colores.

Un consejo aquí: descompón tu diseño en un sistema de diseño y mantenlo desde el primer día. Compensa por partida doble. El agente no vuelve a crear una y otra vez los mismos componentes de UI con pequeñas diferencias, y la calidad sube, porque en esas pequeñas diferencias es exactamente donde habrían vivido los bugs.

Los números y cómo se midieron

• Code output son las líneas de Swift añadidas al mes, solo archivos *.swift, sin localizaciones generadas ni assets. Pasó de unas 6.000 a unas 11.000 líneas al mes.
• Delivery cadence son las builds entregables al mes. El proyecto es trunk-based: cada commit sin merge en main es una build funcional con una funcionalidad o una corrección, así que el recuento de commits es el recuento de entregas. Subió de unas 17 a unas 25 builds al mes.
• Feature throughput son las funcionalidades publicadas al mes, extraídas de los títulos de los tickets en el historial de commits. Los tickets que solo contienen correcciones quedan fuera. Subió de menos de 5 a casi 7 funcionalidades al mes.

Julio de 2026 fue el mes récord: 29.125 líneas añadidas, con las páginas de marcas, los anuncios y el modo oscuro aterrizando el mismo mes. La imagen completa mes a mes, incluido el desglose por funcionalidad, está en la página de estadísticas.

Qué no cambió

• La calidad de la revisión. Leo cada diff. El agente escribe más del primer borrador; la decisión sigue siendo mía.
• La arquitectura. SwiftUI puro y TCA antes, SwiftUI puro y TCA después. Los agentes funcionan mejor en una base de código con convenciones fuertes y explícitas, y TCA resultó encajar muy bien.
• La estabilidad. La app está en la App Store y, a día de hoy, los crashes sencillamente no existen.

Una nota sobre la métrica

Sé que las líneas de código son una métrica indirecta y sé que no capturan por completo la productividad. Por eso se muestran junto a las builds y las funcionalidades, y por eso la comparación usa ventanas idénticas del mismo proyecto. Pero son los números que sí se pueden medir, y todos apuntan en la misma dirección: con el flujo de trabajo en marcha, la velocidad de desarrollo y la velocidad de entrega subieron, más de lo que esperaba.