The codebase is often the crown jewel of any software project or company. Painstakingly accumulated, jealously guarded, and nearly impossible to replicate without direct access.
Said differently, if you had the code, you had the power. That era is ending.
AI can now generate code cheaply and quickly, which means the code itself is becoming a commodity. The fundamental unit of value is migrating from the code itself to the system that generates it: the methodology, the agentic workflows, the processes by which a team converts an initial intent into working software. Virtually everything that once orbited code — the open source debate, competitive moats, etc. — is moving upstream.
Code was king because code was hard
The historical difficulty of producing high-quality code made specific codebases feel almost sacred. The Postgres database, the Linux operating system, the V8 Javascript engine. These were singular technical achievements — the accumulated output of hundreds or thousands of person-years of effort. You couldn’t reproduce them from scratch in a reasonable timeframe or at a reasonable cost.
It was this quest for control over artifacts that were, for all practical purposes, unique that fueled the open vs. closed source debate. Code that was locked behind a proprietary license was truly closed to the general public.
Meanwhile, the costs of building and maintaining the software tended to grow with the size and scope of the project. This meant that traditional software experienced decreasing returns to scale: the larger a codebase grew, the less productive each additional unit of software engineering effort became. Every feature tended to add complexity. Modifications required negotiating with the accumulated weight of prior decisions. This extended far beyond mere “tech debt,” as even one’s technical assets had to be navigated and negotiated to make continued progress.
Inevitably, teams eventually hit ceilings. Not because they ran out of ideas or ambition, but because the raw economics of scaling code made progress prohibitively expensive or agonizingly slow. As I’ve written before, this problem gets worse as software grows — bigger codebases get disproportionately harder to manage, and coordination costs eventually overwhelm even great engineering teams.
In practice, software teams operate in a capped, Malthusian world, where instead of hard constraints on population we have constraints on size of codebase. Throwing more engineers at the problem rarely works and can even be counterproductive.
If you’ve ever worked on a large codebase, this probably feels familiar. The first ten thousand lines of code can feel generative: you’re building something from nothing, and every commit can add visible capabilities. By the time you’re at one million lines, a meaningful fraction of your engineering effort isn’t building anything new. It’s just understanding what’s already there, navigating its constraints, and tracking down bugs caused by how different parts interact. In a sense, the codebase starts pushing back.
This compounding difficulty had an interesting side effect in open source: it acted as a natural trust filter. If someone could contribute meaningfully to a major project — actually understanding the codebase well enough to improve it — that was a real signal of skill. “Proof of work,” so to speak. The hard work was its own vetting mechanism.
AI has brought us code abundance
Consider the relationship between intent (what you want the software to do) and code (the specific artifact that does it). In the old regime, this mapping was extremely narrow. For any given intent of sufficient complexity, there were often only a handful of high-quality implementations in existence. There might be some reference libraries, a couple commercial products, and that’s it. If you’ve ever tried to track down some software with one particular niche functionality, you’ll know how rare these can be.
In the language of statistics, the probability distribution of software concentrated on a few singular points. If you needed to build a high-performance API, you’d likely pick FastAPI, Express.js, Django, or one of a handful of close alternatives. There was no wide open field of options to choose from, and you could easily count them on a few fingers.
With AI, this has flipped. The mapping between intent and code has gone from a discrete distribution to a smooth, continuous distribution of functionally similar codebases. Any specific implementation of an “authentication service” or “rate limiter” is just one version an agentic coding system can “sample” at little marginal cost. As long as you’re clear about what you want, no particular codebase is precious anymore.
The speed of this shift is staggering. SemiAnalysis estimates that as of February 2026, 4% of all GitHub public commits are being authored by Claude Code alone.
As Simon Willison observes, this disrupts engineering intuition at every level. We’ve spent decades designing elaborate planning processes to help ensure that expensive coding time is spent efficiently. When writing code becomes cheap, all those intuitions need to be rebuilt from scratch.
This also flips the scaling problem I described earlier. Well-designed agentic coding systems don’t slow down as codebases grow. If anything, they get better. A single bug fix can eliminate an entire category of future bugs by having the agent learn from this experience. Codified patterns become reusable tools for future work. And the accumulated context of working within a codebase — the documentation, the test suites, the architectural decisions — can be fed back into the agents to improve their performance over time.
This changes how we consume existing software too. Andrej Karpathy recently discussed an incident where he needed some specific functionality from the deep learning library PyTorch. Instead of importing the whole library and all its dependencies, he pointed an AI agent at the library’s codebase, had it understand the relevant implementation details, and extracted exactly the functionality he needed into 150 lines of clean, self-contained code. The result ran faster than the original library, lacking any of the overhead.
You no longer need to adopt a library wholesale. You can take exactly what’s useful and leave the rest. The tangled web of dependencies that makes modern software so fragile starts to unravel when any piece of it can be cheaply rebuilt on demand.
The Eternal September
This has an awkward consequence for open source because it impairs the implicit trust mechanisms that the ecosystem has relied on.
The implicit social contract of open source followed directly from the historical economics of software:
- Welcome contributions: because skilled labor is rare and high quality commits are precious
- Guard the license: because the artifact itself is valuable, you need to control how it’s used
The gatekeeping was on outputs: who could use the code, under what terms, for what purposes. The input — who could contribute — was left relatively open, because the filtering happened automatically.
Mitchell Hashimoto, creator of Terraform and co-founder of HashiCorp, has been thinking carefully about this. When code was hard to write, the difficulty of making meaningful open source contributions was itself a trust signal. The skill required to contribute was a strong signal of both competence and good faith.
That filter is now gone. AI can generate plausible pull requests at scale, with no guarantee the person submitting the code even understands what it does. The quantity of contributions explodes, but each one means much less.
“Open source has always been a system of trust. Before, we’ve had default trust. Now it’s just default deny.” — Mitchell Hashimoto
GitHub has named this moment “The Eternal September of Open Source” — a reference to the Usenet days when a flood of new users overwhelmed early internet communities that had relied on friction to keep order. The parallel to today: creating a contribution has gotten much cheaper, but the reviewing one has not to the same degree. Even well-intentioned submissions, arriving at sufficient volume, can overwhelm maintainers.
Mitchell’s Ghostty project has moved to an invitation-only contribution model. GitHub is shipping features that would have seemed extreme a few years ago — repo-level controls to limit or disable pull requests entirely along with automated triage tools. Mitchell launched Vouch, a trust management system where contributors must be vouched for by trusted maintainers before they can participate. A system of explicit endorsements and identity verification.
These responses all make sense, but they represent a real shift. Open source communities are being forced to formalize what used to happen naturally. Gatekeeping is now focused on inputs rather than outputs, guarding contributions rather than welcoming them.
Building autopilot while flying the plane
If code is no longer the scarce resource, what is?
The answer is already visible in the behavior of some of the most sophisticated engineering organizations. What’s scarce is the engine — the methodology, the agentic workflows, the systems by which teams convert intent into code at scale.
Evidence from the field:
- Stripe has built what it calls Minions: autonomous coding agents that produce over 1,000 merged pull requests per week — real, production code that ships to millions of users. Humans review, agents write end-to-end. We believe Stripe’s edge isn’t the agents themselves but the six-layer harness built around them: the deterministic gates, the sandboxed dev boxes, the curated tool selection from their 500-tool internal MCP server, and three-tier feedback loops.
- Ramp has built Inspect, a background agent that now accounts for roughly 30% of all merged PRs across the company. The agent runs continuously with full dev environment access. Ramp’s bet is that owning your own tooling compounds over time in ways no generic tool can match.
- Coinbase has invested heavily in background agents and agentic systems that span the entire software development lifecycle — code generation, but testing, deployment, monitoring, and incident response.
- Spotify leadership has described an internal system called Honk, built on Claude Code, that lets engineers remotely task an agent to add a feature or fix a bug in the codebase. The agent writes the code and pushes a QR code back to the engineer’s phone so they can try the feature live. If they like it, they can merge it to production before they arrive at the office. As their CEO put it: “We’re retooling the entire company for this age.”
The pattern is the same. These companies are increasingly competing on the sophistication of the machine that writes the code. They understand deeply that the system can turn cheap generated code into reliable production software.
We believe the best engines compound. Every has articulated this emerging idea well and called it compound engineering: a well-designed coding system that learns from its own output. Each unit of work makes subsequent work easier rather than harder and institutional knowledge gets encoded into the system itself. Stripe’s design principle captures this concisely: “putting LLMs into contained boxes compounds into system-wide reliability upside.” Every deterministic gate, every codified linting rule, every curated tool subset is an investment that pays off on every future agent run.
This is the new moat. Not the codebase, which can be reproduced, but rather the rate at which the system improves itself. A company whose software development “engine” compounds at 10% per quarter can, within a few years, be operating at a qualitatively different level than a company whose engine is static — even if they started from identical codebases on day one.
The debate follows the bottleneck
It’s no surprise, then, that the cultural energy around open vs closed source has shifted from software to AI models.
The model is now the core of the software-building engine — the thing that converts intent into code. It has inherited the “preciousness” that code used to hold. It’s expensive to build and hard to replicate.
So naturally, the open source debate has followed. The fights about open source LLM licensing, or what counts as “true” open source vs merely open weights (without the training data) are structurally identical to the fights about software licensing in the 90s and 2000s. The vocabulary has changed, but the underlying dynamic hasn’t: people fight over access to whatever is scarce.
And if the models themselves commoditize — if the gap between frontier and models narrows — the bottleneck will likely just move again. It might migrate to intent quality: knowing what to build and specifying it clearly. The ability to clearly articulate a complex software system’s requirements and design constraints might become one of the highest-leverage skills in engineering.
The specific answer matters less than the pattern: value migrates to scarcity, and the debates and competitive dynamics follow right behind it every time.
Authors
