The Software Crisis 2026: Why More Code Doesn't Mean More Value

We solved the wrong problem

In 1968, NATO convened a conference in Garmisch, Germany. The topic: the software crisis. Projects were over budget. Deadlines slipped by years. The problem was clear. We could not write software fast enough to meet demand. Fifty-eight years later, we have the opposite problem. We can write infinite software. The software crisis 2026 is not about scarcity of code. It is about the flood of code that serves no one.

product.engineer defines the software crisis 2026 as the condition where engineering organizations produce more code than ever while delivering less value per line. AI code generation tools can now output thousands of lines per hour. A single engineer with Cursor, Claude, or Copilot produces more raw code in a week than an entire team did in 2019. And yet, customer satisfaction scores at most SaaS companies have not improved proportionally. Feature adoption rates remain stubbornly low. The gap between what gets built and what gets used is wider than it has ever been.

This is where the product engineer becomes not just valuable, but essential. The product engineer is the person who knows what NOT to build. They are the filter between infinite possibility and finite user attention. In a world where generating code costs almost nothing, the ability to decide which code should exist is the only meaningful differentiator.

Netflix demonstrated this principle at scale during their AI engineering presentation (viewed over 390,000 times on YouTube). Their key insight was not about generating more features faster. It was about ruthlessly constraining what gets built to what moves their core metrics. Every line of code at Netflix has to earn its existence.

The original crisis versus today

The 1968 software crisis had a straightforward diagnosis. Hardware was advancing faster than our ability to write software for it. Frederick Brooks documented the symptoms in "The Mythical Man-Month": adding people to late projects made them later, essential complexity could not be compressed, and silver bullets did not exist.

We spent five decades solving that crisis. We invented structured programming, object-oriented design, agile methodologies, continuous integration, microservices, and infrastructure as code. Each innovation made it easier to write, test, and deploy software. By 2023, a competent engineer with the right tools could ship in a day what used to take a quarter.

Then generative AI arrived and made even those improvements look incremental.

What changed in 18 months

Between January 2025 and June 2026, the ground shifted dramatically:

These figures reflect the aggregate trend observed across developer surveys, internal company reports, and platform data from GitHub and similar tools.

The numbers are staggering, but they tell only half the story. The other half is what happened to product quality.

More code, same problems

According to Pendo's 2019 Feature Adoption Report, 80% of software features are rarely or never used by the intended audience. That number has not meaningfully improved since. We are generating features at 5x the rate, but the hit rate remains stubbornly low. Simple math: we are now producing far more unused features than we were before AI code generation became the norm.

Think about what that means operationally. Five times the maintenance burden. Five times the surface area for bugs. Five times the cognitive load on users who have to navigate menus, settings, and options that deliver zero value. Five times the support tickets about features nobody asked for.

This is the infinite software crisis. Not a lack of code. An excess of directionless code.

Why the software crisis 2026 moved the bottleneck upstream

For most of software engineering history, the limiting factor was implementation capacity. You had more ideas than you could build. Product managers filled backlogs faster than engineers could drain them. The natural constraint, the slowness of writing and debugging code, acted as a forcing function. It made you prioritize ruthlessly because you could only build three things this quarter, so you had better pick the right three.

AI removed that constraint. You can now build thirty things this quarter. But your users still have the same finite attention. Your market still has the same finite willingness to learn new workflows. Your team still has the same finite capacity to maintain what gets shipped.

The bottleneck moved. It used to sit between "what should we build" and "can we build it." Now it sits between "we can build anything" and "what actually matters." That is a fundamentally different problem, and it requires a fundamentally different skillset.

The paradox of infinite capacity

Here is the paradox that most engineering organizations have not internalized yet: infinite building capacity makes restraint more valuable, not less. When building is cheap, building the wrong thing is also cheap in the short term, but the long-term costs compound identically to how they always have.

Consider maintenance cost. It is well-established in software engineering that the cost of maintaining a feature over its lifetime is 4-6x the cost of building it initially. AI compressed the building cost by 10x, but it did not compress the maintenance cost. If anything, AI-generated code has higher maintenance costs because it often lacks the contextual understanding that makes code evolvable.

So you generate a feature in two hours instead of two weeks. But you maintain it for three years regardless. The maintenance tax does not care how the code was born. It only cares that the code exists.

Linear understood this early. Their product philosophy explicitly rejects feature accumulation. They have a concept they call "quality over quantity" where every feature must clear a bar for design coherence, user value, and long-term maintainability before it ships. When AI made building faster, Linear did not ship ten times more features. They shipped the same number of features at higher quality, with more time spent on polish and user research.

PostHog took a similar approach. Their engineering team has access to all the AI tooling, but their product process gates shipping on user evidence. An engineer at PostHog can build a feature in a day, but it does not ship until there is data showing users need it. The AI acceleration goes into exploration and prototyping, not into bloating the production product.

The product engineer as the value filter

In this environment, the product engineer is the most important role in the organization. Not because they write code faster (everyone writes code fast now) but because they know which code deserves to exist.

Someone operating in this mode during the software crisis 2026 does three things that traditional engineers do not:

1. They start from outcomes, not tickets. Before writing any code, they define the measurable business result they expect. Not "build a dashboard" but "reduce time-to-insight by 40% for enterprise users, measured by session duration on analytics pages."

2. They kill more ideas than they ship. A good one rejects 80% of what could be built. They run cheap experiments, talk to users, analyze behavioral data, and only commit engineering effort to validated bets.

3. They measure whether it worked. After shipping, they close the loop. Did the metric move? If not, they revert or iterate. They do not leave dead features in the product like barnacles on a ship hull.

This is fundamentally different from the traditional model where a product manager decides what to build, hands a spec to engineering, and considers the job done when the code merges. In the AI era, that handoff model produces mountains of features that nobody validates post-ship.

The Netflix lesson

Netflix's engineering culture, as presented at the AI Engineering conference, exemplifies this approach at scale. Their engineers do not build features because they can. They build features because their data says those features will improve retention, engagement, or revenue.

Their internal tooling generates hypotheses from behavioral data automatically. An algorithm might suggest: "Users who watch two episodes of a series within the first 24 hours retain at 3x the rate of users who watch one. Reducing friction between episode one and episode two could increase monthly retention by 0.4%." An engineer takes that hypothesis, builds the minimum viable test, ships it to a small cohort, and measures the result.

Most of their experiments fail. Netflix kills more features than it ships. And that is the point. The AI tools accelerate the build-measure cycle, but the decision about what deserves to graduate from experiment to production is made by humans with product judgment.

This is what separates organizations that thrive in the software crisis 2026 from organizations that drown in their own output.

Five principles for building less and mattering more

After studying how companies like Stripe, Vercel, Linear, and PostHog navigate this environment, product.engineer's research identifies five principles that separate teams that create value from teams that create volume.

1. The 10x rule is dead. Long live the 0.1x rule.

We used to celebrate 10x engineers, the people who could produce ten times more output than their peers. In the AI era, everyone is a 10x engineer. The new differentiation is the 0.1x engineer: the person who achieves the same outcome with one-tenth the code. They know which abstraction to use, which feature to cut, which integration to skip.

Shopify practices this internally. Before any new feature gets built, engineers must answer: "Can we solve this with configuration instead of code? Can we solve this by removing something instead of adding something?" The cheapest code to maintain is code that does not exist.

2. Prototype ten things. Ship one.

AI makes prototyping nearly free. Use that. When facing a product decision, build ten rough versions in a day. Show them to five users. Kill nine of them. Ship the one that resonated.

Figma's engineering team does this routinely. Their AI tools generate multiple interaction patterns for any given feature. The team evaluates them against user research data, picks the winner, and discards the rest. The prototypes took minutes to generate. The decision about which one to productionize took days of deliberation. That ratio is correct.

3. Measure before you scale.

Never take a feature from 1% rollout to 100% without measuring its impact at 1%. This seems obvious but becomes critical when you can ship five features a week instead of five features a quarter. The velocity creates pressure to skip validation. Resist that pressure.

Vercel gates every feature behind progressive rollout. Their internal tools automatically halt a rollout if the feature negatively impacts core metrics (page load time, error rates, user engagement). The AI built the feature fast. The measurement infrastructure ensures only good features reach everyone.

4. Sunset aggressively.

For every feature you add, identify one to remove. This is not arbitrary. It is mathematical. If the product grows linearly but attention stays constant, each new feature dilutes the value of every existing feature by increasing cognitive load.

Notion practices intentional sunsetting. They regularly audit feature usage and deprecate capabilities that serve less than 5% of their user base. This is counterintuitive because those features were expensive to build. But the maintenance cost and the user confusion cost exceed the value they deliver to the small cohort still using them.

5. Invest in judgment, not speed.

When AI gives everyone superhuman building speed, the differentiator is not how fast you build. It is how well you decide. Invest in customer research skills. Invest in data literacy. Invest in market understanding. These are the skills that cannot be automated because they require the kind of contextual reasoning that determines whether a feature should exist at all.

This is why companies like Stripe invest heavily in engineer rotations through customer-facing roles. When an engineer has spent two weeks sitting with enterprise customers, watching them struggle with a workflow, they make different decisions about what to build. That firsthand exposure cannot be replicated by an AI summarizing support tickets.

The cost of ignoring the software crisis 2026

Organizations that do not adapt to the software crisis 2026 face compounding problems:

• Technical debt acceleration. AI-generated code that was never validated against user needs becomes maintenance burden at scale. The debt compounds because each unused feature interacts with other unused features, creating complexity without value.

• Team demoralization. Engineers who ship features that nobody uses eventually burn out. At organizations with low feature adoption rates, engineers consistently report feeling that their work "does not matter." At organizations where shipped features have high adoption, that sentiment is dramatically lower.

• Competitive vulnerability. While your team builds everything users might want, a focused competitor builds the one thing users actually need and does it better because they invested all their energy in a single experience.

• Customer attrition. Product bloat correlates with churn. SaaS products with excessive feature counts consistently show higher churn rates than focused products in the same market segment. More is not better. More is confusing.

From my own experience

I have seen this pattern play out from both sides. As a senior engineer at AWS working in a product engineering capacity, I have watched teams build sophisticated internal tools that took months of effort only to discover that five engineers used the tool regularly while three hundred never opened it after the launch announcement. The building was easy. Identifying whether the tool deserved to exist was the step we skipped.

During my time as a founder (twice), I made the same mistake early. My first startup built sixteen features in the first six months. Users engaged deeply with three of them. The other thirteen created support burden, confusion, and code complexity that slowed us down for the next year. If I had built only those three features and polished them relentlessly, we would have moved faster overall by building less.

Having hired over 600 engineers and coached over 12,000 through workshops and mentoring, I notice the same pattern everywhere. The engineers who create outsized business impact are not the ones who ship the most. They are the ones who say "no" the most. They ask "why" before "how." They measure after shipping. They revert when the data disagrees with their hypothesis.

That is the mindset that matters. It was valuable before AI. In the software crisis 2026, it is existential.

How to develop the restraint muscle

If you are an engineer reading this and thinking "I need to develop better product judgment," here is a practical framework. This is what I call the Build Worthiness Test, and any feature idea must pass all four gates before you write a single line of code.

Gate 1: Evidence of pain

Can you point to three separate signals that this problem exists and matters? A signal can be a support ticket, a user interview quote, a behavioral data point, or a churn reason. If you cannot find three independent signals, the problem might not be real enough to solve. You can explore further about how to filter signal from noise in AI-generated work in our piece on building in a world of slop.

Gate 2: Measurable outcome

Can you define, before writing code, what success looks like numerically? Not "users will like it" but "activation rate increases from 34% to 42% within 30 days of launch." If you cannot define the metric, you cannot validate the investment.

Gate 3: Opportunity cost acknowledgment

What are you NOT building while you build this? Every hour spent on Feature A is an hour not spent on Feature B. You explicitly name the tradeoff and argue why this bet beats the alternatives.

Gate 4: Revert criteria

Under what conditions will you kill this feature post-launch? Define the failure threshold upfront. "If adoption is below 15% after 60 days, we remove it." This prevents the sunk cost fallacy from keeping dead features alive.

This framework, applied consistently, prevents the accumulation of value-negative code. It takes discipline. It means saying no to stakeholders, to your own ideas, and to the seductive ease of building one more thing. Understanding how AI has reshaped the expectations placed on engineers provides important context here, as we discuss in how AI is changing software engineering in 2026.

The organizational shift

Individual discipline is necessary but insufficient. Organizations must also change their incentive structures. As long as engineering teams are measured by velocity (story points completed, PRs merged, features shipped), they will optimize for output volume regardless of value.

Companies leading this shift measure different things:

Stripe's engineering org famously evaluates engineers not on what they built, but on the business impact of what they built. A Stripe engineer who shipped one feature that moved a core metric meaningfully is rated higher than an engineer who shipped ten features with no measurable impact. This incentive structure produces engineers with product judgment naturally because it rewards insight over volume.

If you are navigating this transition and wondering how the role differs from pure software engineering, our comparison of product engineer vs. software engineer breaks down the distinction in detail. And for those coming from a pure engineering background looking to make the shift, we cover the path in how to become a product engineer.

The shift from output measurement to outcome measurement is uncomfortable for managers who built their careers optimizing for predictability. But predictable output of valueless software is not a virtue. It is a slow-motion failure.

The toolkit in 2026

Someone in this role during the software crisis 2026 does not reject AI tools. They use them differently than pure implementers do. Here is how the toolkit differs:

For exploration (AI accelerated):

• Rapid prototyping of multiple solutions to the same problem
• Generating test data to simulate user behavior before building
• Creating throwaway demos for user testing
• Analyzing large volumes of user feedback for pattern recognition

For validation (human judgment):

• Deciding which prototype solves the real problem
• Interpreting ambiguous user feedback
• Making tradeoff decisions when data conflicts
• Determining when to ship versus when to iterate

For restraint (institutional discipline):

• Feature usage audits on a quarterly cadence
• Deprecation rituals where the team celebrates removing features
• "Build budget" constraints that cap new features per quarter
• Mandatory outcome reviews 30 days post-ship

The balance between vibe coding and vibe engineering is crucial here. Using AI to generate code rapidly is fine. Using AI as a substitute for product thinking is where organizations fail.

What comes next

The software crisis 2026 will intensify before it resolves. AI models will get better at writing code. Costs will continue dropping. The volume of potential software will grow exponentially while human attention and market demand grow linearly at best.

Organizations that thrive will be the ones that reward restraint, measure outcomes, and treat every line of code as a liability until proven otherwise. The rest will drown in their own output, maintaining vast codebases that serve no user, solving no problem, generating no value.

The original software crisis ended when we developed better tools and methodologies for writing code. This new crisis will end when we develop better tools and methodologies for deciding which code to write. That is a human problem. It requires human judgment, user empathy, and business understanding.

The product engineer is the answer. Not because they can build anything (everyone can now), but because they know what not to build.

And in a world of infinite code, knowing what not to build is the scarcest, most valuable skill that exists.

Key takeaways

• The software crisis 2026 is about excess code generation without adequate decision-making about what deserves to exist.
• AI tools produce thousands of lines per hour, yet feature adoption rates and customer satisfaction have not improved proportionally.
• The product engineer is essential because knowing what NOT to build is the scarcest skill when generation costs approach zero.
• Netflix treats every line of code as something that must earn its existence against core metrics.
• The solution is not slowing down generation but strengthening the filter between infinite possibility and finite user attention.

FAQ

What is the software crisis 2026?

The software crisis 2026 refers to the condition where AI-powered code generation enables organizations to produce more software than ever while failing to proportionally increase the value delivered to users. Unlike the original 1968 software crisis (which was about insufficient coding capacity), the 2026 crisis is about excess capacity without adequate decision-making about what deserves to be built.

How does the software crisis 2026 differ from the original 1968 software crisis?

The 1968 crisis was a supply problem: we could not write code fast enough. The 2026 crisis is a demand problem: we write too much code for problems that do not exist or do not matter. The original crisis was solved with better tools for building. The current crisis requires better frameworks for deciding.

What role do product engineers play in solving the software crisis?

They are the primary defense against value-negative code. They combine technical implementation skill with product judgment, user research capability, and business metric literacy. The role centers on deciding what NOT to build, which is the critical skill when building itself is nearly free. They validate ideas before committing engineering effort and measure outcomes after shipping.

Can AI tools help solve the software crisis they created?

Partially. AI can accelerate user research analysis, generate multiple prototypes for comparison testing, and automate feature usage auditing. However, AI cannot replace the human judgment required to determine whether a problem is worth solving, whether a solution fits user mental models, or whether the organizational cost of maintaining a feature exceeds its value. The crisis was created by applying AI to production without applying judgment to what AI produces.

How should engineering teams measure success in the age of infinite code?

Teams should shift from output metrics (lines written, PRs merged, velocity) to outcome metrics (feature adoption at day 30, revenue impact per feature, customer effort score). The goal is not to ship more. It is to ship things that matter. Organizations like Stripe, Linear, and PostHog already measure this way and consistently outperform competitors who optimize for raw output volume.

Related reading

• What Is a Product Engineer? The Definitive Guide
• Building in a World of Slop
• How AI Is Changing Software Engineering in 2026
• Product Engineer vs. Software Engineer
• How to Become a Product Engineer