By Zheng Jiamei
Edited by Cen Feng
Git has supported software development for more than twenty years, yet Anthropic decided to replace it. To let the code continuously generated by Claude flow smoothly into the development process, 7 engineers spent 5 months developing a version control system called Scion and migrated the core code repository over to it. In May (month 5) of this year, Anthropic merged an average of about 2500 code changes per day; by September (month 9), that had exceeded 3×10,000 (30,000), and the CI system alone had to perform about 2500×10,000 (25 million) code checkouts per day. The speed of writing code has gone up, but preparing repositories, syncing objects, and querying history have become increasingly machine-intensive. Around the same period, GitHub replaced the general-purpose LLM judgment in secret scanning with a fine-tuned ModernBERT. Columbia University, Google DeepMind, and other institutions, meanwhile, used BTTF to convert chip simulation waveforms into SQLite, letting Agents use SQL to troubleshoot anomalies. Scion is online by default, BTTF turns waveforms into a query interface, and GitHub hands high-frequency judgments to a classifier. Systems designed around human development rhythms are beginning to bear a different kind of load brought by Agents.
01
Why Git's offline capability became a burden
Git's distributed design lets engineers commit, merge, and view history even offline after cloning a repository. But Anthropic's code-reading-heavy workloads are always-online CI jobs and Agent sandboxes that run for a few minutes and are then destroyed; they may need only a few files, a single diff, or to confirm the ancestry relationship between two commits. Preparing a local repository for these operations incurs ever-higher repeated costs. Anthropic's main branch history is nearly 100 GB, with compressed working copies exceeding 25 GB. If each of the 25 million daily checkouts fetched a full copy, theoretical traffic would exceed 600 PB. The company uses shallow clones, sparse checkouts, snapshots, and hundreds of Git mirrors, but mirrors still need syncing, snapshots expire, and history queries still require filling in objects. The more active the repository, the higher the maintenance cost. Scion shrinks the client into a lightweight entry point. Commit creation, merging, rebasing, and history queries are moved to a central service; the local side only monitors file changes and maintains a small cache, expanding on demand when a working directory is needed. If CI only wants to compute a diff, it can call the API directly without a full checkout. This sacrifices offline autonomy but reduces repeated initialization. The commit format also changed. A Git commit points to a directory tree describing the repository state, whereas Scion's changeset uses a write-ahead log entry to record the files modified relative to the first parent commit, referencing data through content-addressed pointers. Creating a changeset requires no Git packfile generation and no immediate movement of shared branches; only when references like main are updated does the system perform a compare-and-swap on a single-row record in Spanner. Agents can generate changes concurrently, with contention concentrated at branch reference moves. But history queries still pose a challenge: incremental records cannot directly answer who changed a given line or what a file went through. Scion maintains derived data for blame, path history, and commit graph skip lists, precomputing it based on parent commit relationships, or generating it on demand when a query occurs. Writes and history analysis can scale independently. Leiphone found that at checkout, the scn client starts from the target directory tree and requests only the missing trees and blobs. Requests pass in sequence through the scion-daemon on the node and the regional scion-cache, then scion-server goes back to the source in Spanner or object storage. Objects are immutable once written, so caches can be reused across tasks, reducing negotiation, compression, and repeated transfers. According to Anthropic, cache hit rates exceed 99%, and back-to-source traffic during failures is capped. After the migration, Scion's CPU and memory requirements shrank roughly 200 times compared with the old Git mirror system, checkouts dropped from minutes to seconds, and CI freed up about 25% of CPU capacity. The 200-fold figure refers to infrastructure resource usage, not an across-the-board speedup of Git operations. Anthropic also built Antique code review, source code search, IAM, and batch merge tools in parallel to support the new protocol. Maintaining the online services became a new cost as well.02
Let the database read waveforms so Agents can trace faults
Chip verification faces a different kind of obstacle. VCD and FSDB waveforms produced by RTL simulation record the states of large numbers of signals over time; dumps of complex designs can reach tens of GB, even TB-scale. Leiphone (WeChat account: Leiphone) Engineers can hunt for anomalies along the time axis in a waveform viewer, but if an Agent converts raw waveforms into text, its context is quickly filled with timestamps, signal names, and repeated transitions. Tracing other signals may require reading the files again. Moreover, humans are used to finding a needle in a haystack visually in charts, but no matter how large an Agent's context is, it cannot hold tens of GB of physical files. Therefore, converting these "dead files" into "live interfaces" that can be precisely invoked via SQL is the optimal way to feed data to AI. BTTF hands data access to SQLite. signal_metadata stores static information such as signal names, types, and hierarchy, while signal_changes records signal IDs, timestamps, and the values after each change; the two tables are joined by ID. To query a signal's state at a given moment, SQL finds the nearest change record before that moment; to check toggles over a period, it filters and aggregates by time window. The state is unchanged between two transitions, so the absence of a new record must not be mistaken for unknown. The model only needs to process the question and a small set of returned events. For example, if a handshake protocol segment times out, the Agent can first retrieve the changes of the request and response signals, then narrow down to the anomalous interval and check the timing relationships. The database handles retrieval; the model decides what to query next. Queries must align signal IDs, time units, and RTL versions. But moving waveforms into a database does not automatically remove the pressure. High-frequency clocks generate dense records, and row-by-row INSERT carries transaction costs. BTTF builds a mapping from waveform identifiers to database IDs during ingestion, counts signal transitions, and combines clock filtering, pruning of toggle-free signals, and batch inserts. Without pruning, the database occupies 1420 MB with queries taking about 410.5 milliseconds; after filtering clocks and toggle-free signals, the size drops to 395 MB and query time falls to 94.8 milliseconds. If signals with below-average toggle rates are further removed, the database can shrink to 185 MB, but active coverage drops to only 64.23%. Rare faults may occur precisely in control signals that almost never toggle. If data is deleted at the import stage, downstream Agents cannot recover the evidence. Pruning must be subordinate to assertions and debugging needs. With the SQL interface in place, BTTF then assigns different Agents their roles: an Orchestration Agent decomposes tasks, an Analysis Agent generates queries, a Verification Agent checks assertions and correlates RTL source code, and an Evaluation Agent verifies time ranges, field relationships, and result completeness. For instance, when ASSERT_KNOWN finds a signal in an X/Z unknown state, the system first locks in the moment of violation, then checks the states of relevant operands going forward, gradually locating the likely module. SQL errors can also be corrected and execution continued. In experiments with a 4.2 GB waveform, 18450 signals, and 150 expert-annotated queries, the research team achieved a 95.33% execution accuracy. The Multi-Agent quality score improved by 17.3% over a single Agent, while average latency increased to about 1.96 times, and static SVA checking accuracy was 84.62%. The approach can support post-simulation analysis, but continuous ingestion and complex attribution still need validation.03
Why secret switching went back to classifiers
High-entropy strings may be real credentials, or they may be test data, placeholders, or checksums. Regular expressions can quickly find suspicious formats but are poor at judging code context; general-purpose LLMs can help distinguish, but the more candidates there are, the more inference costs and latency accumulate. For Push Protection, which must deliver results before a code commit is accepted, such waiting directly affects the development experience. GitHub keeps regular expressions as the candidate entry point and hands subsequent judgment to a fine-tuned ModernBERT. It reads the candidate string, key type, variable name, file path, and nearby code, outputs a risk classification score, and a threshold decides whether to alert. An encoder can return a category after a single forward pass, without needing to output explanations token by token like a generative LLM, making it suitable for batch processing of similar requests. The difficulty lies in hard negatives: strings that look very much like keys but are harmless examples. GitHub combines product feedback and human annotations, high-recall candidates from real repositories, and specially synthesized hard negatives, and splits training and evaluation sets by repository, candidate value, and associated relationships to reduce evaluation bias from similar data. Otherwise the model might memorize file names yet struggle to recognize credentials in unfamiliar projects. At deployment, the model is exported to ONNX with 8-bit quantization to reduce inference resource overhead. The threshold also needs calibration against Precision, Recall, and live traffic: too loose brings false positives, too strict may let real keys through. When new key formats appear, the training set and rules must be updated as well. Compared with the old LLM pipeline, the new approach improved offline Precision by 13% and Recall by 19%. Online A/B experiments showed the median Post-push scan execution time dropped 86%, model serving costs fell more than 98%, and the alert acceptance metric weighted by repository owner rose 11.5%. Here the 98% refers to model serving fees, not the total cost of the entire security system. The classifier can only judge candidates found by the regular expressions, and the coverage of the front-end rules still limits the miss rate. Rules find the leads, classifiers finish the judgment, and open-ended analysis can still be handed to general-purpose LLMs, avoiding the cost of generative reasoning for every fixed judgment.04
CI may be next
GitHub has shortened the feedback loop for security scans, but code still has to go through building, testing, and deployment. After resolving the source code checkout problem, Anthropic also ran into new trouble: before one round of testing finished, the main branch might have merged in hundreds or even thousands of changes. Continuing to rely on a global lock would cause changes to keep piling up, while opening up concurrency would bring new risks — even if a test had already passed, the code state it corresponded to might differ from the version being prepared for deployment. This means that what CI has to handle next is how to keep validation results valid amid high-frequency changes. The build cache needs to recognize changes in source code and dependencies, test records must be associated with specific commits and build artifacts, and the system must determine which results can be reused and which changes invalidate previous validations. For Monorepos with complex dependencies, simply adding more test machines can hardly solve the version consistency problems caused by concurrent modifications. Anthropic has already begun strengthening post-merge testing and pre-deployment validation. For ordinary teams, improving dependency analysis, incremental testing, and build caching first is more realistic than directly rebuilding the version control system. As Agents continue to increase code output, the bottleneck of software engineering will keep moving backward along the delivery chain. The speed at which code enters the main branch can keep getting faster, but reliable validation relationships must be preserved between building, testing, and deployment. In the future, there may be more and more examples showing thatthe breakneck pace of AI writing code is ultimately forcing the entire software engineering pipeline to be 'redone from scratch.'The value of engineering infrastructure will also be increasingly reflected in whether it can enable rapidly changing code to continuously obtain credible delivery evidence.Reference links:https://www.anthropic.com/engineering/redesigning-source-controlHop on board for a tour of the highlights of global AI conferences
Exclusive access to:
Expert presentation slides
Full conference reports
Popular paper explanations
Interviews with rising academic stars
Scan the QR code above
or click "Read Original" to follow the channel.
Leiifeng.com original article; unauthorized reproduction is prohibited. See details inthe reproduction notice。