Filestage pasa de 200 a 300 PRs al mes con agentes IA

Filestage pasó de 200 a 300 PRs mensuales sin más bugs

Elio Capella, CTO de Filestage (una scaleup de software B2B), llevaba 18 años escribiendo código a mano todos los días. Hoy ya no. En una reflexión publicada en su blog personal, cuenta cómo el lanzamiento de Opus 4.5 dentro de Claude Code cruzó un umbral para él: explicar lo que quería era más rápido que escribirlo él mismo. «Un hábito diario de casi dos décadas desapareció de la noche a la mañana», escribió.

El dato central de su testimonio no es la confesión personal, sino lo que midió en su equipo: en Filestage pasaron de alrededor de 200 a 300 pull requests fusionados por mes sin un aumento en los reportes de bugs. Eso es aproximadamente 50% más throughput con una suscripción de US$20 al mes por desarrollador. Eligieron su propio stack: unos usan Codex, otros Claude Code, otros Cursor.

Capella no presenta esto como una victoria absoluta. Lo que más le preocupa ahora son los cuellos de botella que aparecieron en su propia infraestructura: rompieron los límites gratuitos de túneles de Cloudflare porque los tests end-to-end necesitaban recibir webhooks de terceros, y la base de datos compartida tuvo que crecer para aguantar las conexiones. Resolvió el atasco «vibeando» código con infraestructura como código y túneles FRP open source. Las mismas herramientas que crearon la carga ayudaron a removerla.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

¿Qué dice el sector? La tesis de DHH en Rails World 2026

La historia de Capella no es un caso aislado. DHH, creador de Ruby on Rails, expuso una tesis similar en el keynote de Rails World 2026 en Austin, Texas, según el resumen publicado por Fireship el 28 de septiembre de 2026. Su mensaje: escribir código fuente a mano ya no es económicamente viable, ni en Rails ni en general.

Para respaldarlo, DHH mostró que pasó de escribir unas 30.000 líneas de Ruby al año a 150.000 líneas por mes usando agentes. Y anunció la reescritura completa de su app Hey, originalmente en Ruby on Rails, a Rust generado por IA. El cambio redujo el uso de CPU y memoria del servidor en un 95%, según lo reportado en el keynote. Su conclusión provocadora: «Rust es un gran lenguaje siempre que nunca tengas que mirarlo tú mismo».

En el auditorio, con unos 1.200 desarrolladores presentes, DHH preguntó quién seguía escribiendo código a mano una parte significativa de su semana. Solo unas cinco manos se levantaron. La cuenta de Fireship lo traduce así: menos del 1% de los programadores asistentes siguen picando código a mano.

Donde Capella y DHH difieren es en el siguiente paso. DHH sugirió que los agentes pasarán de Rust a ensamblador y eventualmente a microcódigo. Capella lo rebate en su post: «Más output significa más detalles a resolver. Generar ensamblador implica predecir registros, offsets y convenciones de llamada que un compilador ya maneja». Su corazonada es la cadena LLM → representación de alto nivel → compilador determinista → código máquina, con las abstracciones haciéndose más valiosas, no menos.

Qué dicen los estudios: cifras duras sobre agentes en producción

El caso de Filestage se sostiene cuando se mira la evidencia agregada del sector:

Microsoft publicó el 1 de julio de 2026 un estudio interno sobre el despliegue temprano de Claude Code y GitHub Copilot CLI entre sus ingenieros. El resultado: +24% de pull requests mergeados por ingeniero por día, con un rango probable de +14,5% a +33,7% y un efecto que no se disipó durante los cuatro meses analizados, según reportó TechRepublic. Los usuarios intensivos (5 o más días por semana) vieron más del 50% de uplift.
Un estudio empresarial complementario, también cubierto por TechRepublic, siguió a 802 desarrolladores y 196.212 PRs entre enero de 2024 y abril de 2026 en una empresa mediana con un mandato público de duplicar throughput. El resultado: 44,3 PRs mergeados por desarrollador activo al mes en abril de 2026, frente a 21,2 antes del mandato, una mejora cercana al 2x. La clave: el salto se concentró en repositorios nuevos; los legacy apenas se movieron.
Un paper publicado en ACM Transactions on Software Engineering and Methodology revisó 567 PRs generados con Claude Code en 157 proyectos open source. El 83,8% fueron mergeados, pero solo el 54,9% entraron sin cambios adicionales. El 45,1% requirió revisión humana, sobre todo para corrección de bugs, documentación y estándares específicos del proyecto.

Las cifras validan la intuición de Capella: los agentes aceleran el output, pero no eliminan el trabajo fino. Y abren una pregunta que él mismo plantea: ¿bastará con pasar las checks automáticas y obtener el visto bueno de una revisión IA para mergear un PR? «Ya no suena descabellado», escribe.

El cuello de botella que casi nadie anticipa: revisión humana vs. agentes

El estudio empresarial cubierto por TechRepublic muestra el lado oscuro del acelerón. A medida que crecía el volumen de PRs autorales por IA, la proporción de PRs que recibían al menos una revisión humana cayó del 89% al 68%. En paralelo, la cobertura de revisión automatizada por IA subió del 19% al 84%, y la carga de trabajo por revisor humano se duplicó. Los PRs escritos por IA tardaban un 20% más en mergearse después de la primera revisión humana, y un 22% más en total.

Para founders, el mensaje es incómodo: el cuello de botella no es que el agente escriba código; es que tu sistema de revisión, tus estándares de QA y tu codebase absorban ese caudal sin degradarse. Journi, una startup londinense, lo resume así: «Un agente de código es una herramienta de productividad; una flota de ellos es un problema de gobernanza empresarial». Su producto DevOS, presentado el 22 de julio de 2026, es justamente una capa de control que mide ROI financiero por sesión y workspace, fuerza políticas de modelos permitidos y registra ahorros de tokens en un ledger auditable. La categoría entera —control plane para agentes— está emergiendo porque escribir más rápido no basta si no puedes demostrar que lo que escribiste sigue siendo seguro y mantenible.

¿Qué significa esto para tu startup?

Tres acciones concretas si estás construyendo producto con un equipo de ingeniería:

Mide throughput por repo, no por equipo. El estudio de Microsoft y el de la empresa con mandato 2x coinciden: los agentes rinden en código limpio y repos chicos; en legacy el uplift se diluye. Separa qué partes del producto se beneficiarán primero antes de comprar licencias para todos.
Endurece tu CI antes de sumar agentes. Capella lo dice con su propio caso: linting, type checking, checks de duplicación, cobertura 100% y tests end-to-end son los que permiten que +50% de PRs no se traduzca en +50% de bugs. Sin esa base, más velocidad significa más incidentes.
Diseña tu flujo de revisión como producto interno. Si la revisión humana va a caer del 89% al 68%, necesitas decidir hoy quién revisa qué, qué bloqueos son automáticos y dónde entra la IA como revisor secundario. Esperar a que el backlog explote es más caro que definir el protocolo ahora.

La frase que mejor resume el momento la dijo Capella: «Después de 18 años tecleando código, pensé que sabía qué se sentía programar. Tengo curiosidad por descubrir qué se siente después». No es una anécdota personal: es el cambio de default de toda una industria.