Git Replaced, LLMs Displaced: AI Coding Forces a Toolchain Rebuild

When AI agents produce code far faster than humans, toolchains designed around the human development cadence begin to show structural cracks. Anthropic used 7 engineers over 5 months to rewrite a version control system called Scion and migrate its core repositories; GitHub swapped the general-purpose LLM in its secret scanning for a fine-tuned ModernBERT; and Columbia University, Google DeepMind, and other institutions used BTTF to turn chip simulation waveforms into SQLite databases. Three stories point to the same conclusion: the runaway pace of AI-written code is forcing the entire software engineering pipeline to be rebuilt.

1. Why Git's Offline Autonomy Became a Burden in the AI Era

When Checkouts Jump from Thousands to Tens of Millions

Git's distributed design lets engineers commit, merge, and browse history even offline after cloning a repository, and this model has supported software development for over two decades. But Anthropic faced a different kind of load: in May of this year it averaged about 2,500 merged code changes per day, and by September that had exceeded 30,000, with the CI system executing roughly 25 million code checkouts per day.

Most of these checkouts come from always-online CI jobs and agent sandboxes that are destroyed after running for a few minutes. They may only need a few files, a diff, or confirmation of the ancestor relationship between two commits. Preparing a local repository for such operations multiplies the cost indefinitely. Anthropic's main branch history is nearly 100 GB, and the compressed working copy exceeds 25 GB. If all 25 million daily checkouts fetched full copies, the theoretical traffic would exceed 600 PB. Shallow clones, sparse checkouts, snapshots, and hundreds of Git mirrors can ease the pain temporarily, but mirrors need syncing, snapshots expire, and history queries still require filling in objects—the more active the repository, the higher the maintenance cost.

Shallow clones and sparse checkouts are two mechanisms Git provides to ease the burden of large repositories. A shallow clone uses the --depth parameter to fetch only the most recent commits and discard older history objects, greatly reducing transfer size; a sparse checkout allows the working tree to expand only specified directories or file patterns, leaving other paths unwritten to disk. The two are often combined in CI to reduce the cost of a single checkout by "fetching only what is needed." But both are local optimizations: shallow clones cannot answer cross-history blame or ancestor queries, and sparse checkouts still require a complete local object database—any need to fill in missing objects triggers additional network round trips. Under a load of tens of millions of daily checkouts, the marginal benefit of these patch-style measures decays rapidly, which is exactly why Anthropic chose to rebuild the protocol rather than keep tuning parameters.

Scion's Trade-off: Giving Up Offline for Online Efficiency

Scion shrinks the client to a lightweight entry point, moving commit creation, merging, rebasing, and history queries to a central service. Locally it only monitors file changes and maintains a small cache, expanding a working directory on demand. If CI only needs to compute a diff, it can call the API directly without a full checkout.

The commit format changed accordingly: a Git commit points to a directory tree describing the repository state, while a Scion changeset records the files modified relative to the first parent as a write-ahead log entry, referencing data through content-addressed pointers. Creating a changeset requires no Git packfile generation; only when references such as main are updated is a compare-and-swap performed on a single row record in Spanner, concentrating concurrency contention at the moment the branch reference moves.

History queries are the harder part. Incremental records cannot directly answer who changed a given line or what a file has been through, so Scion maintains derived data for blame, path history, and the commit-graph skip list, allowing writes and history analysis to scale independently. Objects are immutable after writing, so caches can be reused across tasks—Anthropic reports a cache hit rate above 99%. After migration, Scion's CPU and memory requirements are about 200 times smaller than the old Git mirror system, checkouts drop from minutes to seconds, and CI frees up about 25% of its CPU capacity.

The "200 times" refers to infrastructure resource consumption, not to an overall speedup of Git operations. Anthropic also built Antique code review, source search, IAM, and bulk merge tools in parallel to adapt to the new protocol, and maintaining the online service itself has become a new cost.

Content-addressable storage refers to a storage model in which a cryptographic hash of the data content serves as its identifier; Git's blob, tree, and commit objects all fall into this category. Scion's changesets reference file data through content-addressed pointers, meaning identical content is stored only once and is immutable after writing, so caches can be safely reused across tasks. Paired with this, compare-and-swap (CAS) is an optimistic concurrency control: before updating, it verifies whether the target record's current value still equals the old value read earlier, writing only if they match, otherwise retrying. Scion converges reference updates into a CAS on a single row record in Spanner, so concurrency conflicts occur only at the instant the branch pointer moves, not throughout the entire commit process. Together these two mechanisms support the article's claims of a "cache hit rate above 99%" and "writes and history analysis can scale independently."

2. Waveforms to SQL: Letting Agents Actually Trace Chip Faults

Tens of Gigabytes of Physical Files Won't Fit in Context

Chip verification faces a different kind of obstacle. VCD and FSDB waveforms produced by RTL simulation record the state of a large number of signals over time, and dumps of complex designs can reach tens of GB or even TB scale. Engineers can search along the time axis in a waveform viewer for anomalies, but if an agent converts raw waveforms to text, the context is quickly filled with timestamps, signal names, and repeated transitions, and tracing other signals requires re-reading the file.

BTTF's approach hands data access to SQLite: signal_metadata stores static information such as signal name, type, and hierarchy, while signal_changes records signal ID, timestamp, and the value after the change, with the two tables linked by ID. To query a signal's state at a specified time, SQL finds the nearest change record before that moment; to check for toggles within a time window, it filters and aggregates by time window. The model only needs to handle the question and a small number of returned events—the database handles retrieval, and the model decides what to query next.

The Cost of Pruning: Only 64% Coverage Behind 185 MB

Moving waveforms into a database does not automatically eliminate pressure. High-frequency clocks generate dense records, and row-by-row INSERTs carry transaction costs, so BTTF builds a mapping from waveform identifiers to database IDs during ingestion, counts signal transitions, and combines clock filtering, pruning of non-toggling signals, and batch inserts.

The experimental data shows the weight of these trade-offs: an unpruned database occupies 1,420 MB and queries take about 410.5 ms; after filtering clocks and non-toggling signals, the size drops to 395 MB and query time to 94.8 ms; if signals with a toggle rate below average are further removed, the database shrinks to 185 MB, but activity coverage falls to just 64.23%. Rare faults may occur precisely on control signals that almost never toggle—if the data is deleted during import, later agents cannot recover the evidence, so pruning must be subordinated to assertion and debugging needs.

In experiments on a 4.2 GB waveform with 18,450 signals and 150 expert-annotated queries, the research team achieved 95.33% execution accuracy, a 17.3% improvement in Multi-Agent quality scores over a single agent, an average latency increase of about 1.96x, and 84.62% accuracy on static SVA checks. The approach can support post-simulation analysis, but continuous ingestion and complex attribution still need validation.

VCD and FSDB are two waveform formats used in chip simulation. VCD (Value Change Dump) is an open-source text format defined by the IEEE 1364 standard that records each change in signal value over time; it is highly readable but bulky. FSDB (Fast Signal Database) is a binary format used by commercial tools such as Verdi, with higher compression and read/write speed, but it depends on a proprietary toolchain. BTTF must first parse both formats, extracting "signal—time—value" triples before writing them into SQLite's two tables. Understanding this helps judge its engineering boundaries: parsing throughput directly determines ingestion speed, and FSDB's closed nature means the approach's portability within open-source toolchains is limited. The caveat that "continuous ingestion still needs validation" stems largely from this.

3. Secret Scanning: From Generative LLM Back to Classifier

High-Frequency Judgments Shouldn't Bear Generative Inference Costs

A high-entropy string may be a real credential, or it may be test data, a placeholder, or a checksum. Regex can quickly find suspicious patterns but is poor at judging code context; a general-purpose LLM can help distinguish them, but the more candidates there are, the more inference cost and latency accumulate. For Push Protection, which must return a result before a code commit is accepted, this waiting directly affects the developer experience.

GitHub keeps regex as the candidate entry point and hands subsequent judgment to a fine-tuned ModernBERT. It reads the candidate string, secret type, variable name, file path, and nearby code, outputs a risk classification score, and a threshold decides whether to alert. An encoder returns a category after a single forward pass, without the token-by-token explanation output of a generative LLM, making it suitable for batch processing of similar requests.

The 98% Cost Reduction Refers to Model Serving Fees

The hard part is hard negatives: strings that look like secrets but are harmless examples. GitHub combined product feedback and human annotations, high-recall candidates from real repositories, and specially synthesized hard negatives, and split training and evaluation sets by repository, candidate value, and association to reduce evaluation bias from similar data. The model is exported to ONNX and 8-bit quantized to lower inference overhead, and the threshold must be calibrated against Precision, Recall, and live traffic.

Compared with the old LLM pipeline, the new approach improves offline Precision by 13% and Recall by 19%. Online A/B experiments show that median Post-push scan execution time dropped by 86%, model serving costs fell by more than 98%, and the owner-weighted alert acceptance metric improved by 11.5%. The 98% here refers to model serving fees, not the total cost of the entire security system; the classifier can only judge candidates found by regex, and the coverage of the upstream rules still limits missed-detection performance.

Encoder models vs. generative LLMs differ fundamentally in inference mode. An encoder such as ModernBERT performs a single bidirectional forward pass over the input and directly outputs a classification vector, with latency roughly linear in input length and highly batchable; a generative LLM must autoregressively decode token by token, with each token requiring a forward pass and KV cache maintenance. Secret scanning is essentially a binary classification task—whether a candidate string is a real credential—and does not require natural language explanation, so encoders win on cost and latency. ONNX and 8-bit quantization further compress this advantage: ONNX provides a unified computation graph and runtime optimization across frameworks, while 8-bit integer quantization reduces weights from FP32 to INT8, significantly cutting memory bandwidth and compute requirements at the cost of slight accuracy loss that must be compensated through threshold calibration.

4. The Next Domino: CI

GitHub has shortened the feedback time for security scanning, but code still has to go through build, test, and deploy. After solving the source checkout problem, Anthropic ran into a new one: before one round of tests finishes, the main branch may have merged hundreds or even thousands of additional changes.

Continuing to rely on global locks lets changes pile up, while loosening concurrency brings new risks—even if a test has passed, the code state it corresponds to may differ from the version about to be deployed. What CI must handle next is how to keep validation results valid amid high-frequency changes: build caches need to detect changes in source code and dependencies, test records must be tied to specific commits and build artifacts, and the system must judge which results can be reused and which changes invalidate prior validation. For Monorepos with complex dependencies, simply adding 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 is more realistic than rebuilding the version control system outright. As agents continue to raise code output, the bottleneck in software engineering will move backward along the delivery chain. Code can enter the main branch faster and faster, but a reliable validation relationship must be preserved between build, test, and deploy. The value of engineering infrastructure will increasingly lie in whether it can give rapidly changing code a continuously trustworthy basis for delivery.

One-line Summary

Faster AI coding is forcing a full-chain rebuild of version control, waveform analysis, secret scanning, and CI

Paragraph Summary

The article uses three cases to show how high-speed code production by AI agents is forcing a rebuild of the software engineering toolchain. Anthropic, crushed by 25 million daily checkouts overwhelming its Git mirror system, built Scion—abandoning offline autonomy for a central service and changeset format, reducing CPU and memory needs by about 200x; BTTF converts tens of GB of chip simulation waveforms into a two-table SQLite structure so agents can trace faults with SQL, achieving 95.33% execution accuracy, though aggressive pruning drops coverage to 64.23%; GitHub replaced its general-purpose LLM with a fine-tuned ModernBERT for secret scanning, cutting model serving costs by over 98% and median scan time by 86%. The author points out that the next domino is CI: keeping validation results valid under high-frequency change will become the new core challenge.