Settled ideas have expiry dates. Git just hit its

Git was the most settled idea in software. Twenty-one years old, so dominant that "git" and "version control" became synonyms, wired into every CI system, every IDE, and the muscle memory of every working developer. Then, in four months, it stopped being the right answer inside Anthropic — not because it was wrong, but because the one condition it was designed around moved by twelve times. That is the shape obsolescence actually takes. It does not arrive at things that are broken. It arrives at things that still work.

The thing that broke was not broken

Git did not fail. It did exactly what it was built to do: give every client a complete, offline copy of history, so that a distributed group of people with unreliable connections could work independently. That design was correct in 2005 and it is still correct for almost everyone reading this.

What changed is that Anthropic's clients stopped being people. Most of them became CI jobs and coding agents that are always online and never need a local copy of anything. Daily merges went from 2,500 to more than 30,000 between May and September 2026. The assumption underneath git — that the expensive, scarce resource is connectivity, and the cheap, abundant one is local disk and human patience — simply inverted. The engineering detail is its own story; what matters here is the mechanism.

Every settled idea is a bet on a condition. Git bet on offline-first clients. The bet was right for two decades. Nobody noticed it was a bet, because when a bet keeps paying, it stops looking like a bet and starts looking like a law.

Obsolescence does not announce itself

This is the part that makes it hard to see coming. A failing thing announces itself — it crashes, it loses money, people complain. An obsolete thing behaves perfectly and quietly becomes the ceiling.

Anthropic's merge queue was not broken. It worked precisely as designed, serializing every change so each one was tested against the exact state it would land on. That is a genuine best practice. And at 30,000 merges a day it became the single thing capping the throughput of the entire engineering organization, no matter how fast anything upstream got.

So the signal to watch for is not failure. It is this: the thing you are most confident about has become the thing you are waiting on. When your most mature process is also your longest queue, you are not looking at an execution problem. You are looking at an expired assumption.

Separate the need from the implementation

Here is the distinction that most of this conversation collapses, in both directions.

The need git serves is permanent: know who changed what, and be able to go back. That need is not going anywhere, ever. The implementation — full local clones, offline-first, a packfile on every laptop — was always conditional. Anthropic kept the need and threw away the implementation.

Almost every argument about what AI is doing to work gets this backwards. The panic treats a conditional implementation as if it were the need ("if nobody types the code, engineering is over"). The denial does the same thing from the other side ("code review has always worked, so it always will"). Both are defending an implementation and calling it a principle.

Consider what that distinction does to the things our working lives are built on:

The left column is safe. The right column is a set of proxies invented because the left column was hard to observe directly. A résumé exists because your actual work was invisible to a stranger. Years-of-experience exists because judgment accumulates slowly and cannot be inspected. Headcount-as-capacity exists because output was roughly proportional to people.

Each of those proxies was a reasonable bet on a condition. Several of those conditions are now moving, and the proxies are not moving with them.

Three questions that separate durable from expired

Not everything settled is expiring, and that matters — most durable things are durable for good reasons. Git earned twenty-one years honestly. So this is a test, not a prophecy. For anything you rely on:

1. Can you still name the condition it was designed for? If you cannot — if the answer is "this is just how it's done" — you are not following a principle, you are maintaining a fossil. The inability to state the original trade-off is the clearest tell.
2. Has that condition moved, and in which direction? Direction matters more than magnitude. Reversible shifts are noise. One-way shifts — the cost of generating code, the cost of storing data, the cost of starting a company — are the ones that retire ideas.
3. Is it still enabling you, or is it now limiting you? Enabling means you move faster because of it. Limiting means you are waiting on it. The transition between those two states is exactly where obsolescence lives, and nothing crashes to mark the moment.

Run those three on a merge queue in an agent-heavy repo and the answer is obvious. Run them on a hiring process that screens for people who type code quickly, and the answer is also obvious — it is just less comfortable.

What this looks like when it is your career

The honest version of this argument is not "everything you know is worthless." It is narrower and more useful: the concept you built your identity on was probably a proxy, and proxies expire faster than needs.

"I am a backend engineer" is an identity built on a task. "I know what will break at 3 a.m. and I can tell when a design is lying to me" is an identity built on a capability. The first is a proxy for the second, and it was a decent one for twenty years. It is a worse proxy every quarter now.

The clearest evidence we have seen is Anthropic's own account of the Scion team. Every engineer on it would rate Claude as better at writing code than them. Their value was design judgment, understanding how systems interact, and — in their own words — telling the model "no" when it violated a constraint. That is not engineers made redundant by a tool. That is the same need, served by a radically different implementation, and the title on the badge did not change to reflect it.

This is why we organize our practice around capabilities instead of seats, and why "we build products by building people" is a statement about durability rather than sentiment. We wrote about the specific reshuffling of product roles in who ships to production when prototyping is free. This is the layer underneath it: roles are implementations too.

What not to conclude

Three guardrails, because this argument is easy to over-apply:

• Most settled things are fine. The test above will return "durable" far more often than "expired." Double-entry bookkeeping is five hundred years old and is not going anywhere. Age is not evidence of obsolescence.
• Being early is indistinguishable from being wrong, for a while. Anthropic replaced git because it had already hit the wall, not because it predicted one. Retiring a working practice before the condition actually moves is just churn with a better vocabulary.
• The need is your anchor. When you retire an implementation, name the need it served and replace it deliberately. Anthropic dropped the merge queue and put automated conflict resolution and post-merge testing in its place. They did not drop the need for a trustworthy main branch.

Key takeaways

• Obsolescence arrives at things that still work. A failing process announces itself; an expired one performs perfectly and quietly becomes your ceiling.
• Every settled idea is a bet on a condition. When the bet keeps paying, people stop seeing it as a bet and start treating it as a law.
• Separate the permanent need from the conditional implementation. Most arguments about AI and work defend an implementation while calling it a principle.
• The things our careers are built on — titles, résumés, years of experience, headcount as capacity — are proxies invented because the real thing was hard to observe. Proxies expire faster than needs.
• Test anything you rely on with three questions: can you name the condition it assumed, has that condition moved one way, and is it now enabling you or limiting you?
• Age is not evidence of obsolescence, and retiring a practice before its condition actually moves is just churn.

FAQ

What does Anthropic replacing git have to do with anything outside of engineering?

The mechanism, not the subject. Git was the most settled tool in software and it was retired inside one organization in four months — not because it was bad, but because a single condition it assumed moved by twelve times. Any idea you rely on rests on a similar condition. The lesson is to know which one.

How do I tell an obsolete practice from a durable one?

Ask whether you can still name the condition it was designed for, whether that condition has moved in one direction, and whether the practice currently makes you faster or makes you wait. Durable practices survive all three questions. Fossils fail the first one.

Does this mean job titles and degrees are worthless now?

No. It means they are proxies, not needs. The need they serve — demonstrating that you can be trusted with consequential work — is permanent. The proxy was invented because that was hard to observe directly, and it degrades as the underlying work changes shape. Build the capability; treat the credential as a receipt, not the asset.

Isn't this just saying everything is changing?

The opposite. Most settled things are settled for good reason, and the test above will usually tell you to leave them alone. The point is that "it has worked for a long time" is not an argument, and the discomfort of examining it is not evidence that it is sound.

What is the first thing to examine?

Whatever you are most confident about that also has a queue in front of it. Confidence plus a waiting line is the signature of an assumption that expired while nobody was looking.