Depot co-founder and CEO Kyle Galbraith argued in a July 29 essay that GitHub's branch, pull request, review and merge workflow was built for human-paced development and is becoming a bottleneck as coding agents produce parallel streams of work.
The critique also lays out Depot's product strategy. Galbraith wants to turn source control, execution, artifacts, caching, identity and policy into infrastructure primitives that software teams can assemble around agents. Depot has spent this year moving in that direction, taking control of the layers surrounding the accelerated builds that first gave Depot its foothold.
In Depot's Series A post, Galbraith said he and co-founder and CTO Jacob Gillespie worked together as staff engineers for roughly four and a half years at Thorn and Era Software. They repeatedly encountered slow container builds and CI pipelines, then built an internal proof of concept that made their own container builds five times faster, according to Galbraith. That experiment became Depot, which was incorporated in January 2022 and joined Y Combinator's Winter 2023 batch.
Galbraith grew up around Portland, Oregon, and now lives in Montpellier, France. Gillespie, who previously worked at Webflow and Playlist as well as Thorn and Era, is based in London. Their geographic separation fits Depot: a distributed developer-infrastructure operation focused on removing the waiting that both founders experienced inside engineering teams.
A GitHub critique with a product behind it
Galbraith's argument starts with the familiar software-development loop: write code on a branch, open a pull request, wait for checks, collect comments, revise the code and merge it. Early coding agents fit into that sequence because they still operated close to human speed. Better agents, he writes, have increased the number of branches, checks and reviews moving through the same system at once.
That places the constraint downstream from code generation. Source control, CI, security scans, review and deployment each have to process the added output, while engineers still have to decide who owns agent-written code and how it should be trusted.
Depot began reducing its dependence on that workflow in March, when Depot CI became generally available. Depot says its earlier products could accelerate container builds or supply faster GitHub Actions runners, while GitHub still controlled orchestration, APIs and the surrounding control plane.
Depot CI gave the founders their own orchestration and compute layers. It accepts GitHub Actions workflows, supports custom runner images and lets developers or agents trigger runs, retrieve logs and test uncommitted changes through an API or command-line interface. The compatibility is a distribution tactic: teams can move execution to Depot without immediately rewriting the workflows they already run through GitHub.
The founders pushed one layer higher on July 9 with Depot Code, a source-control host now in private beta. Depot says it wrote a diskless Git server that stores packfiles and indexes in Amazon S3, keeps references and metadata in a transactional store, and runs stateless workers that can scale horizontally.
Depot Code can host a standalone repository or mirror an upstream GitHub repository. In the mirrored configuration, Depot CI can clone and fetch from Depot Code while commits continue flowing back to GitHub. That design gives Galbraith a migration path: move performance-sensitive infrastructure first and leave GitHub's collaboration surface in place until customers are prepared to change more of their workflow.
The approach also reveals the tension in the thesis. Depot says GitHub has the wrong architecture for agent-scale delivery, yet GitHub remains the easiest route into the customers Depot wants. GitHub Actions compatibility, repository mirroring and familiar Git commands lower adoption costs, while keeping Depot tied to the platform it wants to move beyond.
The founders are moving beyond faster runners
The expansion carries a defensive logic. Products that make an incumbent's infrastructure faster can lose their advantage when the incumbent improves.
That happened to BuildJet, another provider of accelerated GitHub Actions runners. In February, BuildJet announced it would shut down its runner service by March 31. BuildJet said GitHub's faster hardware, larger runners and native Arm support had largely closed the performance gap its service set out to address.
GitHub has also rebuilt the core services behind Actions. GitHub said its new architecture was handling 71 million jobs per day by late 2025, up from about 23 million per day in early 2024. GitHub cut hosted-runner prices by up to 39% from January 1 and announced a $0.002-per-minute platform fee for self-hosted runners starting March 1, then postponed that billing change after customer feedback. GitHub describes the rebuilt system as an execution layer for agentic workloads, directly contesting Galbraith's claim that its architecture cannot adapt.
Depot's answer is to own enough of the delivery stack that it cannot be reduced to a faster machine behind a GitHub label. Container builds led to runners, caching and registries. Those products led to Depot CI, and Depot CI created the reason to host source code closer to Depot's execution layer.
Investors have financed that progression. Depot raised a $10 million Series A in March from existing backers Felicis, Y Combinator and Pioneer Fund. A $4.1 million seed round in August 2024 was led by Felicis, with Y Combinator, Aviso Ventures, Tokyo Black and angel investors participating. Depot has disclosed at least $14.1 million in outside funding.
Depot says it accelerated over 100 million builds during 2025, saving customers about 8.5 million build hours. Those company-reported figures show meaningful usage of its build infrastructure. They do not establish that customers are ready to move source control or replace pull requests, which requires changes to security, compliance, ownership and review practices far beyond purchasing faster compute.
Galbraith's larger bet
Galbraith is proposing a delivery system organized around machine throughput. Source control supplies immutable history. Execution provides isolated compute. Artifacts and caches move reusable work between systems. Identity establishes whether a person or agent produced a change, and policy determines whether that change can ship.
That framing gives Depot room to sell infrastructure beneath whichever collaboration model wins. A team could keep pull requests for human decisions while agents use Depot's APIs to create repositories, run tests and collect evidence. Another customer could build a different approval process on the same primitives.
The hard part will be trust. Faster code generation raises the cost of weak review, unclear ownership and unreliable tests. A delivery system built for machine volume needs stronger controls around provenance and policy, rather than a faster route around them. Galbraith identifies those requirements in his essay, but Depot's recent releases are concentrated in source control and execution.
Depot has already shown that engineering teams will pay to spend less time waiting for builds. Galbraith is now betting those customers will reconsider where their code lives, how it is validated and which parts of the workflow still require a pull request. That takes Depot into a larger market and places the founders in direct competition with the platform that helped distribute their first products.