Halyard Systems had forty-eight employees and a roadmap that never got shorter. It sold workforce-scheduling software to mid-sized logistics companies, the kind of business that runs on shift swaps, compliance rules, and a support inbox that never quite empties. For six years, the company's product backlog behaved like a queue with a broken exit: ideas went in, and almost nothing came out except the handful that survived a brutal, informal triage process run by a product lead named Dana and three engineering managers who had learned, the hard way, to say no.
The saying-no was not a philosophy. It was arithmetic. Halyard had fourteen engineers. Every quarter, they could ship perhaps six to nine meaningful pieces of work, once you subtracted incident response, code review, onboarding, and the slow grind of maintaining a platform that eleven different logistics companies depended on to pay their drivers correctly. A request from a major client to support a new overtime rule in Alberta might take three weeks. A nice-to-have integration with a scheduling app used by two customers might never get built at all, not because anyone thought it was a bad idea, but because building it meant not building something else.
That changed, or seemed to, in the space of about a year. Halyard's engineers started using AI coding assistants seriously in early 2025, first for boilerplate and test scaffolding, then for entire features. By the end of that year, a mid-level engineer could take a client's oddly specific request — a custom approval workflow for a client with a unionized warehouse, say — and turn it into a working prototype in an afternoon instead of two sprints. The backlog, that graveyard of good ideas that never got funded, started to look conquerable.
Dana remembers the mood in a leadership meeting that winter. Someone pulled up the backlog board, which had accumulated 340 open tickets over five years, and said, half-joking, that at the current pace they could clear it by the following summer. Nobody laughed at the idea. It seemed plausible. The constraint that had shaped nearly every product decision at Halyard for six years — we don't have the engineering capacity — appeared, for the first time, to be lifting.
What happened next is the subject of this article, and it did not look like what anyone expected.
Twelve months later, Halyard had shipped more functionality than in the previous three years combined. It had also acquired: forty-one new configuration flags, most of them requested by a single client and used by no one else; six internal tools built by non-engineers using AI assistants, none of them documented, two of them quietly load-bearing for finance's month-end close; a support queue that had grown 30 percent, driven not by bugs but by confusion over which of several overlapping ways to accomplish the same task was the "right" one; a security review that took four times as long as the previous year's because nobody could produce a current inventory of what the system actually did; and a growing, unspoken anxiety among the senior engineers that they no longer had a complete mental model of their own product.
The backlog was not empty. It had roughly the same number of items as before — the tickets just described different problems now. Engineering capacity was no longer the bottleneck. Something else was.
This article is about that something else.
Part I: Software Used to Be Expensive for a Reason
It is worth remembering, before going further, why software was expensive in the first place, and why that expense — for all the frustration it caused product managers, executives, and customers — was quietly doing useful work.
Writing software has never been merely a matter of typing code. A single feature request, however small it looks from the outside, drags a long tail of effort behind it: someone has to understand what the customer actually needs, as distinct from what they asked for; someone has to design an approach that fits the existing architecture without breaking three other things; someone has to write the code; someone has to write tests, or at least think hard about how the change could fail; someone has to review it; someone has to deploy it safely; and someone, eventually, has to support it when a customer hits an edge case nobody anticipated. Multiply that by the size of an engineering organization and divide by the number of things the business wants to do, and you get a chronic, structural scarcity that every software company has lived with since the discipline existed.
That scarcity was expensive in the way that all constraints are expensive. Salaries for experienced engineers have long represented one of the largest line items in a technology company's operating budget. Coordination between teams consumes calendar time that never shows up as a cost on a spreadsheet but is deeply real. Architecture decisions, once made, become expensive to unmake. Technical debt — the accumulated cost of shortcuts taken under time pressure — compounds quietly for years. None of this is new, and none of it required AI to become a persistent drag on how fast an organization could turn ideas into shipped products.
But scarcity had a side effect that rarely got named explicitly, because it looked like a limitation rather than a feature: it forced choice.
When every feature required real engineering effort, weak ideas had to fight for a place on the roadmap, and most of them lost. A product manager proposing a new capability was implicitly asking the organization to give up something else — another feature, a bug-fix sprint, an infrastructure investment — because the total supply of engineering hours in a quarter was fixed. This is, in the most literal sense, an allocation problem, and the backlog was the mechanism by which it got solved. Ideas competed. Most died quietly, not because they were bad, but because they were not quite good enough to displace something else.
This rationing was not designed by anyone. It emerged from the physical limits of how much a team of a given size could produce in a given period of time. But it did real work. It kept products from sprawling in every direction a sales team or an enthusiastic founder could imagine. It forced prioritization discipline that many teams, if asked directly whether they wanted more of, would have said yes to in principle but rarely practiced without the external pressure of scarcity. Engineering capacity, in other words, was not only a cost center. It was also, unintentionally, a filter — and filters are valuable precisely because they discard more than they keep.
It is this filter that AI-assisted development is now weakening, and understanding what happens when a filter loosens is different from understanding what happens when a cost falls. A falling cost, on its own, is unambiguously good. A weakening filter is not — because filters exist to keep something out, and what gets let in when a filter loosens is not guaranteed to be good just because it used to be excluded on cost grounds rather than merit.
Part II: What Happens When Code Stops Being the Scarce Resource?
It is tempting to describe what is happening in software organizations right now as "developers becoming faster," and in a narrow sense that is true. But the more accurate and more consequential description is that the traditional shape of software engineering work — designing, writing, testing, reviewing, one function or file at a time — is shifting toward something closer to specification, supervision, and verification of work that a model produces at high speed. Engineers are not disappearing. Their relationship to the code is changing, and with it, the shape of the constraint that used to govern how much software an organization could produce.
There is a temptation to overstate this shift, and the empirical picture so far is genuinely mixed. A randomized controlled trial run in 2025 by METR, a nonprofit research organization that studies the capabilities and impacts of AI systems, found something that surprised its own authors: experienced open-source developers working on repositories they knew well, using the AI tools available at the time, took 19 percent longer to complete real coding tasks when allowed to use AI than when they were not — despite forecasting beforehand that AI would speed them up by 24 percent, and estimating afterward that it had sped them up by 20 percent (METR, 2025). The gap between how fast developers felt and how fast they actually were was, in the researchers' words, substantial and persistent. Google's own DORA research program, which surveys thousands of technology professionals annually, found a similar tension in its 2025 report: AI adoption is now correlated with higher individual effectiveness and greater software delivery throughput, but it remains correlated with higher delivery instability — more unplanned work arising from the changes AI helps produce (DORA, 2025).
These findings do not mean AI fails to help. They mean the help is not evenly distributed, and that raw code-generation speed is a poor proxy for the thing organizations actually care about, which is delivering software that works, that people use, and that does not become an operational liability. That distinction — between code generation becoming cheap and software becoming cheap — is worth sitting with, because the rest of this article depends on it.
A feature that a model generates in twenty minutes still has to enter a living system. It has dependencies on other parts of the codebase. It interacts with real users making real mistakes. It creates new states the database has to represent and the support team has to understand. It generates data that someone, eventually, has to make sense of. It expands the surface area that security has to think about. It has to be observed, meaning someone has to know when it breaks and why. And unless something unusual happens, it will still be running in five years, maintained by people who may not be the people who built it, defending assumptions that may no longer hold.
None of that work became cheaper just because the code did.
This is worth stating as its own principle, because it is easy to elide in conversations about AI productivity: every feature creates a future obligation. The obligation is not optional, and it does not expire when the sprint ends. It persists for as long as the feature exists in production, which for most enterprise software is measured in years, not months. The cost of producing a feature has, for many kinds of work, fallen sharply. The cost of owning it — the sum of everything that has to happen after the code is merged — has not fallen at anything like the same rate, and in some dimensions, as later sections will explore, it has risen.
Part III: The Feature Factory Becomes Literally Possible
Long before AI entered the conversation, product and engineering commentators used the term "feature factory" as a criticism — a label for organizations that had optimized for the appearance of progress rather than its substance. A feature factory measures itself by output: number of releases, story points completed, tickets closed, features shipped. It rarely asks whether any of that output moved a metric that mattered to the business or the customer. The criticism was always aimed at incentive structures, not at technology, and it presupposed a world in which output was at least somewhat expensive to produce, which imposed a natural ceiling on how far the dysfunction could go.
AI-assisted development removes that ceiling, and it does so at exactly the moment when the underlying incentive structures that produced feature factories in the first place have not gone anywhere. If an engineering organization discovers that it can now produce three times as much functionality with the same headcount, the instinctive organizational response is rarely "wonderful, now we can build less and rest." It is closer to "wonderful, now the roadmap should be three times as ambitious." Productivity gains, in most organizations, get absorbed as higher expectations rather than banked as freed-up capacity — this is a familiar pattern from decades of research on automation in other industries, and there is no obvious reason software would behave differently.
Picture the range of ways this plays out. A SaaS company that historically shipped twenty meaningful features a year finds it can plausibly commit to sixty, and sales starts promising features in deals before they exist, because "we can just build it" has become operationally true in a way it wasn't before. A B2B marketplace, under pressure to satisfy the specific procurement quirks of each large merchant, generates dozens of merchant-specific configuration options rather than pushing back and asking merchants to conform to a smaller number of well-tested paths. A fintech platform adds pricing rule after pricing rule to accommodate individual enterprise contracts, because writing the rule engine logic to support one more exception is no longer the multi-week undertaking it once was. An enterprise software vendor builds a custom workflow for every large client rather than resisting customization, because resisting customization used to be partly a function of resisting cost, and the cost argument has gotten quieter.
Each of these decisions, examined individually, looks defensible. The pricing rule solves a real customer problem. The merchant configuration closes a real deal. The custom workflow satisfies a real enterprise buyer. None of them, in isolation, looks like the beginning of a feature factory. That is precisely the mechanism by which feature factories form: not through a single bad decision, but through the accumulation of many individually reasonable ones, each approved because its immediate cost looked small relative to its immediate benefit — a calculation that, as the next section argues, is systematically incomplete.
Interlude: The $5,000 Feature That Cost $200,000
Here is a thought experiment, with numbers chosen for illustration rather than derived from any specific study — the point is the shape of the argument, not the precision of the figures.
Suppose an AI-assisted engineering team can build a customer-requested feature for roughly $5,000 in engineering time, where the same feature would have cost $30,000 two years earlier. Management looks at this and sees a $25,000 saving. In the framework most organizations use to evaluate engineering work — cost to build, weighed against expected customer value — this looks like an unambiguous win, and in the narrow terms of that framework, it is.
But the $5,000 figure captures only the cost of the initial implementation. It says nothing about what happens over the following four years, which is the realistic lifespan of a feature that gets adopted by even a modest number of customers. In that time, the feature will likely require: inclusion in the regression test suite for every future release, indefinitely; a stream of support tickets from users who configure it incorrectly or expect it to behave slightly differently than it does; analytics instrumentation so anyone can tell whether it is actually being used; documentation that has to be kept in sync as the feature evolves; additional infrastructure if it turns out to be used more heavily than expected; a security review, possibly more than one, especially if it touches sensitive data; onboarding material so new employees understand why it exists and how it interacts with everything else; compatibility maintenance every time an adjacent part of the system changes; at least one migration, if the underlying data model needs to evolve; a permanent increase in customer expectations, since customers rarely accept the removal of a capability once granted; and, eventually, a redesign, because very little software survives four years untouched.
None of these costs are exotic. Every experienced engineering leader has lived through versions of all of them. What is easy to lose track of is that they are not one-time costs — they recur, in smaller amounts, for as long as the feature exists. Multiple independent lines of research into software lifecycle costs, going back decades and continuing into recent industry benchmarking, converge on a strikingly consistent conclusion: maintenance, not initial development, dominates the total cost of software ownership. Estimates vary by methodology and system type, but a wide range of studies — cited by the IEEE Computer Society, referenced in Gartner's guidance to IT leaders, and echoed across the academic software-engineering literature — place the maintenance share of total lifecycle cost somewhere between roughly 60 and 90 percent, depending on the system's complexity and how central it is to the business (IEEE Computer Society estimates; Gartner-cited figures). Whatever the precise number for any given system, the direction of the finding has held up for decades: the build is a down payment, and maintenance is the mortgage.
If the $5,000 feature follows anything like that pattern, its true four-year cost of ownership — support, testing, infrastructure, review, and everything else — could plausibly land somewhere in the neighborhood of $150,000 to $250,000, not because the implementation was inefficient, but because implementation was never the majority of the cost to begin with. The $200,000 figure in this section's title is illustrative, not a forecast; the honest version of the claim is not a precise number but a warning about where organizations are pointed by an incomplete metric. Implementation cost is becoming a less and less reliable proxy for the true cost of a feature, precisely because AI has compressed implementation cost while leaving the rest of the cost structure largely untouched. The cheaper the build gets, the more misleading it becomes to use build cost as the basis for deciding whether something is worth doing.
Part IV: Complexity Becomes One of the Most Expensive Things in Software
There is a reason experienced engineers get nervous watching a system's feature count climb quickly, and it is not nostalgia for smaller codebases. It is an intuition, usually earned the hard way, about how complexity actually behaves — which is not linearly.
Ten independent features do not create ten units of risk. They create, potentially, dozens or hundreds of possible interactions between those features, because each new capability does not exist in isolation. It touches permissions systems, data models, notification logic, billing calculations, integrations, and the mental models of every person who has to reason about the product. A feature that is completely correct in isolation can behave incorrectly the moment a user triggers it in combination with another feature nobody thought to test alongside it — a discount rule combined with a currency conversion, a permission override combined with a bulk-edit workflow, a webhook combined with a rate limit. This is not a hypothetical failure mode. It is close to the default behavior of software systems once they cross a certain size, and it is why the hardest bugs in mature products are almost never in a single function — they live in the space between features that were each built and tested correctly on their own.
This complexity accumulates across several distinct layers, and it is worth naming them separately because they are usually invisible to whoever approved the original feature request.
Product complexity shows up as the accumulation of settings, toggles, exceptions, and conditional workflows that a user has to learn to navigate, even if they only ever use a fraction of them. Architectural complexity shows up as more services, more APIs, more places data has to move through correctly. Organizational complexity shows up as the growing number of teams that now have to understand how their part of the system interacts with everyone else's, a coordination cost that grows faster than headcount. Testing complexity shows up as a combinatorial explosion of states and paths that a comprehensive test suite would, in principle, need to cover — and rarely does. Operational complexity shows up as new categories of failure that on-call engineers have to be prepared to diagnose at 2 a.m. Security complexity shows up as an expanding attack surface and an increasingly tangled web of who can access what. And customer complexity shows up as the growing amount that a new user has to learn before they can use the product confidently, which is its own quiet tax on adoption and retention.
None of these forms of complexity are new to software engineering. What is new is the rate at which they can now accumulate, because the traditional brake on feature creation — the fact that building things took real time — has loosened, while the mechanisms that manage complexity have not sped up at anything close to the same rate. Writing a new workflow can now happen in an afternoon. Understanding how that workflow interacts with the twelve other workflows already in production still takes a human being real time to think through, and that thinking has not gotten meaningfully faster just because the code got easier to produce. The bottleneck has not disappeared. It has moved from the keyboard to the space between people's ears.
Part V: Verification Becomes More Valuable Than Generation
If there is a single argument at the center of this article, it lives here.
When code becomes easy to generate, the economically scarce activity is no longer producing a plausible implementation. It is determining whether that implementation is actually correct, in every sense that matters. Verification, properly understood, is a much broader activity than the term "testing" usually implies. It includes whether the software satisfies the requirement it was built for; whether the requirement itself made sense in the first place, which is a question generation cannot answer on its own; whether the feature behaves correctly across the messy, non-ideal paths real users actually take, rather than the clean path a demo follows; whether it breaks something elsewhere in the system; whether it fails safely when something unexpected happens, rather than failing in a way that corrupts data or exposes information it shouldn't; whether it behaves correctly when it receives unusual, malformed, or adversarial input; whether it introduces security or privacy exposure that wasn't there before; whether the system, after the change, remains something a human being can still explain and reason about; whether the organization can actually observe when the new code misbehaves in production; and whether, months later, anyone can articulate why the system does what it does, as opposed to simply observing that it currently seems to work.
The economics of generation and verification are asymmetric in a way that is easy to underestimate. Producing a plausible-looking implementation has become fast, sometimes dramatically so — a model can generate several different approaches to a problem in the time it takes a human reviewer to read through just one of them carefully. Establishing confidence that an implementation is actually correct, safe, and consistent with everything else the system does has not gotten commensurately faster, because that work depends on human judgment, domain context, and the kind of adversarial thinking about what could go wrong that current AI tools are, at best, inconsistent at supplying on their own.
This asymmetry is not speculative. Veracode's 2025 GenAI Code Security Report, which tested output from more than one hundred large language models across eighty coding tasks, found that AI-generated code introduced a detectable security vulnerability roughly 45 percent of the time — a figure that held essentially flat in the company's follow-up testing through early 2026, even as the same models improved sharply at producing code that was syntactically correct (Veracode, 2025; Veracode, 2026 update). The models got measurably better at writing code that runs. They did not get measurably better, over that period, at writing code that is safe. That gap is exactly the gap that verification exists to close, and it is not a gap that more generation can fix — it can only be widened by it, since more generated code means more surface area that needs the same careful scrutiny applied to a smaller, more expensive supply.
A machine, today, can produce ten plausible implementation variants faster than an organization can confidently determine which of those ten, if any, is actually safe to ship. That is the verification bottleneck in its purest form, and it explains why the center of gravity in software organizations is beginning to shift: away from "can we build this quickly" and toward "can we tell, with real confidence, whether what we built is trustworthy." Quality engineering — the discipline concerned with exactly this question, across functional correctness, reliability, and risk — does not disappear in a world of abundant code generation. It becomes one of the few remaining activities that cannot be trivially accelerated by the same technology that created the abundance in the first place, which is precisely what makes it valuable.
Part VI: The New Scarce Resource — Human Judgment
Step back from QA and testing specifically, and a broader pattern comes into view. If software generation becomes abundant, the rare resource in an organization is not engineering throughput. It is the quality of the decisions about what to build, what to refuse, and what to leave alone.
Consider the kinds of questions that determine whether an organization's growing capacity to build things actually translates into value: which customer problem is genuinely worth solving, as opposed to merely requested; which request should be declined even though it is technically easy to fulfill; which automation should never be built at all, because the operational or security risk it introduces outweighs the convenience it offers; which edge case actually matters to the business, as opposed to the one that is easiest to imagine; which risk is acceptable to take on and which is not; which metric reflects real product value as opposed to activity that looks like value; which system behavior is technically correct according to the specification but commercially or ethically wrong in practice; and when additional complexity is actually justified by the value it creates, as opposed to being justified merely by the fact that it is now cheap to add.
None of these are questions that generation, however fast, can answer. They require context about the business, the customer, the regulatory environment, and the second-order consequences of a decision — the kind of judgment that has always been scarce in organizations and that AI has, if anything, made scarcer relative to the volume of decisions now required, because the volume of decisions has grown faster than the supply of people equipped to make them well.
This produces what might be called the premium on refusal. For most of software history, the ability to say yes — to build the feature, take the integration, accommodate the request — was the differentiator, because saying yes was hard and expensive, and companies that could do more of it outcompeted those that couldn't. When building becomes cheap for everyone, saying yes stops being a differentiator, because everyone can do it. What becomes differentiating is the discipline to say no: to decline a feature that would add more operational burden than customer value, to refuse an integration that would expand the attack surface without a correspondingly clear benefit, to resist the urge to build a custom workflow for every large client simply because doing so is now technically feasible. Organizations that cultivate this discipline may increasingly distinguish themselves not by how much they can build, but by what they deliberately choose to leave unbuilt — a form of competitive advantage that looks, from a distance, almost like restraint, but is better understood as judgment applied at scale.
Part VII: Maintenance — The Bill Arrives Later
Software that gets produced quickly today still has to be maintained for years, and AI-assisted development is creating a maintenance paradox worth naming directly: the speed of production has increased sharply while the underlying discipline required to sustain what gets produced has not increased at anything like the same rate.
Consider what accumulates inside an organization that has spent a year or two building at AI-assisted speed. There is generated code that few people on the team deeply understand, because it was written by a model and merged after a review that was necessarily faster and shallower than the review an equivalent hand-written change would have received. There are internal tools, built quickly by an enthusiastic team member using an AI assistant, that solved a real problem at the time and have since become quietly load-bearing — used by finance, or ops, or customer success — without ever being formally adopted, documented, or handed off. There are automations nobody wrote down anywhere. There are duplicate services that emerged because it was faster to generate a new one than to locate and understand an existing one that did almost the same thing. There are experimental integrations, built to test an idea, that were never meant to become permanent and that nobody has since had the time to either formalize or remove. There are hidden dependencies between systems that were never mapped. There are libraries and external APIs, some of them chosen by an AI assistant rather than a human with an opinion about long-term support, that will eventually change or deprecate in ways nobody is currently tracking. And there are, inevitably, employees who built or understood a piece of this system who have since left the company, taking irreplaceable context with them.
It is useful to think about software the way a company thinks about inventory — not the metaphor of "code as liability," which has become a cliché, but something closer to the literal accounting concept. A company can accumulate software assets faster than it can retire them, and unlike physical inventory sitting in a warehouse, software does not visibly announce its own carrying cost. It does not take up floor space. It does not show up as a line item that anyone reviews quarterly. It sits quietly in production, consuming a slow, distributed stream of operational capacity — a few minutes here reviewing an alert nobody quite understands, a few hours there tracking down why a deprecated internal tool is still being used by three people in operations — until, eventually, someone tries to make a significant change to the system and discovers just how much has accumulated underneath it.
This suggests a genuinely useful frame for engineering leadership: a software balance sheet. On the asset side sit the things everyone naturally focuses on — functionality delivered, automation achieved, customer value created, reusable systems built. On the liability side sit the things that are much easier to ignore until they come due: maintenance burden, accumulated technical debt, the growing web of dependencies, expanding security exposure, the ongoing obligation to keep testing everything that already exists, and the sheer knowledge burden of understanding a system that has grown faster than the organization's collective memory of why each part of it exists. Historical estimates of software lifecycle costs — figures that predate the current wave of AI-assisted development but whose underlying logic has not gone away — consistently find that maintenance dwarfs initial build cost over a multi-year horizon, with the maintenance share commonly estimated in the range of 60 to 90 percent of total lifecycle spend depending on system complexity (summarized across IEEE and industry benchmarking sources). If AI has compressed the asset side of that ledger — making it cheaper and faster to create new functionality — while leaving the liability side largely untouched, the balance sheet does not improve just because more assets are being generated. It may simply be growing on both sides at once, with the liability side growing on a lag that makes it easy to miss until it is large.
Part VIII: The Software Equivalent of Fast Fashion
There is a pattern that shows up reliably whenever the cost of producing something falls sharply, and it is worth naming because software appears to be entering it now.
When clothing production became dramatically cheaper through industrialized manufacturing and globalized supply chains, people did not respond by buying the same amount of clothing for less money. They bought far more clothing. When digital photography made the marginal cost of a photo effectively zero, people did not take the same number of photos more cheaply. They started taking thousands of photos a year, most of which are never looked at again. When content creation tools made publishing cheap, the volume of content did not simply substitute for a smaller, higher-quality output — it multiplied, and the average amount of attention any single piece of content receives fell correspondingly.
The analogy should not be pushed too far — software is not a consumer good in the same sense, and a feature is not a photograph — but the underlying economic mechanism is genuinely relevant. Lower unit cost tends to increase total consumption, often by more than the cost reduction alone would predict, because cheapness removes a psychological and organizational barrier to producing more, not just a financial one. If code generation costs fall by, say, 70 percent, there is no reason to expect software organizations to simply spend 70 percent less on building things. A more plausible outcome, and one that several sections of this article have already sketched in concrete examples, is that organizations build significantly more — more features, more internal tools, more integrations, more one-off customizations — such that total technology spending does not fall in proportion to the unit-cost decline, and may not fall at all, because the volume of software being created and subsequently owned is rising to absorb the freed-up capacity. The bill does not disappear. It moves further downstream, into maintenance, verification, and operational complexity, where it is harder to see and, as the previous section argued, often larger than the bill it replaced.
Part IX: Why the Economics of Outsourcing Also Change
This shift reshapes the market for software services — QA providers, engineering consultancies, development agencies, staff augmentation firms — though not in the way "AI will replace outsourced developers" headlines tend to suggest.
Outsourcing is not disappearing, but the thing buyers are willing to pay for within it is changing shape. Clients are becoming less willing to pay simply for hours of coding, for manual repetitive execution of well-specified work, for boilerplate implementation, or for tasks that can be fully described in a ticket and handed to a model with reasonable results. That kind of work is precisely what AI-assisted development compresses most effectively, and any vendor whose value proposition begins and ends with "we have developers who can build what you specify" is competing directly against a capability their client now has in-house, cheaply, without a vendor relationship at all.
What clients are increasingly willing to pay for looks different: architecture decisions that will hold up as a system grows; independent verification of systems that were built quickly and need a second, skeptical set of eyes before they can be trusted with real customers or real money; specialized domain expertise that a generalist internal team does not have and would take too long to build; integration work that requires understanding how a change will ripple through a complex existing system rather than just producing new code in isolation; security review that goes beyond what an automated scanner catches; genuine ownership of outcomes rather than delivery of deliverables, meaning a vendor who is accountable for whether something actually works in production, not just whether it shipped; speed of diagnosis when something breaks and nobody inside the organization can quickly explain why; the exercise of judgment about what should and should not be built, delivered by someone with enough outside perspective to say things an internal team under roadmap pressure might not say to itself; independent review that catches what an internal team, close to its own work, is prone to miss; and a measurable reduction in the risk the client is carrying, whether that risk is technical, operational, or reputational.
The underlying shift is from selling production capacity to selling confidence, judgment, and accountability. This is a meaningfully harder thing to sell, because it cannot be priced simply by estimating hours, and it requires a vendor to actually be good at the thing rather than merely available to do it. But it is also a more durable value proposition, because it is not the part of the software lifecycle that AI compresses most easily. Generation gets commoditized quickly. Verification, judgment, and accountability do not — at least not yet, and not without the same asymmetry described earlier in this article, where producing something plausible remains far easier than establishing confidence that it is actually correct.
Part X: The Metrics Will Have to Change
Engineering organizations have spent the better part of two decades building a vocabulary of metrics to describe productivity: lines of code, number of commits, tickets closed, story points delivered, raw feature velocity, number of automated tests written, and — more recently — number of AI-generated pull requests merged. Every one of these metrics was built for a world in which output was expensive to produce, and expensive output was a reasonably good proxy for effort, and effort was a reasonably good proxy for value. That chain of assumptions is breaking down in an environment where output has become cheap and where cheap output no longer implies careful effort or reliable value.
Google's DORA research program has been tracking something close to this directly. Its most recent findings describe what some analysts have called an AI productivity paradox: individual output metrics rise sharply with AI adoption — one analysis of the 2025 DORA data found 21 percent more tasks completed and 98 percent more pull requests merged among heavier AI users — while broader organizational delivery metrics, the ones that actually reflect whether software is reaching customers reliably, stay comparatively flat, and delivery instability continues to correlate with AI adoption rather than falling alongside it (DORA 2025 findings, summarized by Faros AI; Google Cloud, 2025). A near doubling of pull request volume with no corresponding improvement in organizational outcomes is exactly the signature you would expect if output is rising faster than the organization's ability to absorb, verify, and operate what that output represents — precisely the dynamic this article has described in the language of complexity and verification bottlenecks rather than delivery statistics.
If output itself becomes a weak signal of performance, the metrics worth paying closer attention to shift toward things that are harder to game by simply producing more: change failure rate, which captures how often a deployed change causes a problem; the rate of defects that escape into production rather than getting caught earlier; the frequency and severity of customer-impacting incidents; whether shipped functionality is actually adopted, as distinct from simply shipped; the rate at which an organization retires features that no longer earn their keep, which almost no organization currently tracks at all; how quickly problems get detected once they occur; how quickly they get resolved; what share of existing functionality goes unused; the ongoing operational burden a feature imposes after launch; the support cost per feature over its lifetime, not just at launch; overall system reliability; and, hardest of all to measure but most important, whether shipped work actually improved a customer outcome the business cares about. None of these metrics are new inventions. What is new is the urgency of taking them seriously, because the old metrics — the ones built around volume — are increasingly measuring an activity that has become cheap and therefore no longer tells leadership very much about whether the organization is creating value or simply creating more software.
A Fair Counterargument
None of the preceding argument survives contact with reality unchallenged, and it is worth taking the strongest objections seriously rather than only citing evidence that supports the thesis.
The first objection is that AI does not only generate code faster — it can also verify faster, and the two capabilities should eventually converge. If a model can write a function in seconds, it may also be able to review that function, generate tests for it, and flag suspicious patterns in seconds, closing the asymmetry between generation and verification rather than widening it. There is real substance to this. AI-assisted code review, automated test generation, and AI-driven static analysis are all improving, and it would be wrong to assume the verification bottleneck is permanent simply because it is present today. The more defensible claim is narrower: verification currently lags generation, the lag has real costs, and closing it requires deliberate investment rather than happening automatically as a side effect of better generation models. The Veracode data cited earlier is instructive here — models have improved sharply at producing syntactically correct code while showing almost no improvement on security correctness over the same period, which suggests these two capabilities do not automatically move together even within a single model family. Whether that changes is an open empirical question, not a settled one.
The second objection is economic rather than technical: perhaps organizations that build more will simply capture more revenue, and a modest increase in complexity and maintenance cost is a reasonable price for a much larger increase in addressable market and customer retention. This is sometimes true, and it would be a mistake to treat all feature growth as waste. A feature that unlocks a new customer segment or removes a genuine adoption barrier can be worth a great deal, even accounting for its long-term maintenance burden. The argument of this article is not that building more is always wrong. It is that the decision to build has, for many organizations, become detached from a clear accounting of long-term cost, precisely because the short-term cost fell so sharply. A company that builds more and tracks the resulting complexity, maintenance burden, and unused functionality honestly is in a different position than one that builds more and simply assumes the falling unit cost means the decision was self-evidently good.
The third objection is that this entire framing may be premature. AI-assisted development is still young, tooling for managing AI-generated code at scale is still maturing, and many of the problems described here — shadow software, unused features, undocumented internal tools — predate AI by decades and were never fully solved even in a world of expensive, deliberate engineering. It is fair to ask whether AI is creating a new problem or simply accelerating an old one that organizations already had reasonably good tools for managing. The honest answer is probably both: the underlying dynamics of complexity, unused functionality, and maintenance burden are not new, but the rate at which they can now accumulate is new, and rate matters. A problem that used to take five years to become serious and now takes twelve months leaves an organization with far less time to notice it and respond, even if the problem itself is conceptually familiar.
Taken together, these objections do not undermine the core argument so much as sharpen it: the question is not whether cheap generation is good or bad in the abstract, but whether an organization's capacity to select, verify, integrate, observe, maintain, and retire software is keeping pace with its newly expanded capacity to generate it. For most organizations examined honestly, right now, it is not — but that is a description of a current gap, not a permanent law of software economics.
Part XI: The Unused Feature Problem
Cheap creation has a specific and underappreciated failure mode: it makes it easy to build functionality that almost nobody ends up using, and unused functionality is not a neutral, cost-free artifact sitting quietly in a codebase. It continues to cost the organization money for as long as it exists.
An unused feature still occupies space in the user interface, adding to the cognitive load of every user who has to visually parse past it to find what they actually need. It still has to be documented, or it creates confusion when someone eventually finds it undocumented. It can still contain vulnerabilities, which do not become less dangerous because the feature is rarely used — an attacker does not care about your usage analytics. It still expands the scope that has to be covered by testing, whether or not anyone actually writes those tests. It still increases the size of the API surface that has to be maintained and kept backward-compatible. It can still break when something else in the system changes, triggering an incident for a feature almost nobody was actively using at the time. And eventually, it still has to be migrated or explicitly, deliberately removed — which is its own project, requiring the same care as building the feature in the first place, except now with the added difficulty of figuring out who, if anyone, still depends on it.
The scale of this problem, even before AI accelerated feature production, was already large. A frequently cited figure from the Standish Group, presented by its chairman Jim Johnson at a conference in 2002, found that 64 percent of features in the systems studied were rarely or never used — a number that has been repeated so often across the industry that its origin is worth noting honestly: it came from a study of four internally developed applications, not a broad industry survey, and should be treated as illustrative rather than universally representative (Mountain Goat Software's review of the original claim). More recent data points in a similar direction: Pendo's analysis of feature adoption across a large base of cloud software products found that roughly 80 percent of features saw low to no adoption, with a small fraction of features driving the large majority of daily usage (Pendo data, as summarized by Ant Murphy). Different methodologies, different eras, broadly consistent direction: a large share of what gets built in most software organizations is used by almost no one, and every part of that unused share continues to accrue cost indefinitely, right up until someone finally removes it.
There is a genuinely provocative claim worth stating plainly: the most expensive feature in a mature codebase may not be the one that fails most often. It may be the one that nobody uses but nobody dares to delete — kept alive by uncertainty about who might depend on it, by the diffusion of responsibility that makes deletion nobody's clear job, and by the basic organizational asymmetry that adding something generates visible credit while removing something generates only invisible risk. Companies are, almost universally, structurally better at adding than at removing. Feature deletion — deliberate, careful, well-communicated removal of functionality that no longer earns its keep — deserves to be treated as a serious engineering discipline in its own right, not an occasional cleanup task squeezed in between "real" work. In a world where creation has become cheap and abundant, the ability to remove things well may become one of the more valuable and least practiced skills in an engineering organization.
Part XII: The Rise of Software Archaeology
Project the current moment forward five years, inside an organization that has spent that time building at AI-assisted speed without a corresponding investment in inventory, documentation, and governance. What accumulates is not a single system anyone can hold in their head. It is a sprawling collection of small tools, scripts, agents, integrations, internal services, and configurations — some built by engineers, some by product managers or analysts using AI assistants directly, some by AI agents operating with minimal human supervision, and some that began as quick experiments and quietly became production dependencies because they worked well enough that nobody circled back to formalize or replace them.
Nobody in the organization remembers, with confidence, why all of it exists. This is not a hypothetical scenario — it is close to a description of what already happens inside organizations after less dramatic technological shifts, and AI-assisted development compresses the timeline sharply, because the volume of artifacts that can be created in a given period has grown even as the organization's capacity to track, document, and understand them has not.
The likely consequence is that future engineers will spend a growing share of their time not writing new software but understanding software that already exists — its provenance, its ownership, its dependencies, its actual behavior as distinct from its documented behavior, if documentation exists at all. This is a real discipline, close in spirit to what the phrase software archaeology is meant to evoke: the careful, patient work of reconstructing what a system does and why, often without the benefit of the people who originally built it, using whatever fragments of documentation, commit history, and behavioral evidence remain. Where archaeology has traditionally been a niche activity performed occasionally on unusually old or unusually neglected codebases, it may become a much more central and constant activity for teams operating systems that were substantially built through AI-assisted generation at high speed, where the volume of undocumented, half-understood functionality accumulates faster than institutional memory can keep pace.
Organizations that take this seriously in advance — building genuine dependency maps, treating documentation and ownership as first-class deliverables rather than afterthoughts, investing early in observability that reveals what a system actually does in production rather than what it was designed to do, and maintaining honest, current inventories of what exists and why — will spend far less time doing archaeology under pressure, during an incident or an acquisition due-diligence process, than organizations that let this accumulate silently.
Part XIII: Security When Everyone Can Build Software
The security implications of cheap software creation are, at their core, a volume problem before they are a technical problem, and it is worth resisting the temptation to turn this into a cybersecurity checklist rather than naming the shift clearly.
When software creation becomes accessible to more people inside an organization — not just professional engineers, but analysts, operations staff, and product managers using AI assistants to build tools that solve their own immediate problems — more internal tools get built outside traditional engineering review. More integrations connect systems that were not designed with each other in mind. More APIs get exposed, sometimes without anyone centrally tracking that they exist. More credentials and tokens move between systems as these integrations proliferate. More third-party services get connected to internal data. And, increasingly, more AI agents are granted permissions to act on an organization's behalf, often with less scrutiny than a human employee would receive for the equivalent access.
Any single tool built this way might be entirely reasonable on its own terms — a well-intentioned solution to a real, narrow problem, built by someone who understood the immediate need clearly. The difficulty is systemic rather than individual: the aggregate ecosystem of dozens or hundreds of such tools, each reasonable in isolation, becomes extremely difficult for any central function to govern, inventory, or secure, because no single team has visibility into all of it. This is directly analogous to the long-recognized problem of shadow IT — unsanctioned software and services adopted by departments outside formal technology governance — except that AI-assisted development lowers the barrier to building shadow software, not just adopting it, which expands the scope of the problem considerably. It is one thing for a department to sign up for an unauthorized SaaS tool. It is another for that department to build and operate its own application, with its own data flows and its own security posture, without engineering or security ever being consulted.
Compounding this, the underlying quality of AI-generated code itself carries measurable security risk. Veracode's research, discussed earlier, found that across major languages, AI-generated code introduced a detectable vulnerability in roughly 45 percent of tested cases, with particularly poor performance on categories like cross-site scripting and log injection — failure rates of 86 and 88 percent respectively on those specific vulnerability classes (Veracode, 2025). When that baseline risk is multiplied by a sharply growing volume of code and tools being produced by a sharply growing number of people, many of them without security training, the total exposure an organization is carrying can grow substantially even if the risk per individual tool has not changed. Governance, in this environment, is less about restricting who can build and more about ensuring that what gets built — regardless of who builds it — passes through some minimal, consistent standard of review before it touches real data or real customers.
Part XIV: The Company With Less Software May Win
It is worth directly challenging an assumption buried in most conversations about AI and software development: that more software produced means a stronger technology company. The two are not the same thing, and there are real reasons to expect they may increasingly diverge.
Imagine two competitors in the same market. Company A has 800 distinct features, accumulated over years of aggressive, AI-accelerated development. It has hundreds of integrations, a configuration surface so large that new customers require weeks of onboarding just to understand which options apply to them, and dozens of workflows that overlap in ways nobody has fully reconciled. Company B has 250 carefully selected features. Its architecture is legible enough that a new engineer can hold a meaningful mental model of it within their first month. It has fewer dependencies, which means fewer things can break in combination. Its reliability is measurably better, because there is simply less surface area for something to go wrong. Its onboarding is faster, because there is less to explain. Its support team resolves issues more quickly, because the space of possible causes is smaller. And its product team has a clearer, shared understanding of what the product is actually for, because that understanding has not been diluted across 800 divergent use cases.
Company A has technically produced more. There is no guarantee it has created more value, and a plausible case can be made that it has created less — because a meaningful share of its complexity is not serving customers, it is serving the accumulated weight of past decisions that nobody has had the discipline or the mandate to reverse. Simplicity, in this light, starts to look less like a stylistic preference and more like an economic moat: something a competitor cannot simply buy by hiring more engineers or adopting better AI tools, because simplicity is not achieved by adding capability faster. It is achieved by consistently declining to add capability that does not earn its place, which requires organizational discipline that has nothing to do with how fast anyone can generate code.
When everyone in an industry gains access to the same AI-assisted generation capability, the capacity to produce complexity stops being a differentiator, because everyone has it. The capacity to preserve simplicity in the face of that shared capability becomes rare precisely because it works against the grain of what the technology makes easy. That scarcity is where the advantage increasingly lives.
Part XV: A New Software Economic Stack
It is possible to describe the layers at which software organizations now compete, in a way that clarifies where the center of gravity is moving. This framework is offered as original to this discussion, built specifically around the argument developed above, rather than adapted from an existing published model.
Layer 1 — Generation. How cheaply and quickly can the organization turn an idea into working code? This is the layer AI has transformed most dramatically, and it is the layer that most conversations about "AI and software development" still focus on almost exclusively.
Layer 2 — Selection. How well does the organization decide what actually deserves to be built, out of everything that technically could be? This layer depends entirely on human judgment, and its importance grows in direct proportion to how cheap Layer 1 becomes.
Layer 3 — Verification. How confidently can the organization determine that a given change is correct, safe, and consistent with everything else the system already does? This is where the asymmetry described earlier in this article lives most acutely — generation has sped up; confident verification has not kept pace.
Layer 4 — Integration. How safely can new capability enter an existing, live system without breaking something else, given the compounding interactions described in the discussion of complexity? This layer requires understanding a system as a whole, not just the piece being added to it.
Layer 5 — Observation. How quickly can the organization detect that something is behaving unexpectedly, once it is in production? Abundant, fast-moving change makes strong observability more necessary, not less.
Layer 6 — Maintenance. How sustainably can the organization own, over years, everything it has chosen to build? This is the layer where the software balance sheet metaphor from earlier applies most directly, and where lifecycle-cost research consistently shows the largest share of total cost accumulates.
Layer 7 — Retirement. How effectively can the organization remove software that no longer creates value, given the organizational bias toward addition described in the discussion of unused features? This is the layer almost no organization currently treats as a discipline, and it may be the one with the most room for competitive advantage precisely because it is so neglected.
For most of software history, competitive advantage concentrated heavily at Layer 1, because Layer 1 was the bottleneck — organizations that could produce more, faster, tended to win, all else equal. AI does not eliminate the value of Layer 1. It compresses it, which pushes the center of competitive advantage upward through the stack, toward the layers that depend on judgment, verification, sustained ownership, and the discipline to remove things — layers that remain stubbornly human, expensive, and slow to build organizational capability in, even as the layer below them accelerates.
Part XVI: What an AI-Native Engineering Organization May Actually Look Like
It is worth resisting the more extreme predictions circulating about the future of engineering organizations — the vision of a handful of people running an entire company through AI agents with no meaningful human engineering team at all. The more plausible picture, grounded in what current evidence shows about where AI genuinely helps and where it introduces new burdens, looks considerably less dramatic and considerably more interesting.
Smaller teams may indeed produce larger raw output, consistent with what DORA's research already shows about individual effectiveness rising with AI adoption. But the composition of those teams is likely to shift toward more senior engineers whose primary job is supervising, reviewing, and taking responsibility for systems, rather than writing every line themselves. Platform engineering — the discipline of building the internal tools, standards, and guardrails that make it safer for others to build quickly — becomes more central, not less, echoing the DORA finding that AI's benefits depend heavily on the quality of the underlying platforms and workflows it operates within. Automated testing expands, but so does the sophistication required of it, since a larger volume of AI-generated change needs a correspondingly larger and smarter safety net to catch problems before they reach customers. Observability becomes a first-class investment rather than an afterthought, because the alternative — discovering problems only when customers report them — becomes untenable at higher volumes of change. Quality engineering, far from being displaced by AI, becomes one of the disciplines best positioned to absorb the growing verification burden this article has described at length. Product teams spend proportionally more time on requirements and outcomes and less time waiting on implementation, because implementation is no longer the bottleneck it used to be. Independent verification — someone other than the builder confirming that something works and is safe — becomes more structurally important, not less. Architecture decisions receive more scrutiny rather than less, precisely because mistakes are now easier to compound quickly across a larger volume of generated code. Purely repetitive implementation roles shrink. And ownership becomes more cross-functional, because the old boundary between "the people who build" and "the people who decide what to build" becomes less useful once building is no longer the constraint separating those two groups.
The overall shift is from software organizations that primarily functioned as production organizations — organized around the scarce activity of writing code — toward organizations that increasingly function as decision and verification organizations, organized around the scarcer activities of judgment, review, and sustained ownership. This is a different organization, with different hiring priorities, different career paths, and a different definition of what a strong engineer is good at. It is not a smaller organization, necessarily, and it is certainly not one with less need for skilled people. It is one where the skills in shortest supply have changed.
Part XVII: The CEO/CTO Question
The most important question facing a technology leader in this environment is not "how much faster can AI make our engineers." That question has a knowable, improving answer, and pursuing it in isolation is a reasonable but incomplete use of leadership attention.
The more important and more difficult question is this: what happens to our organization when the marginal cost of creating software approaches zero?
Sitting underneath that question are others that deserve to be asked directly, in leadership rooms, on a recurring basis rather than once. What actually prevents this organization from building software it does not need? Who, specifically, owns the growing complexity that gets left behind after each feature ships, and does that person or team have real authority to slow things down when complexity is compounding faster than the business can absorb it? Who has the standing to veto a feature that is individually reasonable but collectively adds too much? How does the organization measure the lifetime cost of what it builds, rather than only the cost to build it — given that the interlude on the $5,000 feature suggested those two numbers can differ by an order of magnitude? Does the organization actually know which features nobody uses, given that industry data consistently suggests the answer is "a large share of them," or is that knowledge simply absent? How quickly, in practice, could the organization remove a piece of functionality if it decided to, and has it ever actually done so? How much software is currently running in production that no single person fully understands anymore — and is that number known, or only feared? Can the organization verify changes with anything close to the confidence and speed at which it can now generate them, or has a growing gap opened up between those two capabilities? And, perhaps most pointedly: are the productivity gains AI has produced so far actually increasing the value this organization delivers, or are they primarily increasing the volume of output — a distinction that, as this article has argued throughout, is easy to conflate and expensive to conflate for very long.
These are not questions with comfortable, one-time answers. They describe an ongoing discipline, not a project with an end date, because the underlying dynamic — cheap generation continuously producing more raw material for complexity, verification burden, and maintenance obligation than the organization can process at the same pace — does not resolve itself. It has to be actively managed, indefinitely, by leadership that understands it is happening.
Ending: What Halyard Learned
A little over two years after that leadership meeting where someone floated the idea of clearing the backlog by summer, Halyard's engineering leadership sat down to do something the company had never formally done before: an inventory. Not of features shipped, but of everything currently running in production — every integration, every internal tool, every configuration flag, every automation, however small.
It took six weeks, longer than anyone expected, partly because a meaningful number of the things they found had no clear owner, and a smaller but unsettling number had no one on staff who could confidently explain what they did or why they existed. The exercise was not a failure story. Halyard had grown, its revenue had grown, and a real share of what it had built in those two years was genuinely valuable to genuine customers. But the inventory made visible something that the celebratory mood of that early leadership meeting had obscured: the company's biggest miscalculation had not been building too much, in any single decision. It had been assuming, implicitly and almost without examining the assumption, that cheaper creation meant lower overall software costs — that if a feature cost a fifth as much to build, the company was a fifth better off for having built it.
What Halyard's leadership eventually concluded, slowly and through direct experience rather than through any single realization, was that the scarce resources inside their company had not disappeared when engineering capacity stopped being the constraint. They had simply changed. Attention was scarce — there was only so much of it, and every new feature competed for a share of it, whether or not anyone tracked that competition explicitly. Judgment was scarce, in the sense that deciding what deserved to exist turned out to be a harder and more consequential skill than building whatever was decided upon. Simplicity was scarce, because the organization had gotten very good at adding and had never developed a comparable discipline for removing. Verification was scarce, because confirming that something worked had not gotten faster even though producing something that looked like it worked had. Reliability was scarce, because a system with more moving parts had more ways to fail, regardless of how each part had been built. Understanding was scarce, in the specific sense that fewer and fewer people inside the company could hold a complete, accurate model of what the product actually did. And trust — from customers, and increasingly from Halyard's own employees toward the systems they were responsible for — was scarce, and, unlike code, it could not be generated quickly by anyone.
For most of the history of the software industry, companies competed primarily to overcome the cost of building things — the scarcity that made every feature a trade-off, every roadmap a negotiation, every "yes" a hard-won decision. That competition is not over, but it is no longer where the hardest problems live. The organizations that do well in the years ahead may be the ones that learn, deliberately and early, to compete on something considerably less glamorous than production speed: the discipline of knowing what to build, the patience to verify it properly, and the willingness to remove what no longer earns its place — long after the applause for shipping it has faded.
Sources and Further Reading
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" and the underlying paper
- Google Cloud / DORA, "Announcing the 2025 DORA Report: State of AI-assisted Software Development"
- Faros AI, "Key Takeaways from the 2025 DORA Report"
- Veracode, "2025 GenAI Code Security Report" and the "Spring 2026 GenAI Code Security Update"
- Mountain Goat Software, "Are 64% of Features Really Rarely or Never Used?" — an important corrective on the origin and limits of the widely cited Standish Group statistic
- Ant Murphy, "When Did You Last Remove a Feature?" — discussion of Pendo's feature-adoption data
- IEEE Computer Society and industry benchmarking on software maintenance cost share, summarized here
Note on methodology: figures presented as illustrative thought experiments (including the "$5,000 feature that cost $200,000") are explicitly labeled as such throughout the article and are not drawn from a specific study. All statistics attributed to named research organizations are drawn from the cited sources above.
