Steve Klabnik from East River Source Control argues that Git, designed in 2005 for the Linux kernel, can't handle the demands of modern development. The real pressure comes from AI agents generating code at unprecedented speeds, creating massive repositories with frequent branching and merge conflicts. Monorepos—which agents favor for accessing context—amplify these problems by requiring fast clones and dealing with billions of lines of code. What used to be a big-company problem is now hitting everyone as agents scale up development velocity. ERSC's approach keeps the Git protocol on the client side but replaces the storage layer underneath with a custom engine. This sidesteps the network effects that locked everyone into Git—you can't easily switch version control systems when every tool speaks Git and every team uses it. By maintaining protocol compatibility, they let developers keep using familiar Git clients while gaining horizontal scalability and isolated deployments that don't suffer when someone else's repository balloons. It's a pragmatic bridge rather than a revolution. The company is also betting on Jujutsu, a version control system that already demonstrates how to support multiple backends. Developers can adopt Jujutsu individually while their coworkers stick with Git, and later the same backend could speak a different protocol entirely. ERSC plans to follow this pattern on the server side, letting teams migrate gradually rather than forcing a risky cutover. Storage comes first, but they're positioning this as the foundation for additional tools—code review, CI, issue tracking—that integrate into your existing stack instead of forcing you into a single platform.