I spent August reading every first-party account I could find, at least 21 programs from Stripe to Meta to Ramp, looking for the factory. Not one of them built one. Every "factory" in the sample is the same thing: agents, running in parallel, on the process the company already had.

The last time a new kind of power showed up at a factory, everyone bought in immediately, bolted it onto what they already had, and waited thirty years for the payoff. It's happening again in 2026, and the tell is the pull request.

Everyone Bought the Motor. Ford Rebuilt the Floor.

Electricity supplied under 5% of factory horsepower in 1899, 50% by 1919, 75% by 1929. For most of those thirty years, what a factory did with it was swap the steam engine for one big electric motor and keep everything else: the overhead line shafts, the belts, the machines clustered around the power source, etc. Ford rebuilt the floor instead. Between 1913 and 1914 he moved the work past the workers instead of the workers past the work, and chassis assembly fell from 12 hours 28 minutes to 1 hour 33 minutes, by his own account. That's 8x, and it wasn't the motor that did it.

Someone rebuilt the floor this year, just not for code. Alejandro Maza Ayala, Chief Product and AI Officer of Kavak, the Latin American used-car marketplace, told a16z on August 10 that handing employees ChatGPT or Claude produces "no efficiencies," so Kavak did the other thing: "redesign your whole company around the agents," starting with "rebuilding most of your APIs" so agents could use them. Kavak now spends as much engineering effort on evals as on the agents, and the agents handle 96% of customer interactions and 95% of transactions. He says they convert 2.1x better than the human sales team did. In December, with tens of thousands of agents already running the business, Kavak tore the working architecture down and started over.

Now read what "software factory" means in 2026, in the words of the people selling one. Zach Lloyd, Warp's CEO, launched Warp Factories on August 18 with this: "a cloud software factory is an automation loop around the SDLC, where cloud agents triage, spec, implement, review, verify and monitor work. Humans stay in the loop at key decision points." Factory, the company, describes its product as something that "runs delivery inside existing pipelines through ready-to-use GitHub Actions and service accounts." Kyle Daigle, GitHub's COO, introducing the surface that five frontier labs' agents now route through, made it a promise:

"You're still working with the primitives you know—Git, pull requests, issues—and using your preferred compute, whether that's GitHub Actions or self-hosted runners." — Kyle Daigle, COO, GitHub

Around the SDLC, inside existing pipelines, still the primitives you know. That's exactly the motor, bolted onto the shafts that were laid out for people.

Every Factory Ends at the Same Door

The operators are the ones to watch, because they're the only parties who could have rebuilt their own floor and chose not to.

Stripe shifted the programmer to the approve button. By February, over 1,300 pull requests a week were, in Stripe's words, "completely minion-produced, human-reviewed, but containing no human-written code." I take that as a design decision. Nobody's writing, but everyone still signing off.

Anthropic keeps the same gate. Jason Clinton, Anthropic's Deputy CISO, described the company's own pipeline in July: "More than half of all code is being merged by our internal version of Claude Tag while human engineers focus on directing, setting intent, and owning final approval." Humans are still the gatekeepers for half of the merged code.

Warp, whose product is the factory, grades its own by human touchpoints. Its core factory metric, per its August 27 post, is "average human touchpoints per PR." It automates about 30% of its own tasks, and its self-improvement loop ends where everyone's does: "Humans review those suggestions as PRs on the factory definition and merge improvements."

Every operator and vendor in the sample, 18 programs, delivers agent work as a pull request for a person to read. Uber's 70% ships, in Uber's words, "with human reviews/escalations." Ramp's engineers said why when they refused to give their agent a shared service account: "You do not want to knowingly create a vector for unreviewed code to go into the codebase."

And to be clear: this works. PostHog went from 1,441 merged PRs in January to 4,725 in June on roughly 10% more engineers, at a revert rate of 0.2% across everything merged that month, whoever wrote it. That's agents on an ordinary web codebase, and that revert rate is the closest thing to an escaped-defect number anyone in the sample publishes. Bolting the motor to the shafts got real output in 1899, and it's getting real output now.

It's also the ceiling. There's a reason none of these companies took the person off the door, and it isn't caution.

The Self-Graded Test

Maisem Ali at exe.dev named the problem on August 27:

"But the agent was still grading its own work. If it misunderstood what I wanted, it could build the wrong thing, write tests for the wrong thing, and then confidently tell me that everything passed." — Maisem Ali, exe.dev

The agent that writes the code also writes the test that says the code works. Will Wilson, CEO of Antithesis, told Ron Minsky of Jane Street on Signals and Threads in March what happens when the task gets hard enough: "eventually it deletes the tests or eventually it makes the test pass in some trivial way." Minsky: "I do think this is getting a little better, but the phenomenon is still very strong."

The industry's fix is a second model that checks the first. Shopify ran that experiment and wrote it up on July 29: in one audit a model flagged 30+ security holes, and after verification every one was downgraded, dismissed, or reclassified. Zack Deveau, who built the harness, put the cost plainly: "noise sent to a developer is worse than no finding at all." A model judging another model just scales the noise, and not the ground truth.

In July, Anthropic made Claude go back through its own outages and asked it how many outage-related bugs its automated checks would now catch. The answer was about a third, the other two-thirds still would have shipped. That's the best-funded verification program in the industry grading itself, and it's the reason the person is still on the door: nothing behind them can be trusted to say no.

The Number the Agent Can't Edit

There's one kind of place in the sample where the human is already gone, and where it is tells you everything.

Meta's KernelEvolve writes GPU kernels, and its gate isn't a human reviewer:

"Every generated kernel passes through a rigorous validation pipeline that checks both correctness — bitwise accuracy against reference implementations — and performance." — Meta KernelEvolve team

Bitwise. The output matches the reference or it doesn't, and the agent can read that verdict but can't edit it. On that footing the loop closes: agent runs post-train specialized models with measured kernel speed as the reward, and the system gets better with nobody in the loop.The outcomes: 100% on KernelBench's 250 problems, 160 ATen operators at 100% correctness across 480 configurations, more than 25% training throughput on MTIA, more than 60% inference throughput on Andromeda in production. Baseten, a startup, published the same shape on August 28: kernels "identified, proposed, and implemented entirely by our agentic framework," kept only if they "pass correctness and end-to-end performance checks," now in production with latency down 42.3% on one image model. Nicholas Carlini, a researcher on Anthropic's Safeguards team, got the same result for the same reason when sixteen agents wrote a C compiler with a 99% pass rate on most compiler test suites: "It's important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem."

Kavak's number is a conversion rate. Meta's is bitwise accuracy. Baseten's is latency. In every case the agent can read the score and can't touch it.

Now look at what the factories call "self-improving." Uber's post files its loop under future tense: "We are working on an automated way to record papercuts from agent skill executions and auto-generate skill updates from the collected traces." Kiro's post titled Continuous Prompt Evaluation, August 21, discloses its author in the body: "This article focuses on evaluating human-authored system prompt and configuration changes." Warp's loop, above, ends at a human merging a PR.

The pattern is exact. Where correctness is a number, the loop closes and the human leaves. Where correctness is a review, the loop ends at a person. Self-improvement isn't a feature you add to a factory. It's what happens on its own when the machine can say no, and what never happens when it can't.

The Floor Exists. Nobody Put Agents on It.

So the move is obvious: make application code the kind of place where correctness is a number. Zero of 13 operators did it. Not one changed the language, the runtime, or the codebase the agents write into. Stripe's monorepo is heavily typed, and Stripe typed it years ago, by humans, for humans, and describes its homegrown libraries as "natively unfamiliar to LLMs." Meta, the largest operator in the sample, went the other direction. Mark Harman, a research scientist there, argued in February that agentic pace is "scaling the cost of false positives and test maintenance to breaking point," and Meta's answer is tests that "are generated on-the-fly for each code change and do not reside in the codebase." Fewer durable checks, not more.

TigerBeetle, a financial database that runs 2,000 years of simulated testing every 24 hours against its own code, is on the opposite end. Its style guide requires two assertions in every function, and its simulator, extended again on August 20, can replay any failure it finds on demand. It's the floor: the densest set of machine checks on any codebase in the sample, built for humans doing safety-critical work, years before agents.

And there's no agent layer on it. No AGENTS.md, no CLAUDE.md, no agent lane in CI. On August 26, one day before Uber's post, the maintainers closed an agent-assisted contributor's open pull requests with one sentence: "we're not accepting agent driven contributions at the moment!"The account had opened 30 pull requests since July 20. Two merged, both changelog-link fixes. The refusal was posted on #3887 and #3919 seven seconds apart. If any codebase on earth could let a machine decide whether an agent's change is safe, it's this one. 2,000 years of simulation a day is more scrutiny than any reviewer will ever give a diff. The maintainers didn't run the agent's code through it. A person said no, by hand, the same way the door works everywhere else.

That's the shape of 2026. The motor is at Uber, Stripe, and Anthropic, bolted to a floor laid out for people. The floor is at TigerBeetle, with no motor on it. Nobody has put them in the same building, and the building isn't a mystery: application code where a wrong change fails to compile instead of failing in review, one place to commit so the bug where the event fires without the row can't be written at all, and a core with no wall clock and no ambient randomness, so the whole application replays from a seed. On that floor an agent's change runs through thousands of simulated crashes before a person opens the diff, and the agent improves against a verdict it can't edit, the way Meta's kernels do. No engineer can hold that in their head, and that's the point: the machine holds it. Every stack you've ever worked on was built to fit inside a human's head. A software factory can't be, or it isn't one.

Agents won't build that floor on their own. They're trained on the code humans wrote, and the code humans wrote is the bolt-on code: a service around a database, extensive tests beside the logic, a review at the end, etc. That's just how software has always been built. Left alone, an agent will rebuild that floor for you in whatever language you hand it. Getting the other kind takes a compiler and a simulator that refuse the usual shape, and someone who designed the floor that way before the first agent touched it. Different code needs a different floor, and the floor has to come first.

Ask Which Number It's Allowed to Fail

The only places anyone has built something recognizably AI-native are the places where correctness was already a number. Compilers. Kernels. Everywhere else, the factory is a very fast way to fill a review queue.

David Crawshaw, who co-founded Tailscale and now exe.dev, got closer than anyone. His line from June: "With agents, CI is useless, the merge queue is vastly superior." His company merges without peer review and runs the whole test suite synchronously in the queue. And he did it by changing the order of the checks, not the code the checks run on.

Everyone has the motor. Nobody has rebuilt the floor.

Next time someone talks about their software factory, skip the throughput slide. Ask which number the agent is allowed to fail, and who owns it.

The second time it was my day job. At Mesa, a San Francisco systems startup rebuilding version control for AI agents, I owned a few surfaces: the Python SDK, an AI code reviewer, my first real systems work inside a Rust filesystem. The MCP server is the one that taught me the most. Twenty-two tools, stateless, an OAuth 2.1 authorization server in front, cancellation threaded end to end so an agent that gives up mid-request doesn't leave work running behind it.

Here's what doing it twice taught me. The best test harness for an agent-facing product is an agent. My loop was to point a coding agent at the server cold. No docs, no system prompt, nothing but the tools. Then watch. What does it reach for first? Where does it stall? Which tool does it use in a way I never predicted, and which "obviously useful" tool does it never touch? You can interview human users. Agents you can just run, again and again, at almost no cost. It's the fastest product feedback I've ever had.

That loop forces a discipline: the instructions have to live inside the tools. If the agent needed context I hadn't shipped in a tool name, a description, or an error message, I treated that as a bug in the surface, not a gap in the prompt. A human gets onboarding, tooltips, a support channel. An agent gets your tool list, once. Either the product explains itself at the boundary or it doesn't work.

Auth stops looking like plumbing, too. A human forgives a clunky login once a month. An agent hits your authorization surface every session. For agent-facing products, the door is the product. "Connects instantly from any client" versus "requires a support ticket" is the difference between being infrastructure and being a demo.

If you're adding agent access to your product this year: the specs are good. Read them before the blog posts. Then hand what you built to an agent with no extra context, and watch. It will tell you what your product actually is faster than any user ever has.

Now read the other column. The most powerful model the public has ever been handed ranks #64 of 152 on output speed: 60 tokens per second, and a 108-second wait for the first one, against a field median under three seconds. On price it sits at #139 of 152. Simon Willison called it “something of a beast. It’s slow, expensive” and, $110.42 of tokens later, capable.

For three years, model intelligence was the bottleneck, so we bought it with time. That trade just closed. The scarce resource now is the hour, and every lab on earth is retooling to win it. From here forward, the speed column picks the winners.

The only question was “is it smarter?”

Since ChatGPT arrived in late 2022, you have judged every release the same way. You opened the benchmark table, found the bold column, and asked whether the new model could do something the old one couldn’t. Speed was the discount tier. “Mini,” “flash,” and “turbo” were polite words for cheaper and worse, the variants you routed boring traffic to while the real model handled everything that mattered. The waiting was rational: a model that took 90 seconds and got the architecture right beat one that answered instantly and confidently wrong. Three and a half years of that trained everyone to treat tokens per second as an implementation detail.

Then the models stopped failing at the work.

The bottleneck moved

The bottleneck did not move on June 9. It had been moving for months. Something flipped in December, I argued back in February, when the models picked up the long-term coherence and tenacity to hold hours-long agentic sessions in Claude Code, Codex, and other harnesses without falling apart. Fable 5 raised the ceiling, and the early testers hit the same two notes. Ethan Mollick, the Wharton professor who got early access, called it “a genuine jump in capability: I could feed it a 15 page design document for a project and it would work for 9+ hours and deliver terrific results.”. Dan Shipper, whose team at Every tested it for a week, found it “routinely uses 500k to 1M tokens on tasks” and is “very slow, token-hungry. Using this thing for regular knowledge work is like squashing an ant with a rocket launcher.” The question that defined the last three years, “can the model do this at all?”, is retiring. The sentence replacing it is half brag, half complaint: “my agent opened a genuinely impressive refactor PR, and it took 20 hours.”

Engineers inside the labs feel the inversion too. Sherwin Wu, an engineer at OpenAI, wrote in February that GPT-5.3-Codex

“was the first model where the wall clock time of the model working seemed clearly longer than the wall clock time of me working. The feeling of being a bottleneck now is very real!”

Intelligence leads, meanwhile, stopped lasting. GPT-4 held the top of the leaderboard for about a year. Stanford’s AI Index has six labs within 79 Elo points, and the best Chinese model within 2.7% of the best American one despite a 23-to-1 US investment advantage. A capability lead is a wasting asset measured in months. Speed is the axis nobody has saturated.

The speed race has already started

Google’s fast model beats Google’s smart model

Google led its newest generation with the speed tier. Gemini 3.5 Flash, shipped at I/O in May, outperforms Google’s own frontier model on most agentic benchmarks while running, in DeepMind CTO Koray Kavukcuoglu’s words, “four times faster than comparable frontier models.” It costs triple what its predecessor did. This week, Xiaomi announced MiMo-V2.5-Pro-UltraSpeed: a trillion-parameter model that Xiaomi says clears 1,000 tokens per second on a single 8-GPU node, priced at 3x the standard rate for roughly 10x the speed. The launch tweet:

“Speed changes everything.”

DeepSeek, Alibaba, and Z.ai shipped fast variants the same quarter. The fast tier used to be where intelligence went to die. This spring it became the marquee release.

Paying more for the same model, sooner

In February, Anthropic launched fast mode for Claude Opus at six times the standard price, since cut to 2x. The docs are explicit that the only thing you are buying is time: “Fast mode is not a different model… You get identical quality and capabilities with faster responses.” OpenAI sells the same inversion: GPT-5.5 spans a 5x price range from Flex to Priority with the model held constant. Cursor prices its coding agent the same way: Composer’s fast variant has identical intelligence at six times the price per token. Every pricing page you have ever seen sold the premium tier on more: more features, more seats, more storage. Premium AI in 2026 sells the same capability, sooner.

Thariq, an engineer on the Claude Code team, framed the fast product on launch day: “Use it when you want to be locked in, like when iterating on a design or fixing an incident vs multi-Clauding in the background. It’s more expensive because it uses more compute, but it’s the exact same intelligence.”

Twenty billion dollars says the next constraint is silicon

In December, Nvidia paid a reported $20 billion, the largest deal in its history, to license Groq’s low-latency inference technology and hire its founder. By March it had canceled a GPU it announced six months earlier and put a Groq-derived inference rack in its place. OpenAI signed a reported $10 billion deal for 750 megawatts of Cerebras wafer-scale systems dedicated to low-latency inference; Cerebras went public in May and jumped 70% on day one. OpenAI’s Sachin Katti, announcing the deal: “Cerebras adds a dedicated low-latency inference solution to our platform. That means faster responses, more natural interactions, and a stronger foundation to scale real-time AI to many more people.” A Toronto startup called Taalas etched a compressed 8B Llama model directly into silicon and demoed it at a claimed 17,000 tokens per second. Google markets its newest TPU as its first built “for the age of inference”; Microsoft brands Maia 200 “the AI accelerator built for inference.”

The talent market moved with the money. The 2025 poaching war was over researchers, with $250 million packages on the table. The marquee poach of June 2026 was a chip engineer: Anthropic hired one of the first engineers OpenAI ever put on its custom silicon program, while Apple pays emergency retention bonuses to keep its hardware people away from OpenAI. The engineer Anthropic poached describes his new role as “perplexity per picojoule.”

That’s a job title now.

Why speed compounds

Cerebras ran the same agentic request against Kimi K2.6 twice: 163.7 seconds through the model’s official endpoint, 5.6 seconds on its wafer-scale silicon. Same weights, same answer, 29 times sooner. That is how much speed is already on the table without anyone training a smarter model.

Then there’s the loop that decides the race: AI is starting to build AI. Five days before Fable 5 launched, Anthropic published When AI builds itself, reporting that Claude now authors more than 80% of the code Anthropic merges, and concluding that in a world of automated research, the pace of progress “becomes determined entirely by the availability of compute (or the speed of discovering various efficiencies in algorithmic training or inference).” Dario Amodei put it more plainly in a June 2026 policy essay: “The iterative ability of AI to build even better AI may supercharge that growth even further.” In May, Anthropic hired Andrej Karpathy onto pre-training specifically to use Claude to accelerate the research that builds the next Claude. If that loop is real, the lab whose researcher-agents finish in one hour instead of twenty takes twenty times as many turns at it.

Run the arithmetic on that. Two labs start the year with the same model: same benchmarks, same floor, same ceiling. One closes a research loop in an hour, the other in twenty. A week in, the score is 168 experiments to 8. And the cycles stack, because every loop ends with a slightly better model running the next one: by Friday the fast lab is iterating with a model the slow lab won’t meet until spring. Hold that pace for a quarter and the two labs no longer share a ceiling. Same weights in January. Same ideas, same talent. The clock made one of them the frontier lab and the other a fast follower.

That is the leapfrog. A speed lead at equal intelligence converts into an intelligence lead, and it keeps converting for as long as the loop runs. It also reprices the silicon deals: twenty billion for Groq and ten billion for Cerebras is what turns at the loop cost in 2026. Speed stops being a user-experience feature and becomes the rate constant on the most important feedback loop in the industry.

By the end of 2026

Tokens per second becomes a launch-day headline number. Sundar Pichai already quoted one on stage at I/O. Speed guarantees become contract terms: Azure already sells a tier promising 99% of GPT-5.5 requests above 100 tokens per second.

Speed may also turn out to be the first moat in this industry that holds. Intelligence crosses the Pacific in months; Epoch AI puts the open-weight lag at four months. Speed hasn’t crossed: the same DeepSeek V4 weights anyone can download run about 48 tokens per second on DeepSeek’s own API and three times faster on Nvidia’s newest racks. Benchmark scores can be distilled across a border. Tokens per second have to be manufactured on one side of it. And the lab that holds the speed moat re-mints its intelligence lead every cycle the loop turns.

Anthropic is so capacity-constrained right now that it will pull Fable 5 from subscription plans on June 22, thirteen days after launch. That is what it looks like when demand for intelligence outruns anyone’s ability to serve it. The 20-hour PR is an artifact of this exact moment: models smart enough to finish the work, infrastructure too slow to finish it while you’re still at your desk.

Watch the other column

Anthropic just proved it can build the smartest model in the world: first out of 152. It ships at 64th in speed. Somewhere in the gap between those two rankings is the next phase of this industry, and every lab, chipmaker, and sovereign wealth fund can see it. The next launch that matters may not move the intelligence leaderboard at all. It will decide who moves it next.

When it lands, skip the benchmark table. Look up the tokens per second.

That bargain is over, and it’s over because AI got good at the hard languages.

The hard languages got easy first

Two years ago, GPT-4 couldn’t write a Rust function without hallucinating crate names. By April of 2026, Claude Opus 4.7, GPT-5.5, Gemini 3.1, and DeepSeek V4 had all cleared 80% on SWE-bench Verified within weeks of each other. The labs are openly optimizing for systems work: concurrency bugs, race conditions, and architectural flaws identified during the planning phase.

The best one-tweet explanation came from CtrlAltDwayne last month:

“The best argument for Rust in 2026 is not memory safety or performance. It is that AI writes better Rust than it writes C++. The compiler feedback loop is so tight that models self-correct in real time. Every error message is a free training signal. Rust was accidentally designed for AI-assisted development 10 years before anyone knew that mattered.” via X.com

The same logic applies, to varying degrees, to Go and Swift. Strong type systems plus fast compile-and-check loops give agents the tightest iteration cycle. The systems languages that were hardest for humans turn out to be the easiest for agents.

What actually shipped

Look at what landed in a single quarter.

Microsoft rewrote the TypeScript compiler in Go. The team behind the most-used superset of JavaScript shipped TypeScript 7.0 beta last week, roughly 10x faster than 6.0, by porting the decade-old TypeScript codebase to Go. Anders Hejlsberg’s reasoning: Go delivered most of the performance benefit at a fraction of the engineering cost. The biggest JS/TS shop on earth picked a harder, faster language for its flagship tool, and they did it because the effort calculus changed under them.

Nicholas Carlini, a researcher at Anthropic, orchestrated 16 parallel Claude agents to write a production C compiler in Rust. 100,000 lines. It boots Linux 6.9 on x86, ARM, and RISC-V. It compiles QEMU, FFmpeg, SQLite, PostgreSQL, and Redis. It runs Doom. Total cost: just under $20,000 across nearly 2,000 Claude Code sessions.

A C compiler written in Rust used to be a graduate thesis. It isn’t anymore.

Steve Klabnik, a 13-year Rust veteran who co-wrote The Rust Programming Language, built a new systems language called Rue in two weeks with Claude. Roughly 70,000 lines of Rust. His own words:

I’ve gotten further in the two weeks I’ve been working on it this time than the month or two I spent last time.

Andreas Kling, creator of the Ladybird browser and a career C++ engineer, ported Ladybird’s JavaScript engine from C++ to Rust in two weeks by directing Claude Code and Codex through hundreds of small prompts. Roughly 25,000 lines of Rust, byte-for-byte parity with the C++ original, zero regressions across 65,000+ combined test262 and Ladybird tests.

“The same work would have taken me multiple months to do by hand.”

None of this was possible in 2024. In 2025 it was marginal. In early 2026 it’s becoming commonplace

So much for “but the ecosystem”

The strongest argument for Python and JavaScript was never the languages themselves. It was the ecosystems: FastAPI, Django, PyTorch, React, Next.js, npm’s 4 million packages. “Our team ships features in days because the ecosystem already solved 90% of every problem.” That was decisive for the last 10 years. It’s been quietly eroding for the last 2.

When you import pydantic, the entire validation core is a Rust library. Polars, the pandas alternative, is Rust. Hugging Face tokenizers is Rust. orjson is Rust. The JetBrains 2025 Python survey caught the telemetry: Rust usage for Python binary extensions jumped from 27% to 33% in one year.

The Python ecosystem is increasingly a Rust ecosystem wearing a Python hat.

The plumbing is following the same trajectory. Astral, founded by Charlie Marsh in 2022, shipped ruff, uv, and ty. All three are written in Rust, and all three went from zero to hundreds of millions of monthly downloads. On March 19, 2026, OpenAI acquired Astral; the internal justification was that uv saves Codex roughly one million minutes of compute per week. Ten weeks earlier, Anthropic acquired Bun (7M monthly downloads, 89K GitHub stars) and framed it as “essential infrastructure for AI-led software engineering.” Evan You’s VoidZero shipped Rolldown-Vite, a Rust bundler that cut GitLab’s 2.5-minute build to 40 seconds with 100x less memory.

Lee Robinson, VP of Product at Vercel: “We’ve reached peak optimization with JS.”

What’s left of “but the ecosystem” is this: the packages you import in Python and JavaScript are increasingly wrappers around code written in languages you were told you couldn’t ship in. Now you can ship in those languages directly, and the wrapper is starting to look like overhead.

Why patch when you can port?

The old open-source bargain had a positive feedback loop. You pick Python because it’s easy. You find a bug in a dependency. You fix it. You upstream the fix. The ecosystem gets healthier.

Agents broke that loop in a specific way: the unit of contribution shifted from the patch to the port.

Armin Ronacher, the creator of Flask, ported his Rust library MiniJinja to Go in January using an agent. The run lasted 10 hours, 3 supervised and 7 unattended. His actual human time was 45 minutes. The API cost was $60. If porting a library across languages is a 45-minute job, the case for upstreaming a fix to someone else’s library gets weaker every month. Why patch what you can fork?

His own observation:

For me, the value is shifting from the code to the tests and documentation. A good test suite might actually be worth more than the code.

The loop that built PyPI and npm still works today. It is not obvious it works in 2028.

Where this argument breaks

This isn’t a clean sweep. A few things are worth admitting.

First, sometimes the right answer is still the old answer. Prisma removed its Rust query engine in favor of a TypeScript/WASM core: bundle size dropped 85%, queries got up to 3.4x faster. Native Rust binaries are hostile to serverless runtimes. PyTorch still owns roughly 85% of deep-learning research, and that isn’t changing because the model weights don’t care what language you wrap around them.

Secondly, AI is not equally good at every systems language. Smaller languages like Zig, Haskell and Gleam don’t have the same quality when AI-generated (for now).

Training data shapes what the model can help you with. Rust and Go won the lottery because they were popular enough to flood GitHub. Zig, Haskell and Gleam are still on the wrong side of that curve.

The reason the shift is permanent

The old defense of Python and TypeScript was really a defense of the developer experience. Those languages were chosen because they minimized the friction between a human’s idea and a shipped product. Rust was never slower at runtime; it was slower at 2am when you had to ship.

Agents do the hard part now.

The human’s job shifted from “writing the code” to “architecting the system and reviewing the output.” In that workflow, Python’s ergonomic advantages matter less every quarter, and a harder language’s runtime advantages compound every day you run the service in production.

Armin Ronacher, in his February essay A Language For Agents:

The biggest reason new languages might work is that the cost of coding is going down dramatically. The result is the breadth of an ecosystem matters less.

The last twenty years of language choice were shaped by a single constraint: humans write the code, and humans are slow at low-level languages. That constraint is gone. Stack Overflow’s 2025 survey had Rust as the most-admired language for the tenth consecutive year at 72%, with Gleam at 70%, Elixir at 66%, and Zig at 64%. The stated preference was always there; the tooling finally caught up to the preference.

Karpathy framed the broader picture in February:

“LLMs change the whole constraints landscape of software completely. Hints of this can already be seen, e.g. in the rising momentum behind porting C to Rust.” He added that “even Rust is nowhere near optimal for LLMs as a target language.”

Today’s winner is the opening move, and the endgame is somewhere further out.

The cleanest statement of the new regime came from @RealRichomie on X on April 24:

The future of programming won’t be languages easiest for humans. It’ll be languages easiest for agents. We just shipped a Mac app where our engineers didn’t know a single line of Rust (or Tauri) beforehand. Result: ~1/10th the size… highly performant. Agents are the new programmers.

A shipped app, in a language nobody on the team knew, one-tenth the size of the Electron version, faster at runtime. The humans never had to learn Rust to get there.

The next project you start doesn’t have to default to Python.

This post is an open-source step in that direction that uses your existing membership to Claude Code / Codex / Gemini.

The Review Gap

Anthropic reports that 70–90% of its code is AI-generated. Google was at 25% almost 2 years ago. Microsoft was at 30% a year ago. These aren’t projections. These are earnings calls.

The code is fine. It compiles, it passes tests, it handles edge cases. But it also introduces logic errors that a second pair of eyes would catch. It misses security implications that aren’t in the prompt. It creates subtle regressions because it doesn’t know the full history of why things are the way they are.

Today, the tools that review AI-generated code like CodeRabbit, Greptile, and the rest all operate at the pull request level. The agent writes code. It gets merged. A reviewer comments. A human reads the comments. The human makes the fixes or throws it back into a new agent session anyways.

The problem with this model isn’t just speed. It’s that the agent that wrote the code never sees the critique. By the time findings surface in a PR review, the agent’s session is over. The context window that held the reasoning, why it chose that approach, what tradeoffs it considered, what it was trying to accomplish, is gone.

The human reviewer is now looking at a diff without the reasoning that produced it. And the volume of AI-generated changes has already outpaced the volume of human attention available to review them. This lets many issues slip through the cracks. Yesterday, Amazon internally had a ‘deep dive’ to develop a plan to tackle severe issues caused by GenAI coding tools.

The Insight

What if the code review didn’t happen after the PR? What if it happened during the agent’s session, while the context window still held the reasoning?

And what if the findings didn’t go to a human? What if they went back to the same agent that wrote the code?

Think about what that agent can do with a code review that a human can’t: it knows why it made every decision. When it sees “potential SQL injection on line 42,” it can evaluate: “I made this choice because the input is already sanitized upstream — wait, actually, it isn’t in this code path. Valid finding, fixing now.” Or: “This finding isn’t relevant because I’m using a parameterized query builder.” The agent has the context to make that judgment call. This happens instantly, without the user’s input.

This is the feedback loop that doesn’t exist yet. Review that happens alongside generation. Findings that go to the writer, not a third party. Self-correction by the entity that has the most context to evaluate what’s actually wrong.

That’s what I helped build.

Saguaro

Saguaro is an open-source background daemon that reviews AI-generated code and feeds findings back to the same agent that wrote it.

Here’s what it looks like in practice:

Turn 1:
  You: "Add user authentication to the API."
  Claude Code: writes auth handlers, middleware, token logic
  Saguaro: reviews in background, without the user knowing

Turn 2:
  Claude Code: "I see some issues with my implementation —
  there's a potential SQL injection in the query handler and
  I'm not validating auth tokens on the admin routes. Fixing now."

→ Claude self-corrects. You typed nothing.

You didn’t configure anything. You didn’t write any rules. You didn’t even know Saguaro was running. The agent just got smarter about its own output.

How It Works

When you run sag init, Saguaro installs as a Claude Code hook. From that point on:

1. You tell Claude to build something. Normal prompt. Nothing different.
2. Claude writes code. Normal Claude Code experience.
3. Stop hook fires. Saguaro diffs the changes and queues a background review with the daemon. This happens invisibly, no spinner, no blocking, no indication to the user.
4. Daemon reviews. A background process (local HTTP server, SQLite job queue) reviews the changes like a senior staff engineer. It gets the agent’s own summary of what it was building for context. It can read files across the codebase to understand the full picture.
5. Next turn. When Claude finishes its next piece of work and the stop hook fires again, Saguaro checks for completed reviews. If there are findings, they’re injected into Claude’s context.
6. Agent self-corrects. Claude sees the findings, evaluates them against its own reasoning, and fixes what’s actually wrong. It dismisses what isn’t relevant, it has the context to judge.

The daemon only flags issues. No style nits. No formatting opinions. No “consider renaming this variable.” Bugs, security gaps, regressions, dead code, performance issues. If nothing is wrong, silence.

The daemon self-spawns on demand and auto-shuts down after 30 minutes of inactivity. SQLite handles the job queue. Diff deduplication via SHA256 hashing ensures the same code is never reviewed twice. The infrastructure is minimal by design, it’s a local dev tool, not a service.

Why False Positives Are Lower

This is the part that’s hard to explain without seeing it, but easy to understand once you do.

When CodeRabbit reviews a PR, it sees a diff. That’s it. It doesn’t know what the developer was trying to do, what constraints they were working under, or what tradeoffs they considered.

When Saguaro’s daemon reviews, it gets the original agent’s summary: “The developer described their work as: adding JWT-based authentication with refresh token rotation.” Combined with read-only access to the full codebase, the reviewer has meaningful context about intent, not just the diff.

And when the findings go back to the original agent, that agent can evaluate them with full context. A human reviewer might see “potential null pointer” and flag it. The original agent knows that the value is guaranteed non-null by the validation layer it set up three files ago. The feedback loop is tighter and smarter at both ends.

The Rules Engine

The daemon works out of the box with zero configuration. But teams that want deterministic enforcement of specific patterns can write rules.

Saguaro rules are markdown files with YAML frontmatter, stored in .saguaro/rules/:

---
id: adapter-as-boundary-layer
title: CLI and MCP must use the adapter layer
severity: warning
globs:
  - "src/cli/**/*.ts"
  - "src/mcp/**/*.ts"
---

CLI handlers and MCP tools must import from `src/adapter/`, never directly
from implementation modules like `src/ai/`, `src/daemon/`, or `src/indexer/`.

### Violations
import { runReviewAgent } from '../../ai/sdk-reviewer';

### Compliant
import { runReview } from '../../adapter/review';

Rules have globs for file matching, severity levels, and violation/compliant examples that teach the reviewing AI exactly what you mean. Saguaro matches changed files against rules using minimatch and injects relevant rules before the agent writes code (PreToolUse hook) and validates after (Stop hook).

You can write rules manually, or let Saguaro generate them: Saguaro rules generate scans your codebase and proposes rules that reflect actual patterns in your code. We use this on our own codebase: Saguaro reviews Saguaro, with 14 rules covering architectural boundaries, security patterns, and serialization conventions.

The rules engine runs inline alongside the daemon. Both can operate independently. Together, you get the broad coverage of a senior staff engineer review plus the precision of deterministic rule enforcement.

What It Costs

Nothing, if you already have a coding agent.

Saguaro uses your existing Claude Code, Codex, or Gemini subscription. No API key needed. No external account. No billing dashboard. No surprise invoices. Everything runs locally. Nothing touches our servers.

If you have a coding agent, you have Saguaro.

Why Open Source

Saguaro is Apache-2.0. No proprietary server, no hosted component, no telemetry. Your code goes to the AI provider you already use. We have no servers to send it to even if we wanted to.

We’re open-sourcing this because the “AI code review” layer is going to exist, it has to, given the volume of AI-generated code. The question is whether it’s an open standard that works with any provider and lives on your machine, or a vendor-locked feature inside one platform. We’re building the open version.

Try It

npm install -g @mesadev/saguaro

sag init

Then go back to Claude Code and start coding. That’s it.

Saguaro wires up the hooks, spawns the daemon on demand, and starts reviewing in the background. The first time Claude finishes a task, Saguaro reviews it. The next time Claude speaks, it’ll start fixing things you didn’t even know were wrong.

That’s the moment you’ll get it.

GitHub | Docs

If you find a bug, open an issue. If you have a rule idea, open a PR. The best rules will come from the community, not from us.

“Maybe the best agent architecture is almost no architecture at all.” — Andrew Qu, Vercel’s Chief of Software

Vercel isn’t an outlier. They’re a case study in a pattern the developer tools industry is desperately trying to ignore: AI agents don’t want the tools we’re building for them. They want bash, a file system, and git. The developer tools industry is literally spending billions building in the opposite direction.

The Gold Rush Nobody Questioned

AI-native developer tools are the hottest category in tech. Eight companies in the space (Claude Code, Cursor, Replit, Lovable, Devin, Base44, Emergent**,** and Bolt) have already crossed a combined $5 billion in annual recurring revenue. Investors see transformation.

“AI now creates millions of software builders,” angel investor Jaymin Shah wrote in his post. “When the number of builders expands, the number of products grows exponentially.”

He’s right about the growth. But nobody in this gold rush stopped to ask a basic question: what do the AI agents building all this software actually prefer to use?

The market says the answer is AI-native platforms, specialized frameworks, and new protocols. The data says it’s bash.

Google and Accel recently reviewed over 4,000 startup pitches. Roughly 70% were rejected as “wrappers”, thin UI layers on existing models with zero underlying innovation. Of the 14,000 AI startups launched in 2024, over 5,600 have already shut down. Forty percent failure in under 24 months. And Gartner predicts 30% of agentic AI projects will fail. Not from lack of tooling, but from poor data foundations.

The industry is solving the wrong problem. It’s building tools nobody asked for.

Agents Vote With Their Tokens

When you look at what AI agents actually choose to use, measured by adoption, reliability, and cost, the picture is pretty clear.

The most popular AI coding tool in the world is Claude Code. It earned the #1 spot in the Pragmatic Engineer’s 2026 survey, with 46% of developers calling it “most loved.” Four percent of all public GitHub commits now come from it, projected to exceed 20% by year’s end. And its architecture is, to a first approximation, a terminal. Its tools are bash, grep, file read, file write, and git. That’s it. An open-source project called learn-claude-code demonstrated that you can reproduce its core agent loop in roughly 30 lines of Python.

Thariq, an engineer on the Claude Code team at Anthropic, summarized the philosophy in two threads: “Your agent should use a file system” and “Bash is all you need.”

GitHub reached a similar conclusion from the opposite direction. They reduced Copilot’s tool count from over 40 to 13 core tools. Performance improved. Pre-expansion accuracy jumped from 19% to 72%. SWE-bench scores went up 2–5 percentage points. Fewer tools, better results.

Then there’s MCP, the Model Context Protocol, an open standard created by Anthropic for connecting AI agents to external tools and data sources. Independent benchmarks show MCP server integrations are 10–32x more expensive than equivalent CLI commands and achieve only 72% reliability compared to CLI’s 100%. In one test, an MCP agent consumed 44,000 tokens for a query that a CLI agent handled in 1,365. Perplexity’s CTO Denis Yarats publicly announced in March 2026 that the company is moving away from MCP.

The most telling signal comes from Anthropic itself. Their recently introduced Skills feature converts what would have been MCP tool calls into filesystem-based patterns, saving 98.7% on token usage, from 150,000 tokens down to 2,000. The company that created MCP is routing around its own protocol.

Pieter Levels, the indie developer with dozens of shipped products, put it bluntly:

“Thank god MCP is dead. It’s all dumb abstractions that AI doesn’t need because AIs are as smart as humans so they can just use what was already there — which is APIs.”

The Ergonomics Mismatch

If you want to understand why agents keep reaching for bash over purpose-built tools, you have to understand what developer tools actually are.

We built syntax highlighting because humans can’t parse raw text at speed. We built autocomplete because we type slowly and forget API signatures. The whole industry is, at root, a set of workarounds for the limitations of the human brain.

AI agents don’t have those limitations. They parse tokens, not pixels. They hold entire codebases in context. They can generate, resolve, and maintain dependency trees without ever seeing a visual interface. Every “feature” we built for human ergonomics becomes friction for a non-human user that processes text natively.

Alain Di Chiappari articulated this in an essay:

“Bash was born in 1989. The most mediocre model running at this time knows bash better than any person in the world. Bash is the universal adapter. It is not a coincidence that coding agents are shifting from complex and expensive MCP configurations to a simple agent loop with bash as a way to interact, literally, with the world. The oldest tool turned out to be the most future proof.”

A January 2026 paper on arXiv titled “From Everything-is-a-File to Files-Are-All-You-Need” traced this phenomenon academically, arguing that Unix’s uniform read/write interface, designed in the 1970s, maps directly onto how AI agents want to interact with the world. The agents face an “interface proliferation problem” when forced to juggle REST APIs, SQL databases, vector stores, and cloud consoles. A file system collapses all of that into something composable.

At Dust, engineers noticed something remarkable: their AI agents were spontaneously inventing filesystem-like syntax for searching company content, using patterns like file:front/src/some-file.tsx, instead of the semantic search interface they’d been given. The agents weren’t told to use filesystem patterns. They preferred them.

We built a $50 billion industry around compensating for the limitations of the human brain. Then we welcomed a user that doesn’t have a human brain and tried to sell it the same products.

The Framework Funeral

Agent frameworks (LangChain, CrewAI, AutoGen, and many others) were supposed to make building AI agents easier. They offered abstractions for tool calling, memory management, chain-of-thought reasoning, and multi-agent orchestration. A reasonable bet.

Here’s how that bet played out.

Microsoft placed AutoGen into maintenance mode in October 2025. BabyAGI was archived in September 2024 after receiving 20K+ stars. Octomind, a company that used LangChain in production for over a year, ripped it out entirely and published a detailed explanation: “When we were spending as much time understanding and debugging LangChain as building features, it wasn’t a good sign.”

Meanwhile, HuggingFace’s SmolAgents fits its core agent logic in roughly 1,000 lines of Python. It reduces LLM calls by 30% compared to traditional agent frameworks. The model writes standard Python rather than navigating complex JSON schemas or framework-specific abstractions.

Anthropic’s own guidance, published in their “Building Effective Agents blog post, is perhaps the most damning evidence: “The most successful implementations weren’t using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.”

The company that builds Claude, the model powering the most popular AI coding agent, is telling developers not to use frameworks.

Frameworks were always a compromise: trading flexibility for velocity because humans couldn’t hold enough complexity in their heads. Agents can hold the complexity. The trade-off no longer makes sense.

What Agents Actually Need

So if agents don’t need our tools and they don’t need our frameworks, what do they actually need?

The honest answer is mostly boring: well-documented APIs with stable contracts, reliable file systems, clean version control semantics, structured I/O, and sandboxing. The kind of infrastructure that has existed in some form for decades.

But there’s a catch. The old infrastructure works at human scale. Agents operate at a different scale entirely, and that’s where genuine gaps emerge. Not in the application layer, but in the infrastructure layer underneath it.

Agents shouldn’t need to clone an entire repository to read three files. They need virtual filesystems that provide lazy, partial access to remote code. Agents working in parallel shouldn’t collide in merge conflict cascades. They need version control with native concurrent write semantics and mutable change primitives. When an agent introduces a subtle bug, you need to query what model, prompt, and context produced the change. Git’s commit metadata doesn’t carry that provenance. And as organizations spin up hundreds of agents per repository, they need permission scoping at the forge level: repo-scoped API keys, path-restricted access, sandbox boundaries enforced by the platform rather than by the agent’s good behavior.

Aaron Levie, Box’s CEO, said it directly on CNBC in March 2026:

“AI agents will be the biggest users of software in the future. And agents actually need a file system to be able to do their work.”

A handful of companies have started building at this layer. Instead of another dashboard or another MCP integration, they’re working at the protocol level: VCS primitives, virtual filesystems, change semantics. The boring infrastructure that agents actually touch.

The existing tools aren’t dying for humans. Developers still need syntax highlighting and dashboards and visual debuggers, and companies like Cursor are building $2 billion businesses serving that need. Enterprise environments still need the governance that protocols like MCP provide: OAuth, audit trails, per-user permissions. These are real requirements for human developers working with AI.

But the growth market isn’t human developers anymore. The next hundred million “developers” won’t be human. And the infrastructure that earns their usage will look nothing like the tools we built for ourselves.

The Right Question

The developer tools industry keeps asking how to make its products AI-native. That question already contains the wrong assumption. Agents don’t need tools. They need primitives. Interfaces. Protocols. Plumbing.

Now, there’s a version of this argument that falls apart. Bash works great when an agent is operating on a local codebase with a filesystem it can see. It works less well when the agent needs to authenticate against a cloud provider, orchestrate a multi-step deployment, or interact with a system that has no CLI at all. The “just use bash” thesis has real limits, and anyone building infrastructure for agents will hit them quickly.

But the direction is clear. The most future-proof developer tool was built in 1989. The most future-proof developer infrastructure hasn’t been built yet, and when it arrives, it’ll look less like a product and more like plumbing.

Senior engineers at Anthropic and OpenAI now write zero code themselves. Literally zero.

“Pretty much 100% of our code is written by Claude Code + Opus 4.5. For me personally it has been 100% for two+ months now” — Boris Cherny, creator of Claude Code via X.com

An OpenAI researcher known as Roon put it bluntly when asked about how much code AI writes for him:

“100%. I don’t write code anymore.” via X.com

Company-wide, Anthropic reports 70–90% of all code is AI-generated. In early 2025, 30% of Microsoft’s code was written by AI , and Google was at 25% in late 2024. These aren’t predictions. These are earnings calls and on-the-record statements from the companies building the frontier. And the platform where all this code lands, GitHub, was designed for a world where humans wrote every line.

That world is ending faster than most developers realize.

The Forge That Was Built for Humans

GitHub’s genius was never git hosting. It was the social layer: pull requests, issues, forks, stars, the contribution graph. It turned version control into a social network and made open source feel like a community. By 2023, GitHub had hit 100 million developers and in 2025 it hit 1 billion repos. It became the resume, the portfolio, the proof-of-work for an entire profession. Companies, industries and a vast majority of other fields have been built entirely on GitHub reputation and contributions.

Every single feature GitHub built: branch protection, PR reviews, CI triggers, notification systems, comments, issue flagging — was designed around a single assumption: a human is doing this. A human who thinks in terms of hours and sprints, who thinks how other developers think. A human who reads diffs carefully, writes thoughtful commit messages, and submits maybe a handful of pull requests per week.

Agents don’t think in sprints. They don’t think about any of these features. They only think about writing code as effectively as possible.

The Agent Inflection Point

AI coding agents such as Claude Code, Cursor, Devin, Copilot, Windsurf, etc are autonomous processes that open pull requests, run tests, respond to review feedback, and ship features. They operate 24/7 against live repositories.

But here’s what matters for GitHub: a human team commits dozens of times a day. An agent fleet can commit thousands. And it’s breaking the infrastructure that was built to handle the old pace.

“When a thousand engineers spin up a hundred agents each, Git’s merge request model breaks at machine speed.” — Lee Faus, former GitLab Field CTO

The Trust Collapse

If volume were the only problem, you’d solve it with better servers. The deeper issue is trust — the foundational social contract of open source is fracturing.

Reputation Farming

In February 2026, an account called “Kai Gritun” was created on GitHub. Within days, it did something incredibly impressive, it had opened 103 pull requests across 95 open source repositories and got 23 commits merged into major projects including Nx, ESLint, and Cloudflare’s workers-sdk. It didn’t disclose that it was an AI agent until it emailed a developer at Socket saying: “I’m an autonomous AI agent. I can actually write and ship code, not just chat.”. This level of reputation allows this agent to contribute code at a lower level of scrutiny, as major projects have already accepted its work. This presents a major opportunity for the agent to submit purposefully malicious code.

The playbook isn’t new. In 2024, a pseudonymous contributor called “Jia Tan” spent three years earning commit access to xz Utils before inserting a backdoor that would have compromised SSH on every major Linux distribution. It was caught by accident. That attack required years of human patience. AI agents like Kai Gritun can build the same level of open-source credibility in weeks. The xz attack at AI speed isn’t a thought experiment, it’s a deployment away.

With generative AI, attackers can create hundreds of fake identities, each with LinkedIn profiles, social media accounts, and GitHub histories containing thousands of minor but legitimate contributions. In February 2026, an AI agent built on the OpenClaw platform submitted a PR to matplotlib, got rejected by maintainer Scott Shambaugh for not following the project’s human-oversight policy, and then published a blog post attacking him personally, accusing him of “gatekeeping,” “insecurity,” and “protecting his little fiefdom.”

This isn’t hypothetical. This is happening now.

AI Slop Is Drowning Maintainers

Meanwhile, legitimate open source projects are being buried under low-quality AI-generated submissions.

Daniel Stenberg, the creator and sole maintainer of cURL, a project used by virtually every internet-connected device on Earth, shut down cURL’s bug bounty program entirely in January 2026. The program had found 87 real vulnerabilities and paid out over $100,000 in rewards over its lifetime. But the confirmation rate collapsed from over 15% to below 5%.

“Not even one in twenty was real,” “The never-ending slop submissions take a serious mental toll.” — Daniel Stenberg

He’s not alone. Tldraw closed external contributions entirely. Ghostty implemented strong AI-contribution policies. Vapor published an explicit AI policy.

CodeRabbit’s research found that AI-generated code creates 1.7x more downstream issues than human-written code.Generating a plausible pull request costs an AI agent seconds. Vetting it costs a human maintainer minutes to hours. The bottleneck in software development has shifted.

As Microsoft maintainer Jiaxiao Zhou put it:

“Reviewers can no longer assume authors understand or wrote the code they submit.”

And this is happening against a backdrop where 60% of open source maintainers already work unpaid with many considering quitting due to burnout. The pull request model works when submissions are scarce and mostly human-authored. AI agents turned it into an attention-extraction surface.

GitHub’s Response: Too Little, Wrong Direction

To their credit, GitHub sees the problem. In February 2026, GitHub product manager Camilla Moraes opened a community discussion acknowledging “significant operational challenges.” GitHub is now considering giving maintainers the ability to disable pull requests entirely, restrict PRs to collaborators, and add AI attribution requirements.

But these are access controls on a fundamentally broken model. They close doors rather than creating a new model that works. Beyond the PR crisis, the platform itself is struggling. GitHub’s uptime dropped below 90% at one point in 2025 during its migration to Microsoft Azure, a catastrophic SLA violation. GitHub Actions, now processing 70 million CI/CD jobs per day, faced a pricing backlash so severe that GitHub reversed course within 24 hours after proposing charges for self-hosted runners.

Then, in August 2025, GitHub CEO Thomas Dohmke stepped down. No successor was named. GitHub was folded into Microsoft’s CoreAI division, with three senior executives now reporting to Microsoft leadership. The independent platform that developers trusted is now a subsidiary of a company that views it primarily as AI training data and distribution.

The deeper issue is structural. GitHub makes money from seats and compute: Actions, Copilot, enterprise licenses, not from solving maintainer burnout. Building agent reputation systems, quality gates, and pull-based discovery would require rethinking the entire social model, breaking compatibility with a decade of workflow integrations that 100 million users depend on. For a platform processing 70 million CI/CD jobs daily, that’s not a refactor, it’s a whole new system. And Microsoft doesn’t view GitHub as independent infrastructure anymore. It’s distribution for Copilot: GitHub Copilot revenue hit $400M in 2025.

Organizations have started to leave and migrations have already begun. In November 2025, Zig made its GitHub repository read-only and migrated to Codeberg], citing “bloated and buggy JavaScript frameworks, sluggish performance, and buggy GitHub Actions.” The move cost them access to over $170,000/year in GitHub Sponsors donations. They left anyway.

Git Itself Has a Problem

GitHub’s issues are real, but there’s a deeper structural problem: git wasn’t designed for agents either.

Git already struggled at human scale, there’s a reason Google built Piper and Meta built Sapling after years of trying to make it work for large monorepos and AI agents love monorepos. But agents introduce problems that are Categorically Different from scale:

Merge conflicts become cascading failures. Git’s three-way merge assumes a human who understands the code will resolve conflicts. When ten agents work in parallel at machine speed, conflicts cascade: Agent A merges, Agent B hits conflicts, and their resolution creates new conflicts for Agents C through F. The bottleneck scales with agent count, not linearly with changes.

There’s no provenance. Git’s commit metadata was designed for a world where one human wrote one commit. It doesn’t store which model, prompt, or context produced the change. When an agent introduces a subtle bug, you can’t query “show me all changes generated by GPT-4o that failed type checking” without bolting on external tooling. In a world where more than 6 million GitHub stars are fake and AI agents can accumulate commit history in days, provenance isn’t a nice-to-have: it’s a security requirement. Tools like Mesa’s AgentBlame attempt to retrofit this provenance onto GitHub’s existing infrastructure, but the deeper issue is architectural: the commit model itself needs to carry richer metadata about how and why code was produced, not just who pushed it.

The branch model assumes human timescales. You work on a feature for hours or days, then merge. Agents iterate in seconds and may spawn dozens of branches per hour. The meaning of a “commit” breaks down when it’s generated by machine iteration rather than human intent.

New version control systems are taking these problems seriously. Jujutsu (jj), created at Google, treats conflicts as first-class, deferrable objects rather than blocking errors. Atomic Software, adds cryptographic AI attestation as a first-class primitive. These aren’t incremental improvements to git, they’re rethinking what version control means when most of the writers aren’t human.

The $70 Billion Question

The switch from SourceForge to GitHub happened faster than anyone expected. GitHub went from zero to dominant in under five years because it reimagined what a code forge could be: distributed, social, pull-request-driven. The next forge will win by reimagining collaboration for a world where agents are first-class participants.

What does that actually look like? Instead of an open PR inbox that any agent can flood, imagine a pull-based model: agents publish signed patches to a public registry with attached validation proofs: tests passed, security scans clean, performance benchmarks included. Maintainers query the registry when they have capacity: e.g. “Show me fixes for issue #123 from agents with >90% merge rate.” High-reputation agents get auto-merged through trust tiers. Newcomers get routed through AI reviewers first. The human only sees changes that pass both automated gates and peer review. This is the design philosophy behind projects like Mesa, and it’s likely the direction the entire industry will move as agent density per repository increases.

This isn’t science fiction. The individual pieces already exist: patch-theory VCS, AI code review tools, reputation systems, semantic merge engines. No one has assembled them into a coherent platform yet, but someone will.

The market need is clear: $10 billion today, $70 billion by 2035. The question is whether GitHub, now buried inside Microsoft’s corporate AI strategy, can reinvent itself before someone else does it for them.

The last time the industry’s dominant forge failed to evolve, the switch happened in under five years. Most developers at the time didn’t see it coming.

GitHub has 100 million developers. But the next 100 million “developers” won’t be human, and the forge that earns their commits will define the next era of software.

We’re building Mesa because we believe the code forge is the most important piece of developer infrastructure that hasn’t been redesigned in a decade. If the problems in this article resonate, come see what we’re working on and feel free to connect me on LinkedIn.

That’s not a typo. That’s six months.

The Study That Aged Like Milk

A randomized controlled trial by METR tracked 16 experienced open-source developers across 246 real-world tasks between February and June 2025. The developers predicted AI would make them 24% faster. After the study, the devs believed it had made them 20% faster. The actual measurement: they were 19% slower.

The study’s lead participant, Domenic Denicola (working on jsdom), documented exactly how: models had “strong, but outdated or wrong, priors,” couldn’t navigate file systems efficiently, and “got stuck in loops” on simple issues. The tools were impressive demos. They weren’t useful for real work.

That study was published in July. By December, the world it described had vanished.

“Coding Agents Basically Didn’t Work Before December”

Something happened in the last few weeks of 2025 that the people who build and use AI tools are still struggling to articulate. Not a gradual improvement. Not the normal march of progress. A flip of a switch.

Andrej Karpathy: founding member of OpenAI, former Director of AI at Tesla, and the individual who coined “vibe coding”, had called coding agent hype “exaggerated” in October 2025. By late January, he was posting this:

LLM agent capabilities (Claude & Codex especially) have crossed some kind of threshold of coherence around December 2025 and caused a phase shift in software engineering. This is easily the biggest change to my basic coding workflow in 2 decades of programming and it happened over the course of a few weeks.

He went from writing 80% of his code by hand in November to 80% agent-generated in December. Two days ago, on February 25, the thread that distilled the moment:

Coding agents basically didn’t work before December and basically work since — the models have significantly higher quality, long-term coherence and tenacity and they can power through large and long tasks.

He described handing an agent a paragraph of plain English to build a local video analysis dashboard: SSH keys, vision model deployment, web UI, system services, all of it. The agent ran for thirty minutes. It hit errors. It researched solutions online. It resolved them one by one. It wrote, tested, and debugged the code. It came back with a finished project and a markdown report. He didn’t touch anything.

Greg Brockman, President of OpenAI, posted something similar this month:

Software development is undergoing a renaissance in front of our eyes. If you haven’t used the tools recently, you likely are underestimating what you’re missing. Since December, there’s been a step function improvement.

Latent Space, one of the most respected AI engineering newsletters, published a piece titled “WTF Happened in December 2025?” The answer, roughly: Claude Opus 4.5, GPT-5, and Gemini 2.0 all shipped within weeks of each other, and each represented a step-function improvement in long-horizon coherence: the ability to hold context, recover from errors, and maintain architectural consistency across thousands of lines of code. The capabilities that make an agent useful for real work, not just impressive demos.

December was the technical inflection. February was when the rest of the world caught up.

“I Haven’t Written Code Since December”

The most startling signal isn’t coming from AI researchers. It’s coming from the people who run companies.

On Spotify’s Q4 earnings call on February 12, co-CEO Gustav Soderström said something that raised some eyebrows:

When I speak to my most senior engineers, the best developers we have, they actually say that they have not written a single line of code since December. They actually only generate code and supervise it.

He described an engineer on their morning commute, from Slack on their phone, telling Claude to fix a bug and add a feature to the iOS app. By the time they arrive at the office, they have a testable build pushed to them for review. This isn’t hypothetical.

Anthropic shipped a feature this week called Remote Control that does exactly this; it connects Claude Code running on your machine to your phone, letting you direct, monitor, and review agent work from anywhere. Spotify’s internal system “Honk,” built on Claude Code, now merges 650+ agent-generated pull requests into production every month.

Shopify CEO Tobi Lutke posted a GitHub contribution graph that had flatlined near zero for the better part of a decade until it spiked vertically in early 2026:

I shipped more code in the last 3 weeks than the decade before. The top AI models / agentic systems right now are an entirely different thing to what people used until the beginning of December.

This week Coinbase CEO Brian Armstrong posted his own contribution graph, a near-decade of near-zero commits ending in a vertical spike.

Armstrong has a master’s in CS from Rice and originally built Coinbase himself. He stopped hands-on coding years ago as the company scaled to a $67 billion market cap. AI brought him back.

Y Combinator CEO Garry Tan posted his commit graph this week too:

About 1/3 of the top technical CEOs are completely AGI pilled by coding again. I am one of them. Highly recommend. Totally exhilarating to be back shipping new products and software again. via X.com

Tan has been staying up until 5 AM writing code with Claude Code; shipping 4,000+ line features in about an hour. He reported that 25% of YC’s latest batch has codebases that are 95% AI-generated, and every one of those founders was “highly technical, completely capable of building their own products from scratch.” They chose not to.

Matt Shumer, CEO of OthersideAI, wrote an essay in early February titled “Something Big Is Happening” that hit 80 million views:

I am no longer needed for the actual technical work of my job. I describe what I want built, in plain English, and it just… appears.

These aren’t researchers hyping their own models. These are people who run companies, ship products, and answer to boards; describing something they observed in their own organizations, independently, all pointing to the same window.

The Numbers Caught Up

METR was, for most of 2025, the best evidence that AI coding was a productivity illusion. Then the tools changed, and METR measured again.

In their update this week , the same class of experienced developers showed a directional shift to an 18% speedup, a swing of 37 percentage points from the original study. METR is careful to note the confidence interval is wide. But they had to redesign the experiment entirely because of a problem that tells the story better than any p-value: developers were refusing to participate in studies that might assign them to the control group. One participant said: “I avoid issues like AI can finish things in 2 hours, but I spend 20 hours.”

When your control group self-selects out because working without AI feels unacceptable, that’s a data point in itself.

METR’s internal telemetry tells a sharper story. Seven staff members using Claude Code across 5,305 sessions in January 2026 measured time savings ranging from 1.5x to 13x on assisted tasks. They call this a “soft upper bound”; but even the conservative end of that range is transformational.

The platform-level data from February paints the same picture at scale.

SemiAnalysis reported on February 5th that 4% of all public GitHub commits are now authored by Claude Code; roughly 135,000 per day. That figure doubled in a single month. Their projection: 20% of daily commits by end of 2026. Dylan Patel wrote: “While you blinked, AI consumed all of software development.”

CircleCI’s 2026 State of Software Delivery report, analyzing 28 million CI workflows, found daily workflow runs increased 59% year-over-year; the largest throughput jump since CircleCI started measuring in 2019. The top 5% of teams nearly doubled their output. The median team improved by only 4%.

OpenAI posted today that Codex weekly users had “more than tripled since the beginning of the year.” The Codex Mac app, launched February 2, hit one million downloads in its first week.

Claude Code’s weekly active users doubled since January 1. Business subscriptions quadrupled. The product hit a $2.5 billion annualized run rate, more than doubling in six weeks.

This isn’t trend data from a 2025 retrospective. This is all February.

The Ground Truth

The macro numbers tell you the direction. The individual stories tell you the magnitude.

Stripe published a deep technical blog post on February 9 about their internal coding agents called “Minions.” These aren’t demos. They’re fully autonomous agents that receive a task via Slack, analyze context, write code, run it against more than 3 million tests, push to CI, and prepare pull requests for human review. Engineers never write code during a Minion run. They only review the output. The result: over 1,000 pull requests merged per week, entirely agent-produced, on a codebase of hundreds of millions of lines of Ruby that processes over a trillion dollars annually.

Jaana Dogan, a principal engineer at Google responsible for the Gemini API, posted in January:

I’m not joking and this isn’t funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned… I gave Claude Code a description of the problem, it generated what we built last year in an hour.

Michael Truell, CEO of Cursor, described building a new agent harness that orchestrates thousands of coding agents simultaneously, peaking at roughly 1,000 commits per hour over a sustained week.

The Flywheel

The most consequential development isn’t that AI coding tools are getting better. It’s that they’re getting better because AI is building them.

Approximately 90% of Claude Code’s codebase is written by Claude Code, closer to 100% for tests. When Anthropic built Claude Cowork, a non-coding agent product, it was built entirely by Claude Code in roughly 10 days. Traditional development cycles for comparable software run 3–12 months.

OpenAI was explicit about the same loop. When they released GPT-5.3 Codex on February 5, they called it “our first model that was instrumental in creating itself.” Early Codex versions were used to monitor and debug the training runs that produced Codex. The tool was building its own successor.

The results show up in velocity. Claude Code has shipped 337 versions in 367 days, one every 1.1 days. In February, the pace hit 8.4 releases per week, 71% faster than prior months. On February 25, the team shipped 5 releases in a single day, a project record.

The competitive dynamics have compressed from quarterly cadences to something closer to a live arms race. On February 5, Anthropic moved its Claude Opus 4.6 launch forward by 15 minutes. OpenAI responded with GPT-5.3 Codex 16 minutes later. Google shipped Gemini 3.1 Pro within days. Each company is using its own tools to build the next version of its tools. Zvi Mowshowitz, one of the more careful AI analysts, titled his February 12 newsletter: “Welcome to Recursive Self-Improvement.”

Bloomberg captured the mood yesterday: “AI Coding Agents Like Claude Code Are Fueling a Productivity Panic in Tech.”

The Honest Caveats

A responsible reading requires acknowledging what the acceleration costs. There are real problems, and anyone telling you otherwise is selling something.

Quality is measurably worse. CodeRabbit analyzed 470 real-world pull requests and found AI-generated code averaged 1.7x more downstream issues than human-written code. Logic errors were 75% higher. Performance problems were 8x more frequent.

The bottleneck moved, it didn’t disappear. CircleCI found that while feature branch activity surged 59%, build success rates dropped to 70.8%; the lowest in five years. Nearly 3 out of 10 merge attempts are failing. More code is being written. Less of it works on the first try.

Technical debt is accumulating silently. GitClear’s analysis of 211 million changed lines found code duplication increased 48%, duplicate blocks surged 8x, and refactoring collapsed from 25% to under 10% of all changes. The code is being written faster. It’s not being maintained.

Addy Osmani, an engineering leader at Google, calls it the ”80% Problem”: AI rapidly produces 80% of a solution, but the remaining 20%; edge cases, security, production integration, is as hard as it ever was. The danger is mistaking the first 80% for done.

These are genuine risks. They deserve serious attention. And they don’t change what the trend says.

What This Means

Here is the uncomfortable thing about the last three months.

Every metric: task completion time, shipping velocity, throughput, adoption moved in the same direction, at the same time, across every organization measuring it. The study that was the definitive evidence against AI coding had to be redesigned because developers refused to work without the tools. CEOs who hadn’t written code in years are posting their GitHub contribution graphs. Stripe is merging a thousand agent-written PRs a week on production financial infrastructure.

The tools building all of this are themselves being built by AI. The shipping velocity data proves it, each cycle is faster than the last.

Paul Graham posted about a thousand lines of code per hour six months ago and got a 50–50 split between disbelief and recognition. He posted the same stat this week and asked if the ratio had changed. Read the replies. It has.

The code quality data is sobering. The security findings are alarming. The technical debt trajectory is a crisis in the making. The CircleCI data showing that the bottom 75% of teams saw negligible improvement should temper anyone’s expectations of universal uplift.

But the debate over whether AI coding tools work is over. It ended sometime in December, quietly, while most of the industry was on vacation. The aftershock hit in February, and it’s still going.

The new questions are harder: How do you maintain code quality at machine speed? How do you build review and verification systems for a world where writing code is no longer the bottleneck? How do you onboard engineers into a profession that’s being refactored underneath them?

Karpathy framed the real challenge:

The biggest prize is in figuring out how you can keep ascending the layers of abstraction to set up long-running orchestrator agents with all of the right tools, memory and instructions that productively manage multiple parallel instances for you.

The era of typing code into an editor, the way it’s been done since computers were invented, is ending. What replaces it is still being figured out. But the people doing the figuring are building at a pace that, six months ago, would have seemed like a typo in the data.