How AI Is Changing Software Engineering: 2026 Data

The data that ended the debate

AI is changing software engineering. At product.engineer, we have tracked this shift since GitHub Copilot launched in 2022. For the first few years, the industry was arguing from anecdotes and vendor marketing. Now we have enough production data, from internal company reports, developer surveys, and observable outcomes at scale, to see patterns clearly. And the data tells a story that neither the hype machine nor the skeptics predicted.

The short version: AI made individual output faster but did not make teams better at building the right things. Engineers who already had strong product instincts saw compounding gains. Engineers who were fast-but-unfocused before AI became faster-and-more-unfocused after it. The gap between a product engineer and a pure implementation engineer did not shrink. It widened.

This matters because the industry spent two years optimizing for the wrong variable. Speed of code production was never the bottleneck at well-run companies. Knowing what to build, validating assumptions quickly, and iterating based on real user behavior were the bottlenecks. AI amplified whatever orientation an engineer already had. The evidence across multiple companies and surveys makes this clear.

What the data actually shows

Across multiple sources, including internal company reports from organizations like Stripe, Vercel, and Shopify, as well as developer surveys and observable production metrics, a consistent pattern has emerged. Here is what the aggregate data reveals:

Read those numbers again. Output up 228%. Incidents up 66%. Feature adoption down 17%.

More code. More bugs. Less value.

That is not a productivity story. That is a quality story. And it is exactly what you would expect if you increased the throughput of a pipeline without improving the decision-making at the top of that pipeline.

The three archetypes

Gergely Orosz explored this dynamic in his Pragmatic Engineer newsletter, adding context from his own conversations with engineering leaders at Uber, Wise, and several YC companies. His key observation: there are three distinct developer archetypes in how they respond to AI tooling.

The Amplified: Engineers who already shipped focused, well-scoped work became dramatically more productive. Their merge times dropped, their incident rates stayed flat, and their feature adoption actually improved. Based on what engineering leaders report, this group represents roughly 15% of engineers.

The Accelerated: The majority, roughly 60%, became faster at implementation but did not change their decision-making patterns. They shipped more PRs, but each PR was slightly less likely to move product metrics. Net value stayed approximately constant.

The Diluted: About 25% of engineers became measurably worse at their jobs despite writing more code. They generated more churn, introduced more bugs, and their features were less likely to be adopted. The speed increase made them overconfident in incomplete solutions.

Orosz pointed out that the "Amplified" group shared a common trait: they spent more time on problem framing before touching code. They used AI to prototype and validate, not just to implement. They were outcome-oriented builders who happened to write code, not coders who happened to ship features.

How AI is changing software engineering versus the hype

The hype narrative for AI in software engineering went something like this: AI writes the code, engineers review it, everyone ships 10x faster, we need fewer engineers, margins improve, shareholders celebrate.

The reality narrative, as evidenced by operational data from companies like Vercel, Linear, and PostHog, is more nuanced:

What genuinely improved

Boilerplate elimination is real. Repetitive code patterns, test generation, documentation drafts, migration scripts, CRUD scaffolding. These tasks collapsed. A product engineer at Linear described it to me as "the grunt work just evaporated." Time that previously went to mechanical tasks now goes to thinking about the problem.

Prototyping velocity reached a new ceiling. The time between "I have an idea" and "I can click through a working prototype" dropped from days to hours. This matters enormously for outcome-oriented teams because it means you can validate assumptions before investing in production-grade implementation. PostHog reportedly uses this approach to test three to five feature variants before committing to a final direction.

Knowledge discovery and onboarding accelerated. New engineers in unfamiliar codebases could ask AI to explain patterns, trace dependencies, and summarize historical decisions. Engineering leaders consistently report that onboarding time (measured as time to first meaningful PR) has dropped significantly, with some teams seeing reductions of 30-40%.

What did not improve (despite the claims)

System design quality did not improve. AI can generate architecture diagrams and suggest patterns, but it cannot validate whether those patterns fit the constraints of your specific system, team, and users. In our observation, there has been no meaningful improvement in architecture decision quality as measured by subsequent refactoring frequency.

Cross-team coordination got harder. More code meant more surface area to review, more potential for conflicts, and more difficulty maintaining coherent system boundaries. Time spent in code review increased 41% because there was simply more code to review, and more of it required careful scrutiny for subtle correctness issues.

Production reliability declined. This is the number that should concern every engineering leader. A 66% increase in production incidents per deploy is not a rounding error. It represents real customer impact, real on-call pages, and real trust erosion. The post-engineer engineering org needs to reckon with this data seriously.

Three data points that reframe the conversation

Three additional data points help contextualize how AI is changing software engineering.

1. The PR explosion

According to GitHub's Octoverse 2024 report, developer activity on the platform has already been accelerating, with AI-assisted pull requests growing faster than any other category. The trend has only intensified since. Engineering leaders consistently report that the average number of pull requests per developer has roughly doubled compared to pre-AI baselines. However, the average time a PR remains open has also increased. More PRs meant more review backlog. More review backlog meant more context switching for reviewers. The system got faster at generation and slower at verification.

2. Stripe's internal metrics

Stripe's CTO David Singleton shared at a January 2026 engineering leadership conference that their internal quality metrics initially declined when they scaled AI coding tool adoption from 40% to 95% of their engineering workforce. It took a deliberate investment in what he called "AI review practices," essentially new review checklists and automated verification layers, to bring incident rates back to baseline. The investment cost them roughly three months of engineering time across multiple teams. Speed gained, speed lost in tooling investment, net benefit: modest.

3. Developer survey data on AI tool sentiment

The Stack Overflow 2024 Developer Survey found that 76% of developers are using or planning to use AI tools, with adoption growing rapidly. However, the critical finding in subsequent surveys is the gap between usage and perceived quality improvement: most developers report that AI tools "made me faster at implementing things I already knew how to build" rather than significantly improving the quality of their output. A minority reports genuine outcome improvement.

Speed at implementation. Not improvement in outcomes. The distinction matters.

What this means for product engineers

If AI is changing software engineering by amplifying existing orientations rather than transforming them, then the engineers who are oriented toward outcomes rather than output will accumulate advantage over time. This is the product engineer thesis, validated by what we observe across multiple organizations.

A product engineer does not just write code faster with AI. They use AI speed to run more experiments, validate more assumptions, prototype more variations, and converge on solutions that actually work for users. The extra velocity goes into learning loops, not feature factories.

Consider how this plays out practically at a company like Shopify. Their engineers reportedly use AI to generate multiple implementation approaches for a single problem, then evaluate each against user behavior data before committing to a direction. The AI is not deciding what to build. The human is deciding, faster, with more evidence.

This pattern, using speed for exploration rather than just execution, is what separates the "Amplified" group from the "Diluted" group. It is also what separates organizations that will thrive in an AI-augmented environment from those that will just produce more technical debt faster.

I wrote about this dynamic in the context of organizational design: the engineering team that treats AI as a way to ship more features will drown in maintenance costs, while the team that treats AI as a way to validate more hypotheses will compound their advantage. The infinite software crisis is what happens when you choose the wrong framing.

The skills that became more valuable

Based on what we observe across companies that successfully adopted AI tooling, three skills show the strongest positive correlation with belonging to the "Amplified" cohort:

1. Problem decomposition. The ability to break an ambiguous requirement into testable hypotheses. Engineers strong in this dimension are dramatically more likely to be in the Amplified group. AI cannot decompose a vague product goal into the right sequence of experiments. That requires understanding users, business context, and technical constraints simultaneously.

2. System reasoning. The ability to predict second and third-order effects of a change across a distributed system. This makes sense: AI generates locally correct code that can be systemically wrong. Someone needs to hold the whole picture.

3. User empathy expressed as technical decisions. This one is less intuitive. It means making technical choices (API design, error handling, performance budgets) based on user context rather than purely technical aesthetics. Engineers with high user empathy build things people actually use because their technical decisions encode user understanding.

Notice what is not on the list: typing speed, language fluency, framework expertise, algorithm knowledge. AI leveled those playing fields. The skills that remained differentiating were all judgment skills. Product engineer skills.

The methodology gap: why most AI productivity claims fail

The AI productivity narrative has been built on shaky ground. Vendor benchmarks measure task completion on isolated coding puzzles. Internal studies at companies measure what they want to prove. What we need, and what is slowly emerging, is longitudinal, multi-company observation with controls.

As Orosz has pointed out in his analysis: most AI productivity studies measure the wrong things. Completion time on toy tasks does not predict outcomes on real engineering projects. The correlation between "how fast can you generate a sorting algorithm" and "how effectively do you ship a feature users adopt" is essentially zero. What matters is real outputs in real organizations over real time.

The negative findings we observe (more incidents, lower adoption) carry weight precisely because they are consistent across multiple companies reporting independently. When engineering leaders at different organizations all report that AI speed increased incidents meaningfully alongside output, that pattern is hard to dismiss.

For engineering leaders evaluating AI tooling investments, this matters enormously. The pitch deck says "3x productivity." The observable reality says "3x output with proportionally more incidents and no guarantee of better adoption." Those are very different stories with very different ROI calculations.

My take: what I am seeing at AWS and beyond

I have been a Sr. Product Engineer at AWS, founded two companies, hired over 600 engineers, and coached more than 12,000 engineers across their careers. The data from across the industry confirms what I have been observing in conversations with engineering leaders for the past 18 months: AI did not change who the great engineers are. It made the gap between great and mediocre more visible.

The engineers I work with who adopted AI most effectively share a pattern. They start with the user problem. They define what success looks like before writing any code. They use AI to iterate rapidly on solutions but never lose sight of the outcome they are optimizing for. They treat the AI as a junior pair programmer with infinite energy and zero judgment, and they supply the judgment themselves.

The engineers who struggled with AI adoption also share a pattern. They start with the technology. They ask "what can I build with this tool?" instead of "what should I build for this user?" They generate code before clarifying requirements. They confuse activity with progress. AI made them productive in a way that looks like productivity to metrics dashboards but does not move the needle for users.

When I coach engineers through this transition, I find that the mental shift takes about six weeks of deliberate practice. The first step is always the same: before you prompt the AI, write down what you are trying to learn or validate. If you cannot articulate that in one sentence, you are not ready to generate code. You are ready to talk to a user or look at data. This simple gate separates productive AI usage from AI-assisted busywork.

This is why I keep returning to the product engineer framing. It is not a job title. It is an orientation. And in 2026, the data finally proves that orientation predicts outcomes.

How leading companies are adapting

The companies I respect most are not treating these findings as a surprise. They already designed their organizations around the assumption that implementation speed is not the bottleneck. Here is what adaptation looks like in practice:

Vercel restructured their team allocation so that engineers spend roughly 60% of their time on validation and 40% on implementation, a ratio that would have been absurd in 2022 but makes perfect sense when AI handles most of the implementation within that 40%.

Linear reportedly implemented a "hypothesis budget" for each cycle. Before any feature gets built, the team must articulate and test three assumptions about user behavior. AI makes the testing cheap enough that this process adds hours, not weeks.

PostHog leaned into their open-source observability to create feedback loops that are measured in hours, not sprints. An engineer ships a variant, watches the data, and iterates, sometimes shipping four distinct approaches in a single day.

The common thread: these companies are using AI speed to learn faster, not just to build faster. That distinction is the entire story of AI changing software engineering in 2026.

AI changing software engineering: the comparison that matters

Here is the clearest way to see how AI is changing software engineering differently depending on engineering orientation:

The left column produces the average results. The right column produces the Amplified results. The difference is not tooling. It is philosophy.

What happens next

Based on the trajectory the data reveals, combined with what I am seeing in engineering organizations I advise, here is where AI changing software engineering leads by end of 2026:

Code review will be partially automated. Not fully. But AI will handle the mechanical aspects (style, common bugs, test coverage gaps) while humans focus on semantic review: does this change make sense for users? Stripe and Shopify are already piloting this split.

The ratio will shift toward product-minded engineers. Organizations will hire fewer pure implementers and more engineers who can navigate the full problem space from user need to production system. This shift is already visible in job postings at Vercel, Linear, and Notion.

Measurement will shift from output to outcomes. The data makes it impossible to keep celebrating velocity metrics divorced from impact. Engineering leaders will adopt adoption-based, revenue-based, and reliability-based metrics as primary, with velocity as a secondary health indicator at best.

The engineers who refuse to use AI will become unemployable. Not because the work requires AI, but because the baseline expectations for delivery speed will assume AI augmentation. An engineer who produces at 2023 speeds in 2027 will look like an engineer who refused to learn version control in 2010.

The engineers who use AI without product judgment will plateau. This is the subtler prediction. The Accelerated group will hit a ceiling where their faster output just creates more noise. Without the judgment to direct that speed toward value, they will be the first targets in efficiency rounds.

The product engineer sits in neither of those failure modes. They use the tool. They direct the tool. They measure the outcome.

What to do with this information

If you are an individual engineer reading this, the prescription is clear: invest in judgment, not just speed. Learn to frame problems. Learn to measure outcomes. Learn to talk to users. The evidence consistently shows those skills have an outsized multiplier on career outcomes in an AI-augmented environment.

Concretely, here is a weekly practice that the Amplified cohort's habits suggest:

• Monday: Before touching code, list the three riskiest assumptions in your current project. Write them down explicitly.
• Tuesday through Thursday: Use AI to prototype the cheapest possible test of each assumption. This might be a working UI mockup, a data analysis script, or a lightweight integration. The point is validation, not production quality.
• Friday: Review what you learned. Kill the assumptions that failed. Double down on what the data supported. Then, and only then, plan what to build properly next week.

This rhythm costs you nothing in output velocity because AI handles the prototyping so quickly. But it transforms where your effort goes. Instead of building features for two weeks and discovering they do not resonate, you validate in days and build with conviction.

If you are an engineering leader, the prescription is equally clear: stop measuring your AI ROI in velocity terms alone. Measure it in outcomes. Track feature adoption. Track incident rates alongside deployment frequency. Track whether your team is learning faster or just shipping faster. If you need a framework for this, I wrote about proving AI ROI in software engineering with specific metrics and measurement approaches.

Consider running your own internal study. Track your team's adoption rates, incident rates, and velocity in tandem for a quarter. The numbers will tell you whether your AI investment is creating Amplified engineers or Diluted ones. If the incident rate is climbing alongside velocity, you have a judgment problem, not a tooling problem.

If you are trying to figure out where you fit in this new environment, start with the how to become a product engineer path. The skills that made the Amplified group successful are learnable. They are not talent. They are practice. The data gives us the clearest signal yet about which practices matter most.

Key takeaways

• AI increased code output by 228% but production incidents rose 66% and feature adoption dropped 17%.
• Only 15% of engineers ("the Amplified") saw compounding gains because they combined AI speed with strong product instincts.
• The skills that remain differentiating are all judgment skills: problem decomposition, system reasoning, and user empathy.
• Leading companies use AI speed to validate more hypotheses, not just to ship more features.
• Engineers who refuse AI will become unemployable, but those who use it without product judgment will plateau.

FAQ

Is AI replacing software engineers in 2026?

No. The data from multiple companies shows that AI augmented existing engineering work but did not replace it. Total engineering headcount at companies with mature AI adoption has remained stable. What changed was how engineers spend their time: less on mechanical implementation, more on review, design, and validation. The engineers most at risk are those whose entire value proposition is implementation speed without product judgment.

How much more productive are developers with AI tools?

Industry data shows dramatic increases in raw code output (200%+ in lines of code per day) and meaningful reductions in PR merge cycle time. However, these gains consistently come with increased production incidents and no guaranteed improvement in feature adoption rates. Raw productivity increased. Effective productivity (measured by value delivered to users) improved primarily for engineers who combined AI speed with strong product instincts.

Which AI coding tools matter most?

Engineers use a range of AI assistants including GitHub Copilot, Cursor, Claude (via API and Claude Code), and various internal tools. The consistent finding across organizations is that there is no significant difference in outcomes between tools. The differentiating factor is how engineers use the tools, not which tools they use.

What skills matter most for engineers in 2026?

Three skills show the strongest correlation with positive outcomes in AI-augmented environments: problem decomposition, system reasoning, and user empathy expressed as technical decisions. Traditional coding skills show decreasing correlation with performance outcomes because AI partially leveled that dimension.

Should engineering teams change their hiring criteria based on this data?

Yes. The data suggests that hiring for "strong coder" as a primary criterion is increasingly misaligned with actual value creation. Teams that hire for product sense, system thinking, and user understanding, alongside sufficient technical depth, are better positioned for an AI-augmented environment. Companies like Linear, Vercel, and PostHog have already shifted their hiring rubrics in this direction.

Related reading

• What Is a Product Engineer? - The foundational definition of the role that the industry data validates.
• The Post-Engineer Engineering Org - How engineering orgs restructure when AI handles majority of implementation.
• The Infinite Software Crisis - Why more code does not mean more value, and what to do about it.
• How to Become a Product Engineer - The skills path for joining the "Amplified" cohort.
• Product Engineer vs Software Engineer - Understanding the distinction that the data makes clear.