Depot dice que el modelo de pull request de GitHub no puede seguir el ritmo de los agentes de codificación

Why it matters

Depot's expansion shows where developer-tool founders expect AI coding pressure to move next: source control, CI, identity and policy.

Depot cofundador y CEO Kyle Galbraith argumentó en un ensayo del 29 de julio que el flujo de trabajo de ramas, pull requests, revisiones y fusiones de GitHub fue diseñado para un desarrollo a ritmo humano y se está convirtiendo en un cuello de botella a medida que los agentes de codificación generan flujos paralelos de trabajo.

La crítica también expone la estrategia de producto de Depot. Galbraith quiere convertir el control de código fuente, la ejecución, los artefactos, el cacheo, la identidad y la política en primitivas de infraestructura alrededor de las cuales los equipos de software puedan ensamblarse alrededor de agentes. Depot ha pasado este año moviéndose en esa dirección, asumiendo el control de las capas que rodean las compilaciones aceleradas que inicialmente dieron a Depot su punto de apoyo.

En la publicación sobre la Serie A de Depot, Galbraith dijo que él y el cofundador y CTO Jacob Gillespie trabajaron juntos como staff engineers durante aproximadamente cuatro años y medio en Thorn y Era Software. Se encontraron repetidamente con compilaciones de contenedores y pipelines de CI lentos, y luego construyeron una prueba de concepto interna que hizo que sus propias compilaciones de contenedores fueran cinco veces más rápidas, según Galbraith. Ese experimento se convirtió en Depot, que se constituyó en enero de 2022 y se unió a la promoción Winter 2023 de Y Combinator.

Galbraith creció en los alrededores de Portland, Oregon, y ahora vive en Montpellier, Francia. Gillespie, que anteriormente trabajó en Webflow y Playlist, además de Thorn y Era, está radicado en Londres. Su separación geográfica encaja con Depot: una operación distribuida de infraestructura para desarrolladores centrada en eliminar la espera que ambos fundadores experimentaron dentro de los equipos de ingeniería.

Una crítica a GitHub con un producto detrás

El argumento de Galbraith comienza con el familiar ciclo de desarrollo de software: escribir código en una rama, abrir un pull request, esperar las comprobaciones, recopilar comentarios, revisar el código y fusionarlo. Los primeros agentes de codificación encajaban en esa secuencia porque todavía operaban cerca del ritmo humano. Agentes mejores, escribe, han incrementado el número de ramas, comprobaciones y revisiones que atraviesan el mismo sistema a la vez.

Eso coloca la limitación aguas abajo de la generación de código. El control de código fuente, CI, los escaneos de seguridad, la revisión y el despliegue tienen que procesar la producción adicional, mientras que los ingenieros todavía deben decidir quién es el propietario del código escrito por agentes y cómo debe confiarse en él.

Depot comenzó a reducir su dependencia de ese flujo de trabajo en marzo, cuando Depot CI se volvió generalmente disponible. Depot dice que sus productos anteriores podían acelerar compilaciones de contenedores o proporcionar runners más rápidos para GitHub Actions, mientras GitHub todavía controlaba la orquestación, las APIs y el plano de control circundante.

Depot CI dio a los fundadores sus propias capas de orquestación y cómputo. Acepta workflows de GitHub Actions, soporta imágenes de runner personalizadas y permite a desarrolladores o agentes iniciar ejecuciones, recuperar registros y probar cambios no comprometidos a través de una API o interfaz de línea de comandos. La compatibilidad es una táctica de distribución: los equipos pueden mover la ejecución a Depot sin reescribir de inmediato los workflows que ya ejecutan en GitHub.

Los fundadores subieron una capa más el 9 de julio con Depot Code, un host de control de código fuente que ahora está en beta privada. Depot dice que escribió un servidor Git sin disco que almacena packfiles e índices en Amazon S3, mantiene referencias y metadatos en un almacén transaccional y ejecuta trabajadores sin estado que pueden escalar horizontalmente.

Depot Code puede alojar un repositorio independiente o espejar un repositorio upstream de GitHub. En la configuración espejada, Depot CI puede clonar y hacer fetch desde Depot Code mientras los commits continúan fluyendo de vuelta a GitHub. Ese diseño le da a Galbraith una ruta de migración: mover primero la infraestructura sensible al rendimiento y mantener la superficie de colaboración de GitHub en su lugar hasta que los clientes estén listos para cambiar más de su flujo de trabajo.

El enfoque también revela la tensión en la tesis. Depot dice que GitHub tiene la arquitectura equivocada para la entrega a escala de agentes, sin embargo GitHub sigue siendo la ruta más fácil hacia los clientes que Depot quiere. La compatibilidad con GitHub Actions, el espejado de repositorios y los comandos Git familiares reducen los costos de adopción, al mismo tiempo que mantienen a Depot atado a la plataforma que pretende superar.

Los fundadores van más allá de runners más rápidos

La expansión conlleva una lógica defensiva. Los productos que hacen que la infraestructura de un incumbente sea más rápida pueden perder su ventaja cuando el incumbente mejora.

Eso le sucedió a BuildJet, otro proveedor de runners acelerados para GitHub Actions. En febrero, BuildJet anunció que cerraría su servicio de runners para el 31 de marzo. BuildJet dijo que el hardware más rápido de GitHub, sus runners más grandes y el soporte nativo para Arm habían cerrado en gran medida la brecha de rendimiento que su servicio buscaba abordar.

GitHub también ha reconstruido los servicios centrales detrás de Actions. GitHub dijo que su nueva arquitectura manejaba 71 millones de jobs por día a fines de 2025, frente a alrededor de 23 millones por día a principios de 2024. GitHub redujo los precios de los hosted runners hasta en un 39% desde el 1 de enero y anunció una tarifa de plataforma de $0.002 por minuto para los self-hosted runners a partir del 1 de marzo, para luego posponer ese cambio en la facturación tras los comentarios de los clientes. GitHub describe el sistema reconstruido como una capa de ejecución para cargas de trabajo agenéticas, refutando directamente la afirmación de Galbraith de que su arquitectura no puede adaptarse.

La respuesta de Depot es poseer lo suficiente de la pila de entrega como para no poder ser reducido a una máquina más rápida detrás de una etiqueta de GitHub. Las compilaciones de contenedores llevaron a runners, cacheo y registries. Esos productos condujeron a Depot CI, y Depot CI creó la razón para alojar el código fuente más cerca de la capa de ejecución de Depot.

Los inversores han financiado esa progresión. Depot recaudó $10 millones en su Serie A en marzo de los actuales patrocinadores Felicis, Y Combinator y Pioneer Fund. Una ronda semilla de $4.1 millones en agosto de 2024 fue liderada por Felicis, con la participación de Y Combinator, Aviso Ventures, Tokyo Black y ángeles inversionistas. Depot ha revelado al menos $14.1 millones en financiación externa.

Depot dice que aceleró más de 100 millones de compilaciones durante 2025, ahorrando a los clientes alrededor de 8.5 millones de horas de compilación. Esas cifras reportadas por la compañía muestran un uso significativo de su infraestructura de compilación. No establecen que los clientes estén listos para mover el control de código fuente o reemplazar los pull requests, lo cual requiere cambios en seguridad, cumplimiento, propiedad y prácticas de revisión mucho más allá de la compra de cómputo más rápido.

La apuesta mayor de Galbraith

Galbraith propone un sistema de entrega organizado en torno al rendimiento de máquina. El control de código fuente suministra historial inmutable. La ejecución provee cómputo aislado. Los artefactos y las cachés trasladan trabajo reutilizable entre sistemas. La identidad establece si una persona o un agente produjo un cambio, y la política determina si ese cambio puede enviarse.

Ese encuadre le da a Depot espacio para vender infraestructura por debajo de cualquier modelo de colaboración que gane. Un equipo podría mantener los pull requests para decisiones humanas mientras los agentes usan las APIs de Depot para crear repositorios, ejecutar pruebas y recopilar evidencia. Otro cliente podría construir un proceso de aprobación distinto sobre las mismas primitivas.

La parte difícil será la confianza. La generación de código más rápida eleva el costo de una revisión débil, propiedad poco clara y pruebas poco fiables. Un sistema de entrega diseñado para volumen de máquinas necesita controles más fuertes alrededor de la procedencia y la política, en lugar de una vía más rápida que los rodee. Galbraith identifica esos requisitos en su ensayo, pero los lanzamientos recientes de Depot están concentrados en el control de código fuente y la ejecución.

Depot ya ha demostrado que los equipos de ingeniería pagarán por pasar menos tiempo esperando compilaciones. Galbraith ahora apuesta a que esos clientes reconsideren dónde vive su código, cómo se valida y qué partes del flujo de trabajo aún requieren un pull request. Eso lleva a Depot a un mercado más amplio y coloca a los fundadores en competencia directa con la plataforma que ayudó a distribuir sus primeros productos.