When code is abundant

I returned from the holiday break in January convinced that something fundamental had changed.

Large language models had reached the point where they could produce useful code reliably enough, and cheaply enough, to change the economics of software development. Engineers everywhere seemed to be experimenting with the same thing: not just asking an AI assistant for suggestions, but giving agents real work and seeing how far they could take it.

I started thinking about what happens if that continues. What changes when producing code is no longer the primary constraint in building software?

I wrote those thoughts down in a board memo in January. In May, I published part of that thesis in GitLab’s Act 2: the cost and time of producing software was collapsing, machines would increasingly build software under human direction, and the architecture underneath software development would have to change with it.

In June, at GitLab Transcend, we showed the first pieces of that architecture: source control rebuilt for machine-scale concurrency, GitLab Orbit as a context graph spanning the software lifecycle, and governance around agent identity, policy, approval and audit.

Then, on August 21, Anthropic published The AI-Native SDLC Playbook. It opens with a simple statement:

“Code is no longer the bottleneck.”

I agree.

Anthropic’s playbook is a practical description of how the development lifecycle changes when agents can move implementation dramatically faster: planning becomes machine-readable, handoffs become automated, verification moves into the loop, and human judgment concentrates at the gates.

What interests me is what happens one level beyond the workflow. If code is no longer the primary constraint, what becomes scarce? What architecture does an enterprise need when people, agents and multiple models are all acting across the software lifecycle at machine speed? And where does durable value move when generating the code itself becomes increasingly abundant?

Over the past eight months, I’ve watched GitLab engineering and other organizations including Stripe, Spotify and Amplitude begin to answer those questions in production. Their experiences have sharpened my original conviction. The important change is not simply that AI can produce code faster.

It is that when implementation gets dramatically cheaper, the economics and architecture around software change with it.

The constraint moves from producing code to trusting it. Trust increasingly depends on the environment around the model: context, verification, governance and evidence. As organizations run many models and agents at once, that layer has to be durable and independent of any one of them. And as agents encode more of an organization's workflows, expertise and operating knowledge, they should belong to the organization, not to whichever vendor supplies the model or cloud underneath them.

The constraint that built an industry

For sixty years, software engineering has organized itself around one fact:

Code is precious.

It is expensive because turning business intent into reliable software requires scarce people who can hold complex abstractions in their heads. It is fragile because small mistakes can have enormous consequences. And complexity accumulates faster than any individual can absorb. Much of how we build software descends from that constraint.

We preserve old systems because rebuilding them is risky. We bridge between technologies instead of replacing them. Technical debt survives for years because paying it down competes with something customers need this quarter.

We optimize heavily for developer productivity because developers produce the scarce resource. Fragmented tools, inconsistent environments and awkward processes are tolerated if changing them might slow engineers down.

Then there is the ceremony: reviews, approvals, release gates, security checks, change processes and increasingly sophisticated testing. Much of it exists to protect an asset that is expensive to create and expensive to get wrong. And most of the value never gets built at all. For every idea that makes it onto a roadmap, many more never survive the economics of scarce engineering capacity.

We spend enormous energy protecting the cost of change because change has always been expensive.

That constraint is beginning to break. And when a constraint this fundamental moves, the rest of the system eventually moves with it.

Every abstraction reveals the next constraint

This has happened before.

Humans once programmed computers directly in machine instructions. Assembly abstracted the machine. Higher-level languages moved the abstraction again. Each layer made one problem dramatically cheaper and exposed the one hiding behind it.

Nobody mourns hand-written assembly. We got a bigger problem to work on.

Large language models are obviously not compilers in the technical sense. They are probabilistic systems, not deterministic transformations with defined semantics. But economically, the analogy is useful: they dramatically reduce the human effort required to move from intent to implementation.

The distinction that matters is this:

Code production is becoming abundant. Good software is not.

Models can generate implementation far faster than humans can. That does not mean the implementation is correct, secure, performant, compliant, maintainable or even what the business intended. That gap is the point. When code was scarce, the hard problem was producing it. As code becomes abundant, the hard problem becomes trusting it.

When code is preciousWhen code is abundantPreserve legacy because rebuilding is expensiveRebuild when doing so is cheaper than continuing to bridgeOptimize heavily for developer outputOptimize for business outcomes and learning speedCarry technical debt for long periodsRetire debt when the economics make sensePursue only the highest-confidence ideasTest many more ideas cheaplyUse process to limit costly mistakesUse constraints and verification to govern high-volume change

The cost of typing hid the harder problems. AI is exposing them.

Cheap iteration changes the strategy

One reasonable objection is that typing code was never the hardest part.

The harder part is deciding what to build. Requirements are ambiguous. Customers change their minds. Teams misunderstand one another. Important edge cases appear only after software meets reality.

All true.

But that argument assumes the cost of being wrong stays the same. Discovering after six weeks that a requirement was misunderstood is expensive. That expense creates pressure to be right upfront. Requirements documents, architectural reviews and careful planning are rational responses to expensive iteration.

Make iteration cheap and the strategy inverts.

You stop trying to eliminate uncertainty before implementation and start trying to learn faster.

There is another consequence that may prove even more important. Engineering organizations accumulate enormous amounts of knowledge that never becomes part of the software itself. An experienced engineer knows which service is fragile. Someone remembers why a deployment failed three years ago. A security engineer remembers the class of mistake that caused the last incident. Today, much of that learning lives in human heads. When implementation becomes cheap, more of it can become executable.

A production failure becomes a regression test. A security incident becomes a policy. A performance requirement becomes an automated constraint. A compliance obligation becomes continuous validation.

Learning turns into code.

Not literally all of it, and executable constraints do not eliminate judgment. Policies can be wrong. Tests can encode yesterday’s assumptions. But organizational knowledge can increasingly become persistent, inspectable and revisable instead of disappearing when the person who learned it leaves. That is a different kind of institutional memory, and it is one reason code abundance can improve quality rather than simply increase volume.

Amplitude recently published a striking example of what a broader overhaul of this kind can produce. Over six months, it tripled the number of pull requests it shipped while reported monthly bugs fell from 715 to 319. That does not prove that more AI-generated code creates better software. It does show that much higher change volume does not have to imply proportionally lower quality.

Cost per accepted change

The economic unit I think matters most in this transition is not cost per line of code.

It is cost per accepted change.

A useful software change includes generation, environment setup, context, verification, review, remediation and governance. AI is collapsing the generation term, which makes everything else proportionally more important. An organization that makes generation ten times faster but leaves CI, review and validation untouched will not become ten times faster.

It will simply move the queue.

That is exactly what the Theory of Constraints predicts: remove one bottleneck and the system exposes the next one. We are now starting to see that happen.

What happens when agents reach production

Stripe built internal coding agents called minions. More than a thousand pull requests merged at Stripe each week are produced entirely by minions. Humans review them, but the code itself is agent-generated.

Amplitude documented a six-month overhaul of its development pipeline. Pull-request cycle time fell from 5.2 hours to 44 minutes. Frontend CI fell from roughly thirty minutes to three or four.

Spotify has been operating a background coding agent called Honk and has documented more than 1,500 AI-generated pull requests merged into production.

These are unusually capable engineering organizations, so their experiences should not be treated as proof that every enterprise is about to work the same way. What makes them useful is that they have gone far enough to expose the next constraints, and several of the same ones keep appearing.

Amplitude’s development environment had accumulated manual setup, slow CI and inconsistent tooling. That survived for years because code production limited how quickly changes entered the system. Agents removed that throttle, and validation and review became the stoppage points.

So Amplitude rebuilt the foundations: faster environment setup, dramatically faster CI and fewer inconsistent patterns that confused both humans and agents. Very little of that work was AI. It was infrastructure work that became necessary because AI changed the throughput of the system.

Many organizations are currently focused on choosing the best coding model.

In practice, a thirty-minute CI pipeline defeats every model you point at it.

Agents do not eliminate existing engineering constraints. They expose them faster.

Three modes, not one maturity curve

Most descriptions of AI adoption imply a single journey from traditional development to fully autonomous development. I don’t think that is how the enterprise transition will happen. Three modes will coexist for a long time.

Mode 1: Human-controlled legacy

Systems with undocumented dependencies and operational knowledge that still resides in people. Many will remain largely human-controlled until they are retired or rewritten.

Mode 2: Agentically accelerated development

Humans remain in control while agents assist with implementation, testing, migration, review, documentation and security analysis. This is where most enterprise development sits today and where I expect much of the near-term economic value.

It is not merely a waiting room for autonomy. One of the most valuable uses of agents may be making modernization projects economical when they were previously impossible to justify.

Mode 3: Autonomous development

Agents operate the implementation loop while humans provide intent, constraints and oversight. The important dividing line is not greenfield versus brownfield. It is whether execution remains human-controlled or can safely operate as a closed loop.

A practical way to tell where a system sits is to ask three questions: Can an agent make a useful change with the context available? Can that change be verified without a person reading every line? If it is wrong, does the system catch it or does a person have to? The more those answers depend on a person, the closer the workload remains to Mode 1, regardless of how capable the model is.

Trying to force every workload into Mode 3 too early is likely to be one of the more expensive mistakes organizations can make during this transition.

The pipeline runs the inner loop

Once Amplitude reduced frontend CI below five minutes, the remote pipeline became fast enough that engineers could launch many pieces of work in parallel and review the results as they returned.

Stripe reached a similar architecture from another direction, giving minions isolated, pre-warmed development environments so many jobs can run concurrently without interfering with one another.

Most coding-agent workflows today still begin on a laptop. That is a reasonable place to start. It is unlikely to be where the architecture ends.

In an agentic system, the pipeline becomes the natural place to run the inner development loop:

generate → build → test → validate → review → remediate → repeat

The agent keeps working against those signals until it can return something that is not merely plausible code, but functional, verified software that satisfies the constraints the organization has defined.

Faster inner loops also increase the need for coordination. A thousand individually valid changes can still pull a system in conflicting directions. As AI compresses the gaps between SDLC phases, alignment on intent has to become continuous rather than periodic.

There are architectural reasons this loop belongs close to the repository and the systems around it.

The pipeline already sits next to the code, build system, test infrastructure, security controls, deployment configuration and much of the history surrounding a change. The closer the agent is to those systems, the less context it has to reconstruct through repeated remote calls and fragmented APIs, and the faster it can receive feedback. That matters because machine-speed development can turn even small amounts of latency and context loss into system-level bottlenecks.

Running the loop there also preserves the evidence around the work. The identity that initiated the change, the policies that applied, the tests that ran, the reviews that occurred, the remediation the agent performed and the artifact that ultimately shipped can all remain connected.

That is important for more than efficiency. It is what makes increasing autonomy governable.

The pipeline moves from being a gate at the end of development to becoming the system that runs the development loop itself.

Agentic development therefore scales best where execution, context and governance are close to the work. The faster an agent can access the right context, receive deterministic feedback and prove what it did, the more of the loop it can safely complete before handing work back to a person.

The question is no longer simply: Did the code compile?

It is: Was the change actually good, and can we prove it?

Autonomy is governed, not granted

As model capability improves, I believe governance increasingly becomes the binding constraint on autonomy.

The stalled enterprise programs I have seen rarely stall because nobody can get a model to generate code.

They stall on more basic questions. What is the agent allowed to do? How do we prove what it did? Who is accountable when it is wrong?

Stripe’s architecture illustrates the pattern. Minions combine open-ended agent loops with deterministic software for git, linting and testing. They run in isolated environments, pass local checks before pushing, and selectively run tests from a suite containing more than three million tests.

The agent can be creative.

The system decides where creativity stops.

Amplitude uses a risk model to distinguish work that can merge automatically from work that should still route to a person.

Spotify’s verification architecture gives agents access to verification without exposing the underlying implementation of the verifiers, and runs required checks before a pull request can be opened.

None of these organizations solved reliability with a better prompt. They combined capable models with deterministic gates, isolation, verification, policy and evidence, and that is what allows autonomy to expand safely.

It also explains why this becomes harder outside the best-resourced technology companies. Most enterprises will not want to invent their own agent authorization model, isolation layer, verification architecture and evidence system. They will expect to inherit much of it.

That is increasingly what we mean at GitLab when we talk about speed with control.

Speed without control eventually stops because the organization cannot accept the risk. Control without speed leaves the value of AI unrealized. The two have to be designed together.

Accountability can become clearer

One concern about autonomous development is that accountability disappears into the machine. That can happen if the system is designed poorly. But autonomous development can also make accountability more explicit if identity, policy, context and evidence are preserved as part of execution.

Humans remain accountable for defining the constraints: the security policy, the performance threshold, the compliance obligation, and what the organization learned from the last incident. The control plane has to make execution against those constraints provable.

Amplitude’s description of its SOC 2 approach is instructive. Its automated approval process relies on documented criteria, logged decisions and an override path rather than requiring a human to click approve on every qualifying change. The human moves from approving every action toward owning the criteria under which actions are permitted, which can be both more consequential work and more auditable.

The durable layer

One possible conclusion from increasingly capable agents is that more of the software lifecycle collapses into the model and everything around it becomes commodity infrastructure. I think the opposite is more likely.

As agents take on more of the implementation loop, the durable enterprise layer becomes even more important. Context, identity, policy, provenance, verification and organizational memory cannot live only inside whichever model or agent is executing the work. They have to persist across them.

And over time, I expect the product development lifecycle to use multiple purpose-built models.

Different tasks will optimize for different things: reasoning quality, latency, cost, security, domain specialization or where the model can run. Some will use frontier models. Others will use smaller models or open-weight models deployed closer to the customer's data and infrastructure. The best model for planning may not be the best model for code review, security analysis, te