The Impact of AI on Software Development: What the Data Shows and What It Means for Enterprise Teams

AI adoption in software development is effectively settled. DORA’s 2025 research, drawn from nearly 5,000 technology professionals, put adoption at 90% of respondents, a 14-point jump in a single year.¹

What is not settled is the impact. The same body of research that documents near-universal adoption also documents rising delivery instability, a persistent gap between how fast developers feel and how fast they actually are, and a concerning security failure rate on generated code that has barely moved in two years.

This guide separates what the evidence supports from what the marketing claims. It covers where AI has genuinely changed the work, what the productivity studies actually measured, the quality and security tradeoffs that come with volume, how individual roles are shifting, and why enterprise codebases constrain results in ways greenfield demos never surface, all judged against our own experience with using AI-assisted code generation tools on real projects.

What this guide covers:

1. Where AI Has Measurably Changed the Work

2. The Productivity Question: What the Research Actually Measured

3. The Quality and Security Tradeoff

4. What Changes by Role

5. Why Enterprise Codebases Constrain the Gains

6. A Practical Adoption Sequence

7. Frequently Asked Questions

1. Where AI Has Measurably Changed the Work

Some of the change is real and durable. AI has meaningfully compressed the time spent on a specific band of tasks: boilerplate generation, test scaffolding, unfamiliar syntax lookup, first-draft documentation, regex and query construction, and the initial orientation pass when a developer opens a codebase they have never seen. These are tasks where the cost of a wrong answer is low and the cost of verification is trivial. These are low-value tasks that every developer had to do, whether they liked it or not, and are now able to offload them to reclaim some brain power for more cognitively demanding tasks.

The 2025 arrival of agentic tooling extended that range. Where earlier assistants operated at the level of autocomplete and chat, agentic tools take multi-step action across a repository, which moves them from suggestion into execution. Veracode’s 2026 research found that in organizations that have adopted AI coding tools, AI now authors roughly half of all committed code.² Keyhole’s own experience with these tools corroborates that finding, with adoption starting at a gradual pace before shifting to aggressive usage.

The critical qualifier comes from DORA: AI functions as an amplifier rather than a fix. It magnifies the strengths of high-performing organizations and magnifies the dysfunctions of struggling ones.¹ A team with clear requirements, strong test coverage, and healthy review discipline gets faster. A team without those things ships defects faster.

In Keyhole’s experience: the amplifier effect plays out at the codebase level before it shows up in any survey. Teams that already had disciplined branching, test coverage, and code review standards adopt AI tooling cleanly. Teams without that foundation see AI accelerate the accumulation of technical debt rather than reduce it. Before recommending AI tooling on an engagement, we assess that foundation first, not the tooling.

The Adoption Curve in Numbers

The market data confirms the survey data. GitHub Copilot alone crossed 20 million all-time users by July 2025, up from 15 million just three months earlier, with adoption reaching roughly 90% of Fortune 100 companies.⁷ Gartner separately sized the enterprise AI coding agent market at roughly $9.8 billion to $11 billion annualized as of April 2026.⁸

The same shift shows up from the demand side. Stack Overflow’s own data, tracked through its public Data Explorer, tells a stark version of the story:

• The platform received more than 207,000 new questions in a single month at its March 2014 peak.
• Question volume had already been declining for years as developers moved toward other community platforms, but the drop accelerated sharply after ChatGPT’s release in November 2022.
• By December 2025, monthly questions had fallen to 3,862, a 78% year-over-year decline, and volume was down to 1,442 questions by July 2026, roughly 99% below the 2014 peak and a level the site hadn’t seen since its first year online.¹³

Developers haven’t stopped needing answers. They’re getting them from a model directly instead of searching a Q&A archive or posting a question and waiting on a community to respond.

Tooling at that scale is no longer a pilot-stage experiment. It is becoming the default infrastructure, which is part of why the productivity and security questions below carry more weight than they did two years ago.

2. The Productivity Question: What the Research Actually Measured

This is where the gap between perception and measurement is widest, and where engineering leaders are most likely to plan against a number that does not exist.

Three conclusions follow from reading these together.

1. First, self-reported productivity is not a reliable input to planning, because the one study that measured completion time directly found it pointing the opposite direction from developer perception.

2. Second, the tooling has moved fast enough that findings age quickly, and the honest position is that the 2026 picture is better than the 2025 picture by an amount nobody has cleanly measured yet.

Keyhole’s own consultants report that the gain feels qualitatively different since Claude Opus 4.6, describing it as a real, sustained speedup rather than the kind of self-reported optimism METR’s own data warns against. That’s firsthand engineering experience, not a controlled measurement, and it should be read that way: it’s a data point for where the 2026 picture may be heading, not a correction to what METR found.

3. Third, gains concentrate on well-defined tasks and thin out sharply on complex work inside mature systems.

From Keyhole’s perspective: this matches what we see across delivery engagements. Our teams get real, measurable time savings on test generation, scaffolding, and orientation in unfamiliar legacy code. Those gains shrink or disappear on architecture decisions and on debugging failures whose root cause lives in undocumented business logic rather than in the code itself. Planning an AI rollout around a single productivity number, instead of around task type, is where most of the client rollouts we have reviewed go wrong.

3. The Quality and Security Tradeoff

Veracode’s 2026 GenAI Code Security Report tested more than 100 models across four snapshots and found the average security pass rate sitting at 56%, essentially unchanged from 55% in the first report. Roughly 44% of code generation tasks introduced a vulnerability, spanning common weakness classes such as SQL injection, cross-site scripting, and log injection.²

The earlier 2025 report found Java to be the riskiest language tested, at a 72% security failure rate, and found models failed to defend against cross-site scripting in 86% of relevant samples.⁶ For enterprise Java shops, that stratification is not a footnote.

The structural problem is that syntax correctness and security correctness have decoupled. Models produce code that compiles at near-perfect rates while failing security tasks close to half the time. Code that compiles, passes tests, and ships on schedule can still be accumulating security debt silently, because nothing in the normal feedback loop flags it.

The Volume Multiplier

A flat failure rate against a rising volume of generated code produces a rising absolute number of defects. If AI authors half of committed code and the security pass rate has not improved, the total remediation burden grows even when the per-task rate holds steady. This is the mechanism behind DORA’s instability finding: throughput improved, and the downstream consequences improved along with it, in the wrong direction.

Model Selection Is Now an Engineering Decision

Veracode’s 2026 data shows real spread between models, with the leading model in that snapshot passing 68% of security tasks while more than half of tested models clustered between 50% and 53%.² A model failing one in three security tasks generates materially less remediation work than one failing one in two. Standardizing on a model, and revisiting that choice on a schedule, belongs in your engineering standards rather than in individual developer preference.

In practice: this is why Keyhole standardizes on agentic coding tools such as Claude Code and Codex rather than leaving model selection to individual developers. As a member of the Claude Partner Network, we get direct access to Anthropic’s model updates, security guidance, and delivery playbooks, and we apply that guidance consistently across engagements rather than letting tool choice vary project to project.

Keyhole also recommends using LLMs in an adversarial mentality, having it scan recent commits for security vulnerabilities. The same model that generated the code can be used to scan for issues without a conflict of interest. We then recommend that another model take those initial findings and attempt to validate them by building in a test case that takes advantage of the exploit.

This drastically reduces the number of false positives that a development team needs to review, and is the same fundamental concept as what models like Anthropic’s Claude Mythos 5 does (as a model purpose built for autonomous vulnerability discovery and exploit validation).¹²

4. What Changes by Role

The impact is not distributed evenly. Roles closest to well-specified, verifiable output see the largest shift, and roles closest to judgment and system context see the least.

Delivery consideration: these shifts show up directly in how we staff modernization engagements. Junior developers move faster on well-scoped tasks but need senior review built into the workflow from the start, not layered on afterward. Architects spend more time defining boundaries up front, because generated code will faithfully extend whatever pattern already exists in a codebase, whether or not that pattern is one worth extending.

5. Why Enterprise Codebases Constrain the Gains

Most published demonstrations of AI development involve small, modern, greenfield projects. Most enterprise work does not. The difference explains a large share of the gap between expectation and result.

• Context windows do not contain your system. A model can hold a repository’s worth of code in context. It cannot hold twenty years of undocumented business rules, the reason a particular batch job runs at 2 a.m., or which of three overlapping services is the actual source of truth.
• Legacy patterns get replicated, not improved. Generated code follows the conventions it sees. In a codebase carrying significant technical debt, that means AI reproduces the debt faster and more consistently than a human would have.
• Verification cost scales with system complexity. This is the likeliest explanation for the METR result: in mature repositories with high standards, the review and correction burden consumed more time than generation saved. The tasks were real, the developers were experts, and the AI still cost time.
• Integration surface is where the risk lives. Mainframe interfaces, legacy message queues, and custom authentication schemes are precisely the areas with the least public training data and the highest cost of failure.

The practical implication is that modernization and AI enablement are the same project, not sequential ones. An organization running critical workloads on a monolith built before cloud-native architecture existed will not unlock meaningful AI gains by adding tooling on top.

Keyhole’s modernization work, spanning mainframe and microservices modernization, application architecture review, and cloud migration across Java, .NET, and JavaScript stacks, addresses that constraint directly: the architectural clarity that makes a system maintainable is the same clarity that makes it tractable for AI-assisted development. That work is carried out by senior, U.S.-based consultants who have already worked through the undocumented dependencies and inherited patterns that AI tooling cannot see on its own.

How This Plays Out in Modernization Work

The compression described above is not hypothetical. BCG documented an Asian financial institution that used AI to extract more than 5,000 business rules from a large legacy codebase in under three weeks, a 225x acceleration over manual analysis.⁹ Deloitte found that a major U.S. airline spent six years manually reworking just 10% of its legacy platform, then completed comparable scope in roughly 18 months after adopting AI-assisted tooling.¹⁰

Keyhole has seen a similar pattern directly: one platform modernization engagement originally scoped at 18 to 24 months was completed in approximately five months using AI-accelerated, architect-governed delivery.¹¹ In each case, the acceleration came from applying AI inside a structured, reviewed process, not from removing structure to move faster.

6. A Practical Adoption Sequence

For teams past the pilot stage, the sequence matters more than the tool selection.

• Instrument before you adopt. Capture baseline delivery throughput, change failure rate, and time to restore. Without a baseline, you will be evaluating AI on developer sentiment, which the research shows can be confidently wrong.
• Make security scanning non-optional in the pipeline. At a flat 56% security pass rate and rising volume, static analysis on every AI-assisted commit is the minimum viable control, not a maturity milestone.
• Standardize the model and the tooling. Model choice measurably affects downstream remediation load. Keyhole’s delivery teams standardize on agentic tools such as Claude Code and Codex, backed by our participation in the Claude Partner Network, rather than leaving the choice to whatever a given developer happens to have installed. Treat model and tool selection as an engineering standard with a scheduled review, not an individual preference.
• Tighten review, do not loosen it. The instinct to speed up review to match generation speed is exactly backward. Review is now the binding constraint on quality, and it deserves more attention than it did before. This is the same discipline behind make it work, make it right, make it fast: AI has changed how fast code gets written, not the order in which quality gets earned.
• Set explicit boundaries by task class. Developers already do this informally, leaning on AI for documentation and search while keeping it away from deployment and architecture decisions. Making those boundaries explicit turns individual caution into organizational policy.
• Fix the platform underneath. DORA’s core finding is that returns come less from the tools than from internal platform quality, workflow clarity, and team alignment. That work is unglamorous and it is where the actual leverage sits.

Once a team works through this sequence, the budget conversation tends to follow close behind. If that’s the next question on your plate, our breakdown of what AI software development actually costs covers the pricing models and tradeoffs teams run into once they’re past the pilot stage.

7. Frequently Asked Questions

Does AI reduce the number of developers a project needs?

The evidence does not support that as a general conclusion. What it supports is a shift in the composition of the work: less time authoring, more time specifying and verifying. Organizations that have cut headcount on the assumption of a uniform productivity multiplier are betting on a number that the one controlled trial in the literature measured as negative, and that the follow-up research declined to quantify.

Is AI-generated code less secure than human-written code?

On the benchmark evidence, generated code fails security tasks at a high and stubbornly flat rate, and it does so while compiling cleanly, which makes the failures harder to notice. The more useful framing is that AI changes where defects enter and how fast they accumulate, which means detection controls matter more than they did when authoring speed was the limiting factor.

Should we let AI touch our legacy systems?

Carefully, and with the understanding that this is the hardest case rather than the easiest. AI performs well on comprehension tasks in legacy code, such as explaining what an unfamiliar routine does or mapping dependencies, and considerably less well on modification tasks where the undocumented business context lives outside the codebase entirely.

How do we tell if AI is actually helping our team?

Measure delivery outcomes rather than developer sentiment. Throughput alone is misleading, since DORA found throughput and instability rising together. Pair it with change failure rate and time to restore service, and evaluate over quarters rather than sprints.

What if our team is already struggling before adding AI?

Then AI is the wrong next investment. The amplifier finding cuts both ways, and adding generation speed to unclear requirements and weak test coverage produces more defective work per unit of time. Fix the process and the platform first, then adopt.

Does AI change how legacy modernization projects should be scoped?

Yes. Scoping that assumes manual-era timelines for discovery and code transformation tends to overestimate cost and duration for teams applying AI-accelerated delivery inside a governed process. It also tends to underestimate the review and validation effort needed to keep that speed safe. Both adjustments belong in the estimate, not just the first one.

What does architect-governed AI development actually mean in practice?

It means AI handles the repetitive, mechanical work, such as code transformation, test generation, and documentation, while architects and senior engineers retain authority over design decisions, review every output against quality gates, and maintain traceability from requirement to deployed code. The governance is what turns AI’s speed into a durable advantage rather than a source of accumulating risk.

Keyhole Software’s 100% U.S.-based senior consultants, averaging more than 17 years of experience, apply this AI-accelerated, architect-governed model to legacy modernization and custom software development across Java, .NET, COBOL/mainframe, and cloud-native architectures. Long-standing clients such as AMC Theatres, Commerce Bank, Lockton, and Northwell Health reflect the kind of multi-year, enterprise-scale relationships this approach is built on; roughly 78% of Keyhole’s annual work comes from returning clients rather than one-time engagements. The insurance platform work referenced above, is a direct example of the AI-accelerated, architect-governed model in practice.

Planning AI adoption against an enterprise codebase?

Talk with Keyhole Software about modernization and AI enablement

References

¹ DORA. State of AI-assisted Software Development 2025. Google Cloud. dora.dev/dora-report-2025

² Veracode. 2026 GenAI Code Security Report: AI Is Writing More of Your Code but Security Hasn’t Caught Up.

³ Becker, J., Rush, N., Barnes, E., and Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, July 2025. arXiv:2507.09089

⁴ Becker, J., Rush, N., Cunningham, T., Rein, D., and Mahamud, K. We Are Changing Our Developer Productivity Experiment Design. METR, February 2026.

⁵ Stack Overflow. 2025 Developer Survey. 49,000+ respondents across 177 countries.

⁶ Veracode. 2025 GenAI Code Security Report.

⁷ Microsoft. Q4 FY2025 earnings call remarks on GitHub Copilot adoption, reported by TechCrunch and Dataconomy, July 2025.

⁸ Gartner. Enterprise AI Coding Agents: 2026 Market Guide & Trends. gartner.com, 2026.

⁹ Boston Consulting Group. How AI Is Paying Off in the Tech Function. bcg.com, 2025.

¹⁰ Deloitte. Legacy System Modernization. deloitte.com, June 2025.

¹¹ Keyhole Software. AI-Accelerated Insurance Platform Modernization. keyholesoftware.com.

¹² Anthropic. Claude Mythos Preview. anthropic.com, April 2026.

¹³ Stack Exchange Data Explorer, data.stackexchange.com (original data), as reported by DevClass, “Dramatic drop in Stack Overflow questions as devs look elsewhere for help,” January 2026, and Daniel Lockyer’s July 2026 volume analysis.