The Future of Software Development: When Code Stops Being the Moat

When Code Stops Being the Moat

AI is changing the build-versus-buy equation faster than most software companies expected. The companies that remain valuable will sell less of what is becoming abundant and more of what is still scarce: context, verified knowledge, integration, operational reliability and responsibility.

For most of my career, the answer to whether it made sense to invest in software development was almost automatic. Of course it did. Better software meant that an existing problem could be solved more reliably, with more automation, more features and less manual work, and a company that understood a problem deeply could convert that knowledge into a product and sell the same solution many times. That logic built much of the software industry we know today.

I am no longer sure that the answer is so simple. Artificial intelligence is not merely making programmers faster; it is beginning to change the economics that made software worth buying in the first place. The cost of producing code is falling, the number of people capable of directing software development is expanding, and coding agents are moving from autocomplete to multi-step systems that can inspect repositories, implement features, run tests, review changes and increasingly maintain software over time. McKinsey’s 2026 global AI survey found that 32% of respondents said their organizations had already decided against buying at least one software product or feature because agentic coding tools made it possible to build the functionality internally.^[1]

Code Is Losing Its Scarcity

The strongest evidence is coming from the companies building the models themselves. Anthropic disclosed this year that more than 80% of the code merged into its own codebase was authored by Claude as of May, while the typical engineer in the second quarter of 2026 was merging about eight times as much code per day as in 2024. The effect became so large that the company ran into a problem few software organizations have ever had: writing code was no longer the bottleneck. Source control, builds and continuous integration were.^[2]

Anthropic’s source-control numbers are worth pausing over because they show that this is not simply a better version of the developer tools we already know. The company went from roughly 2,500 merged code changes per day in May to more than 30,000 in September. Its main-branch history approached 100 GB, its systems were performing about 25 million code checkouts a day for CI alone, and Anthropic concluded that Git’s assumptions were increasingly mismatched with a world in which most clients were online agents and automated jobs. A team of seven people built Scion, a new in-house source-control system, together with a new code-review system and related infrastructure, and migrated the monorepo in five months. GitHub, independently, is rebuilding parts of its own Git infrastructure for what it calls agent-scale software development.^[3][4]

The lesson is bigger than source control. When the amount of code that can be produced increases by an order of magnitude, everything around code becomes more important. Requirements, architecture, context, testing, review, security, deployment, observability, governance and the ability to decide what should be built become the scarce resources. Code itself starts to look less like the product and more like a generated material inside a much larger production system.

The Build-versus-Buy Equation Is Moving

This change is particularly uncomfortable for a certain kind of software company: a business that solves one specialized problem, packages the solution as software and then asks a larger enterprise to integrate that component into its own landscape. Historically, the proposition was powerful. The specialist knew the problem better, already had the code, maintained it for many customers and could deliver the capability faster and more safely than an internal team could reproduce it.

AI weakens several of those arguments at the same time. If the customer has access to similar coding agents, the gap in development capacity narrows. If an internal team can describe the requirement, expose its own systems to the agent, generate a first implementation, test it against the surrounding environment and continue maintaining it with agents, buying and integrating a narrow external component can become harder to justify. The integration project itself may have been more expensive than the feature, and once the cost of creating the feature falls enough, internal development becomes a realistic alternative.

This does not mean that every piece of integrated software is about to disappear, and this is where I would revise the most radical version of the argument. Gartner now explicitly treats AI-era application sourcing as a build-versus-buy-versus-blend decision rather than a binary one, and recent research on the economics of agentic development reaches a similar conclusion: the so-called SaaS apocalypse is likely overstated, particularly for regulated, mission-critical and deeply integrated systems. There is also an important counter-signal in enterprise AI itself. Menlo Ventures found that 76% of enterprise AI use cases in its 2025 survey were purchased rather than built internally, up from 53% a year earlier, because production-ready products still package far more than code.^[5][6][7]

The sharper conclusion is therefore not that integrated software has no reason to exist. It is that software whose main reason to exist was the cost and difficulty of writing the code is becoming vulnerable. A narrow component with no proprietary data, no network effect, no difficult operational burden, no certification, no unique integration footprint and no meaningful transfer of risk may increasingly look like something a customer can generate rather than something it must procure.

Knowledge Is No Longer Enough

The next traditional moat is domain knowledge, and that moat is also changing. Specialized software companies often know their subject better than their customers, and that knowledge is embedded in requirements, implementation decisions, support processes and years of accumulated edge cases. For decades, this was difficult to reproduce. Generative AI is making generic expertise much easier to access, which is already putting pressure on parts of consulting, legal work and other knowledge businesses where clients historically paid for access to people who knew how to find, structure and explain information.^[8]

The consulting analogy is useful precisely because it also shows where the simplistic conclusion fails. Consulting is not disappearing. Accenture continues to report strong demand from companies that need help implementing AI and transforming complex operations, even while clients are pushing for lower prices and taking simpler work in-house. The value is moving away from the mere possession of information and toward judgment, implementation, organizational context, accountability and outcomes. The same transition is likely to happen in software.^[9]

For a software company, having specialized knowledge will therefore not be enough if that knowledge exists only in documentation and in the heads of employees. The defensible version of knowledge will increasingly be structured, continuously maintained and executable. It will live in proprietary datasets, ontologies, rule systems, evaluation suites, benchmarks, workflow histories, customer-specific context, mappings between systems and the accumulated evidence of what actually works in production. AI makes knowledge easier to consume, but that makes the quality, provenance and operationalization of knowledge more important, not less.

Maintenance Does Not Disappear; the Bottleneck Moves

There is another tempting conclusion that needs qualification. If agents can write software, it seems logical that software maintenance will simply become the job of a few trained agents and therefore lose much of its value. Parts of maintenance will certainly be automated, but current evidence suggests that faster code generation can move pressure downstream rather than eliminate it. Google’s DORA research found that higher generative-AI adoption was associated with greater individual productivity and satisfaction, yet also with worse delivery throughput and stability in the organizations it studied, partly because teams could produce larger volumes of code faster than their review and delivery systems could safely absorb.^[10]

The same issue is visible in code review. A Microsoft Research benchmark published this month found that the best reviewed agent configuration caught 71.9% of human-verified bugs within its top five comments, a large improvement over models from only a few months earlier, but performance still dropped sharply on complex changes and proprietary repositories where local context mattered. The future software factory may be capable of producing extraordinary volumes of code, but that makes evaluation, test generation, formal constraints, context management and automated governance more valuable. The bottleneck moves from typing code to proving that the software does what was intended and continues to do so when the surrounding system changes.^[11]

Responsibility May Become Part of the Product

This leads to a part of the software business that I think is underestimated: responsibility. A customer does not buy enterprise software only because it would be inconvenient to write the code. It also buys an operating commitment. The supplier is expected to maintain the product, react to incidents, follow regulatory change, provide security updates, offer support, document behavior, meet service levels and, in many cases, stand behind certifications, warranties or contractual obligations.

If internal AI development becomes cheap enough, this responsibility can become one of the strongest remaining reasons to buy. At first glance that sounds like the software vendor is turning into an insurance company, because part of the price is paid to transfer risk. I think the reality is more interesting. The vendor can become an assurance layer that continuously maintains the knowledge, evidence, controls and operational guarantees around a capability. In regulated fields such as payments, identity, tax, fiscalization, security or safety-critical systems, the scarce product may no longer be the code that performs the function but the ability to demonstrate that the function is current, tested, controlled and legally or operationally defensible.

That changes product design. A supplier that continues to sell a black box with a long feature list may be competing with something its customer can increasingly build. A supplier that sells a verified capability with authoritative data, machine-readable rules, audit evidence, continuous updates, predictable APIs, clear responsibility and measurable outcomes is selling something considerably harder to reproduce.

Anthropic Is an Early Warning From the Software Factory

Anthropic’s Scion story matters because it shows what happens when AI is applied deeply enough that old assumptions become structural bottlenecks. Git was designed for human developers who need complete local repositories and can work offline. Anthropic found that those properties became liabilities when enormous numbers of always-online agents and jobs were performing tens of millions of operations. Scion deliberately moved intelligence back to the server, made working copies optional and designed commits, queries and checkouts for machine-scale use. Anthropic itself cautions that Scion is not a general replacement for Git, but the direction is important: tools optimized for human-scale software production will increasingly be redesigned around agent-scale production.^[3]

The same pressure will reach issue tracking, CI/CD, test infrastructure, code review, documentation and release management. Gartner expects that by 2027 more than 65% of engineering teams using agentic coding will treat the traditional integrated development environment as optional, with more control, governance and validation moving into automated platforms. The familiar visual workplace of software development may therefore become less central even before source code itself changes.^[12]

Programming Languages May Become an Intermediate Layer

The programming-language question is even more radical. Today’s mainstream languages were designed around an obvious assumption: humans write code and other humans need to read, debug and maintain it. That explains much of their syntax, naming, abstraction and tooling. If the primary author becomes an agent, it is reasonable to ask whether optimizing the language primarily for human typing remains the right design target.

I do not think the immediate answer is that AI will start producing deliberately unreadable machine languages and humans will simply stop looking. Existing ecosystems, compilers, security tools, libraries, auditors and production operations still benefit enormously from readable source code, and the fact that machines author more of it does not remove the need for humans to inspect consequential decisions. Anthropic itself says its engineers still review every change request in Scion, although they increasingly review the intent of the change rather than every line. Human readability is therefore unlikely to vanish overnight.^[3]

The more plausible change is that source code becomes an intermediate representation rather than the primary place where intent originates. A human might describe an outcome in natural language, an AI system might turn that intent into a more formal specification, domain-specific representation or set of executable constraints, and agents could then generate conventional source code, tests and deployment artifacts from it. Microsoft Research is already treating intent formalization as a central challenge for reliable agentic programming and is experimenting with approaches in which natural-language intent is translated into precise, machine-checkable representations before code is synthesized. This direction is important because the future language may not need to be less understandable to humans; it may need to be more precise for machines.^[13][14]

In that world, the most important development artifact may gradually move upward from source code to specification and downward from source code to verification. Natural language expresses what we want, formalized constraints define what is allowed, agents create the implementation, and automated tests, proofs, simulations and runtime controls decide whether the result is acceptable. Code remains in the middle, but it may no longer deserve the privileged position it has held for decades.

The Future Product Is a Capability, Not a Screen

There is another consequence for software companies that goes beyond development. Much of today’s software is still packaged around a user interface because humans have been the primary operators of applications. As agents increasingly call APIs, use tools and execute workflows on behalf of people, the interface can become less visible. Customers may no longer care which application screen performed a task; they may care whether the capability was available, reliable, governed and correctly executed.

This suggests a broader movement from software as an application toward software as an executable capability. The valuable product becomes something that can be called by humans, agents or other systems; that carries its own context and rules; that exposes reliable interfaces; that can explain what it did; and that can be measured by the outcome it produces. Pricing is likely to follow the same direction, with pressure on per-seat and feature-based models and more attention to usage, transactions, outcomes and assurance.

What Is Still Worth Building

This brings me back to the original question. Investing in software development still makes sense, but I would no longer evaluate the investment by asking how many features we can build or how much code we can produce. Code production is becoming the cheap part of the equation. The investment makes sense when it creates an asset that remains scarce even when every serious company has access to powerful coding agents.

That scarce asset can be proprietary data that improves the outcome, domain knowledge transformed into machine-readable and executable form, a network that gets better as more participants use it, a difficult integration layer embedded deeply into customer operations, a continuously maintained regulatory or safety model, unique evaluation and validation infrastructure, operational reliability at scale, or contractual responsibility that customers do not want to carry themselves. It can also be distribution and trust, two things that do not become abundant merely because code does.

For the most exposed software companies, the strategic mistake would be to use AI only to produce more of the same product faster. That improves efficiency while leaving the underlying value proposition unchanged. If the customer’s own agents are becoming capable of producing the same functionality, adding another hundred features does not necessarily deepen the moat. The more important investment may be to turn the product into infrastructure that agents can consume, to encode the company’s domain knowledge into something executable and verifiable, and to own the evidence, governance and operational responsibility around the result.

Software Is Not Dying; Its Old Economics Are

I started with the uncomfortable thought that software integrated into other software may be losing its reason to exist. After looking more deeply at the evidence, I think that statement is too broad, but the underlying warning is real. A large category of software was valuable because creating and maintaining the code required scarce engineering capacity. AI is rapidly reducing that scarcity, and the build-versus-buy decision will therefore be made on different grounds.

The software companies that struggle will be those whose value can be reduced to functionality that an enterprise can describe clearly, generate cheaply and validate on its own. The companies that remain valuable will own something beyond the implementation: proprietary context, data, workflows, standards, relationships, certification, operational scale, accountability or a continuously maintained body of knowledge that customers cannot reproduce merely by subscribing to the same AI model.

Software development as we know it is changing very quickly, but this does not mean that software disappears. It means that writing software stops being the moat. In the next generation of software businesses, the code may become the least interesting part of the product, while the real value sits in knowing what should be built, proving that it works, keeping it correct as the world changes and being willing to stand behind the result.