Preetam Dwivedi

Preetam Dwivedi is a Seattle-based staff engineer on Uber’s Developer Platform team. He leads work on code hosting, code review, merge queues, and the storage of build artifacts. With Akshay Hacholli and Adam Bettigole, he helped build GitFarm so that hundreds of automation systems could run Git commands without each maintaining its own copies of Uber’s repositories.

Preetam studied computer science and engineering at the National Institute of Technology Raipur. At Amazon, he led projects in digital payments, merchant workflows, and microservice architecture. At Uber, he led the move to GitHub for code review and the migration of artifact storage to the cloud.

Sharing repository checkouts and build artifacts

One Uber service kept full repository checkouts on six machines to answer a question it could resolve by reading a file: who owns this code? GitFarm, in production since early 2025, keeps a pool of checkouts synchronized with upstream repositories. A service can run ordinary Git commands in an isolated session against a prepared checkout and explicitly fetch the latest changes when it needs them. The code ownership service dropped its local copies, and its startup time fell from 15–20 minutes to under a minute.

Moving build artifacts off local disks spared Uber engineers the work of copying hundreds of terabytes when a storage node failed. It also made repeated downloads expensive. Uber’s builds consumed more than five petabytes of artifacts a month, often requesting the same files. Preetam and Manjari Akella’s team built a proxy that checks each request with the cloud service. When the service confirms that a file is unchanged, the proxy serves the bytes locally. That reduced the volume of data leaving the cloud service by more than 99 percent.

Deciding which changes to test together

Two code changes can each pass their tests and still break the build when merged. Uber’s SubmitQueue tests likely combinations before merging them into the main branch. As AI-assisted coding pushed traffic from about 90 requests an hour in January 2026 to 130 in March, the 95th-percentile time to merge grew from 30 minutes to three or four hours.

Preetam and Manjari described how their team revised the queue’s rules. Changes with substantial overlap still had to pass tests together. Those with weaker overlap could proceed independently, leaving some interactions to be tested after the merge. Stovepipe checks the resulting code and advances a separate reference, verified main, only when the build and tests pass. Engineers can use that revision while the on-call engineer fixes or reverts a change that broke a later build. The team reached about 300 merges an hour at peak, with the 95th-percentile merge time back at roughly 30 minutes. Preetam also described a next step for validation: tracking which services passed so that a failure in one needn’t hold up the release of another.