AI Has Been Part of Software Development for Two Years Now. Let's Look at What Changed

AI has been with us in software development for about two years now. That’s long enough for it to stop feeling like an experiment and start feeling like part of the everyday toolkit, so I think it’s a good moment to step back and look at what has actually changed. Our impressions and the vendor headlines have had time to settle, there is now a fair amount of research to check them against, and some of the measured results are quite different from what many of us expected.

My short version goes like this. Writing code really has become cheaper, and for many kinds of work it has become faster. The work around the code has stayed about as expensive as it was: deciding what to build, checking that a change is correct, getting it into production safely, and showing that the whole effort paid off. Most of what follows is about that gap and about what I would change because of it.

One study captures the gap better than anything else I’ve read. Faros analyzed telemetry from about 10,000 developers on 1,255 teams. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, and their code review time went up 91%. Faros presents these as associations rather than causal effects, and I read them the same way. Still, I think many engineering leaders will recognize the pattern: work leaves the developer’s hands faster and then waits somewhere else.

Faros: engineering output rises while review time also increases

Faros 2025: differences observed among high-AI-adoption teams. These are associations, not estimates of AI’s isolated causal effect.

For years, implementation capacity was what engineering leaders planned around, and in many organizations it no longer is. A company that buys more coding capacity and leaves the work around the code as it was will, I suspect, mostly end up with a longer line in front of review.

That has changed the questions I ask as well. Adoption rates tell me very little these days. What I really want to know is how many accepted, reliable and useful changes we get into production, and what each one costs once review, testing and rework are counted.

What changed in how code gets written

The first change is the one everybody noticed: writing code got faster. How much faster is where the studies start to disagree.

Three field experiments at Microsoft, Accenture and a Fortune 100 company found about 26% more completed work among developers who had AI assistance. In a controlled GitHub Copilot experiment, a bounded coding task took 55.8% less time, although the confidence interval was wide, roughly 21% to 89%. Then there is METR, which ran a randomized study with experienced developers working on real issues in mature open-source repositories they knew well. Those developers took about 19% longer with AI. Before the study, they had expected it to make them about a quarter faster.

I’ve stopped treating these as competing answers to the same question. They describe different developers doing different work. A well-specified change that’s easy to test gets a lot cheaper with AI. Work that depends on deep knowledge of a repository, or on architectural judgment, may barely get cheaper at all, and the METR result suggests that we developers aren’t very good at telling which kind of task we’re in. That’s also why I’ve grown skeptical of business cases that take a vendor’s headline uplift and multiply it across a whole engineering budget. The real effect depends on the mix of work, the state of the codebase and the delivery system around it, and as far as I can tell the only way to know it for a particular organization is to measure it there.

At real scale the change can be dramatic. Spotify has published the most useful account of this that I know of. By 2026 more than 99% of its engineers were using AI coding tools every week. PR frequency rose 76%, and monthly merged changes went from about 8,100 to about 17,000 in a year. One backend Java migration that used to involve hundreds of teams over weeks or months was driven by a single engineer in a few days, with the final run taking three days. For maintenance and migration work especially, that’s a real change in what things cost.

What changed in review and QA

What I appreciate about Spotify’s write-up is that it covered the side effects too, and that’s the part I keep coming back to. When Spotify looked at its major incidents, it didn’t find AI-authored code to be a material direct contributor. What it did find was that the number of changes was growing faster than its ability to review, test, roll out and observe them, and that PR size and code complexity had started to climb. DORA’s 2025 research sees something similar across many organizations, with AI use going along with higher delivery throughput and lower delivery stability. I don’t read that as a sign that AI-written code is worse. To me it looks like what happens when more change flows through a delivery system than its slowest stage can absorb.

Review is usually where you feel it first, and the numbers can look contradictory at first glance. GitHub measured roughly 15% less code review time in one AI-assisted scenario, and a twelve-month study at Tata 1mg found about 30% less. Faros, as I mentioned, saw review time in high-AI teams go up 91%. I think both are true at once. Each individual review can get quicker while the queue gets longer, simply because PRs are arriving faster than review capacity grows. It’s one reason I pay as much attention to the time between “ready for review” and merge as to how long the coding took.

My own team is a good example of where this leads. We now have roughly twice as many people in QA as developers. I see that ratio as a direct consequence of everything above: as producing changes gets cheaper, checking them becomes the bigger share of the work, and for us it now takes more people than writing the code does.

So when I think about where engineering money should go now, verification comes first for me. Good tests, CI that people trust, staged rollouts, observability and automated rollback have all become productivity investments in their own right. Funding them before pushing for more AI-generated volume makes the early months look slower than the vendor decks promise. I’m comfortable with that, because the alternative tends to show up later as review backlog and incident recovery.

The other thing that changed in review is who, or what, wrote the code. In LinearB’s 2026 data for the top 10% of AI-adopting organizations, about 54% of PRs involved AI coding assistance, while about 4.7% were authored by agents, so assisted work is still far more common than autonomous work. The rule of thumb I’ve settled on is that an agent’s autonomy should go as far as automated verification reaches. Routine changes with deterministic checks, like migrations and dependency updates, can run largely on their own; Spotify’s Fleet Management has produced more than 2.5 million automated maintenance PRs, most of them merged without a human in the loop. Anything touching sensitive permissions, core architecture or important production behavior still gets human review in my book, and the engineer who owned a service before an agent wrote the patch still owns it afterward.

Where the gains seem to go

Over these two years I’ve also gotten into the habit of following a productivity gain through the organization to see where it actually ends up. There are a few places where it tends to leak away.

The first is the step from faster coding to accepted, reliable changes in production. Review queues, flaky CI, thin tests, rework and failed agent runs can eat most of the gain right there. I’d call that step done when lead time drops and change failure rate and rework stay where they were.

The next is the step from faster delivery to capacity the organization can actually use. If the hours saved in coding get spent on extra review, verification and operational work, nothing was really freed. Having engineering and finance look at the same numbers is the most reliable way I know to tell the difference.

And then that capacity has to go somewhere that matters, whether it’s lower cost, avoided spend or a product result that moves. If nobody decides where freed time goes, it quietly gets absorbed, often into shipping backlog items that weren’t very valuable in the first place. I see that as a decision for the leadership team, and I’d rather it didn’t default to whichever team happened to finish early. Spotify mentions that some feature prototypes now take minutes rather than days or weeks, and when building gets that cheap, picking the right problems matters much more than it used to.

From faster coding to delivered capacity to business value

Most of the AI reporting I come across measures that first step and then talks as though the last one had already happened. McKinsey’s 2026 survey shows how wide the gap can be. 80% of respondents report personal productivity gains from AI, 37% connect it to any positive EBIT impact, and about 6% count as high performers, with at least 5% EBIT impact and significant value. The detail I find most telling is what the high performers do differently: nearly three-quarters of them have fundamentally redesigned their workflows, compared with about a quarter of everyone else. Changing how the work gets done seems to matter far more than simply having the tools.

McKinsey: personal AI productivity and business outcomes are distinct measures

McKinsey 2026: distinct enterprise-AI survey measures across business functions, not engineering-only numbers and not a conversion funnel.

What changed in roles and hiring

The headcount story has been quieter than the headlines suggested. In McKinsey’s survey, 32% of respondents had expected AI-related headcount reductions a year earlier, and 14% actually reported them. Now 39% expect reductions over the coming year. So far expectations have run well ahead of what actually happened, which makes me wary of staffing plans that multiply a task-level productivity number by current headcount. Companies still need people who understand their systems, carry production responsibility, sort out ambiguity and check the work.

What does seem to be shifting is how each role spends its time. Engineers are moving from repetitive implementation toward specification, integration, review and directing agents, while staff and principal engineers spend more time on architectural boundaries and shared standards. QA, SRE and security need verification and recovery that keep up with the volume of change, and engineering managers spend less time handing out tickets and more on how work flows between teams. I haven’t seen credible public data on how headcount should move between these roles, so I’d be careful with anyone quoting precise percentages.

In my team the biggest shift has been in the product role. Product functions have moved almost entirely onto developers, and the role is now a hybrid of product manager and developer. When the person who decides what to build can also build it quickly, choosing the problem and defining what done looks like become part of the engineering job. It’s one more reason I hire for judgment as much as for coding speed.

The trend that worries me most is at the start of the career ladder. Stanford data shows employment of software developers aged 22 to 25 down nearly 20% since 2024. Nobody has shown that AI is the main cause, but the risk to the talent pipeline feels real to me, and Gartner warns that cutting junior roles can hollow out the future senior bench. Junior engineers have always learned by debugging, reading systems they didn’t write, writing tests and owning small things in production. If that path disappears, there will be fewer people ready for senior roles a few years from now. I’d much rather rework it, with supervised AI use, careful review of generated changes and real ownership of small production outcomes.

When I interview, I want to see whether someone can produce and verify the right result both with AI and without it. So I try to look at a candidate’s own reasoning about architecture, debugging and security separately from how well they use AI tools within constraints.

What changed in the build-versus-buy math

One McKinsey finding deserves more attention than it gets, I think. 32% of respondents said their organization had decided not to buy at least one software product or feature because coding agents made building it in-house feasible. Cheaper implementation moves some capabilities into “worth considering internally” territory, and that’s a real shift.

The first version is still the cheapest part of owning software, though. Internal tools have to be operated, secured, integrated, maintained and supported for years. When I look at a build proposal, lifecycle cost and how strategic the capability is weigh much more for me than how fast we could get to a demo. Vendors feel this too. If a customer can rebuild a generic feature cheaply, that feature on its own stops being a reason to buy, and things like integration depth, proprietary context, reliability, security and proven results carry more weight. I don’t think enterprise software buying is going away, but the conversation around it has clearly changed.

What changed in costs

Seat prices are still modest. GitHub Copilot Business is $19 per user per month and Enterprise $39. Most of the money, though, has moved to consumption. LinearB found AI and token spend of about $481 per developer per month at the 90th percentile of heavy usage, and pointed out that even this was under 4% of fully loaded developer cost. About 20% of organizations in McKinsey’s survey say AI operating costs already limit how much they use it.

The number I’d bring to a conversation with finance is the fully loaded cost per accepted production change. Roughly, you add up engineering, AI and tokens, platform, security, review and verification, rework and incident remediation, and divide by the number of changes that were actually accepted and deployed. Review effort and rework are the pieces that tend to go missing, and without them it’s easy to report savings in implementation while the cost of getting that work accepted stays out of sight. I’d keep this number next to reliability and product metrics as well, since two changes can cost the same and mean very different things to customers.

How I’d keep an eye on it

The DORA metrics are still where I start: lead time, deployment frequency, change failure rate and recovery time. Around them I’d add a few measures that show what AI is doing inside the workflow: how long work waits for review, how much fresh code gets reworked, the fully loaded cost per accepted change, and whatever business metric the work is supposed to move. If PR counts go up while lead time stays flat, or throughput rises along with repeat fixes, nothing much has been gained.

AI usage and the share of agent-authored PRs are useful to look at as diagnostics. I’d stay away from setting targets on them, since teams tend to hit targets whether or not delivery improves.

I’ve also come to think trust deserves a place on that list. In DORA’s data, 90% of respondents use AI and more than 80% say it makes them more productive, yet about 30% have little or no trust in AI-generated code. Low trust usually means people quietly re-check the output by hand, and that shows up as review load.

If I were starting a rollout today

Knowing what the last two years have shown, here’s roughly how I’d approach a rollout if I were starting one now.

The research recommends 8 to 12 weeks of baseline data first, with comparisons by cohort or team where that’s practical. Without a baseline, business growth, seasonality, team changes and CI improvements all end up being credited to AI.

I’d look hard at the internal platform early on. Agents do better where repositories, build systems, test commands, ownership and context are consistent and easy to find, and fragmented stacks slow down people and agents alike while making agent output harder to validate. DORA links strong internal platforms with better AI outcomes, and Spotify’s ability to scale agents rested in large part on years of earlier work on platform engineering, standardized stacks and Fleet Management. These days I judge a platform investment by whether it helps teams and agents change, test and ship with less coordination.

Specs are the other thing I’d tighten. AI makes effort estimates less dependable, because two tasks that look alike can need very different amounts of supervision and rework. What helps more is a short, clear statement of what has to change, what must stay as it is, and how we’ll know the result is correct. Kept short, it doesn’t turn into another document or approval step, and it cuts the ambiguity that later becomes rework, which only gets worse when an agent can produce several versions of the wrong thing in an afternoon.

I’d feel comfortable widening the rollout once throughput or lead time had improved, change failure and rework had held steady, review was keeping up with incoming volume, and the fully loaded cost per accepted change had come down. If all I could show was more commits or PRs, I wouldn’t consider the economic case made yet.

Where I’ve landed for now

Looking back over these two years, the evidence doesn’t support either extreme view. AI is doing much more than improving autocomplete, and it has not automated software engineering. The cost of producing code is falling fast and throughput is rising, while fully autonomous work remains a small share of the total. The hard part of the job has moved toward choosing problems, designing systems, verifying changes and making product decisions, and from what I can see, the companies getting financial results out of all this are the ones that rebuilt their delivery systems around that shift.

So, two years in, I see this mostly as a leadership question. Team design, platform investment, hiring, delivery controls and AI spend are all worth judging by whether they help a company turn cheaper implementation into reliable business value. Buying more seats is the easy response, and I expect plenty of companies to stop there. My guess is that the teams who rethink how work moves through engineering, and who measure the results honestly, will be the ones we read about in next year’s research. I’d be glad to hear how this looks from where you sit.

Research and further reading

The figures and company cases above reflect research available as of October 16, 2026. This article is an engineering leadership perspective rather than a research paper; the original publications are listed here for readers who want to examine the evidence.