Anthropic is rethinking how its engineers manage code

The tools engineers use to collaborate on code have remained largely unchanged for two decades, even as the nature of programming itself transforms. Understanding source control, how it evolved, and why AI development might demand different approaches reveals something fundamental about how technical culture adapts to new realities. What source control actually is Source control, also called version control, is the infrastructure that lets multiple programmers work on the same codebase without overwriting each other's changes. At its core, it's a historical record: every change to every file gets tracked, timestamped, and attributed to who made it. If something breaks, engineers can revert to a previous state. If two people edit the same file differently, the system flags the conflict so humans can decide what to keep. Without it, large software projects would be chaotic and unreliable. The standard model emerged in the 1990s For most of the last thirty years, source control has operated on principles designed when code was written line by line by individual humans. Engineers would commit discrete, understandable changes: fix a bug, add a feature, refactor a function. These commits became the unit of collaboration. You could read through a project's history and follow the reasoning behind each change because a human wrote a commit message explaining their intent. Branching, merging, and code review grew around this assumption: that changes would be infrequent enough to review carefully and intentional enough to understand at a glance. Tools like Git became dominant in the 2000s and have remained so because they work well for this model. They're optimized for managing human intent and human-scale collaboration. A company's source control practices are often a mirror of its culture and values about code quality and team communication. Why AI development creates friction Large language models can generate code at speeds and scales that don't fit neatly into this framework. When an LLM assists in writing, it might suggest dozens of variations, all subtly different. When training and deployment pipelines run continuously and generate artifacts, the line between code and data blurs. Experiment tracking, model weights, and configuration files pile up alongside traditional source code, but traditional version control systems weren't designed to handle gigabyte scale binary files or thousands of generated variants efficiently. Additionally, AI development involves constant experimentation. Engineers might run hundreds of training iterations, each producing logs, metrics, and model checkpoints that need to be tracked but don't fit the commit paradigm well. A single experiment might involve changes across dozens of files, multiple branches, and numerous generated artifacts. The narrative of "why this change matters" becomes harder to capture in a commit message. The underlying tension This situation reflects a deeper mismatch: tools buil