What happens to software delivery when AI writes more code?

AI coding tools are becoming a normal part of software development. Developers are using them to generate implementations, write tests, investigate problems and understand unfamiliar code. I use them myself and there are plenty of development tasks where they can save time.

What I've been wondering about is what happens to the rest of the development process when we start producing code faster.

Writing the code is only one part of delivering software. It still needs to be understood, reviewed, tested, integrated, deployed and supported. If AI makes one part of that process considerably faster, it doesn't necessarily follow that the whole process gets faster with it.

A recent Harvard research paper provides some interesting evidence that this might already be happening.

More code, but not necessarily more software delivered

In Artificial Intelligence in the Firm: Bottlenecks in Software Production, researchers Fiona Chen and James Stratton examined approximately 300 million engineering events across 718 companies between 2021 and March 2026.

They looked at what happened when organisations adopted AI coding assistants and agents, including changes in code activity, pull requests, reviews and completed work.

Their findings for AI coding agents were particularly interesting.

| Measurement | Change following AI agent adoption | |---|---| | Lines of code written | +30% | | Commits | +20% | | Pull requests | +23% | | Time from PR submission to merge | +49% | | Review comments per PR | +35% | | Pull requests requiring changes | Nearly doubled | | Completed issues and epics | No statistically significant increase |

Read the Harvard research paper

There's quite a lot in those figures.

Teams were producing considerably more code, commits and pull requests. At the same time, pull requests were taking longer to get through review, reviewers were leaving more comments and more changes were being requested. Most importantly, the researchers couldn't establish a statistically significant increase in completed issues and epics.

There are some important limitations. This is observational research, so it doesn't prove that AI caused every change they observed. The 49% increase is also the elapsed time between submitting and merging a pull request, rather than 49% more time spent actively reviewing code. The study doesn't tell us that AI-generated code is worse either.

What it does show is that increasing the speed at which code is produced doesn't automatically increase the speed at which software is delivered.

I think that's the more interesting finding.

What's happening in code review?

The figures around code review are the part I keep coming back to.

Why are pull requests taking longer? Why are there more review comments? Why are nearly twice as many pull requests requiring changes?

The research identifies the bottleneck but doesn't give us a definitive answer as to why it's happening.

Some of it could simply be volume. If developers are creating 23% more pull requests and the number of people available to review them hasn't increased at the same rate, work is going to spend longer waiting.

There could also be issues with the generated code itself. An implementation can compile and look perfectly reasonable while missing something about the existing application, its architecture or the original requirement. Reviewers may be picking those things up.

But I wonder whether trust and understanding are part of this as well.

When I review code written by somebody I've worked with for a while, there's already some context. I know how familiar they are with the application and how they tend to approach problems. If they've made an unusual decision, I can ask them about it and they can explain why.

That doesn't mean their code should get an easier review. In fact, perhaps we've sometimes relied too heavily on that familiarity.

AI changes the situation, though. A developer can now submit a substantial change where much of the implementation has been generated for them. The reviewer may not know how much the developer understands the generated code, what alternatives were considered or why the implementation ended up looking the way it does.

I can understand why that might result in more scrutiny.

Trust isn't quite the same as understanding

I think there's an important distinction here that I hadn't really considered when I first looked at the Harvard research.

The problem may not be whether we trust AI.

I can trust a compiler without understanding how every part of the compiler works. I trust plenty of libraries that I haven't read the source code for. Software development already involves layers of abstraction and trust.

The question is what the team responsible for an application needs to understand.

If a developer uses AI to generate an implementation, reads it, changes parts of it, tests it and can explain how it works, I don't have much of a problem with that. The AI has helped the developer produce the code, but the developer still owns the change.

I'm much less comfortable with a situation where an agent produces a change, the tests pass and the pull request is approved without anybody really understanding what has been introduced.

That's where I think the risk changes.

Why I don't think longer reviews are necessarily bad

My first reaction to the Harvard figures wasn't that we need to make code review faster.

It was almost the opposite.

I've spent a considerable part of my career developing and supporting applications that run in production. When something goes wrong, somebody has to work out what's happening. You need to understand the behaviour of the application, follow the code and make a decision about how to fix it.

If teams gradually reach a point where large parts of an application have been generated and nobody has a good understanding of them, I think we've created a problem for ourselves.

Security is another obvious concern. The same applies to testing, performance and integration with other systems. A generated implementation might work perfectly well in isolation but make an assumption that doesn't hold elsewhere in the application.

For now, I think somebody still needs to own and understand a change before it goes into production.

So if developers are spending longer reviewing AI-assisted changes, that isn't automatically wasted time. It might be exactly what they should be doing.

What we don't know from the Harvard research is whether that additional review is finding more genuine problems or whether reviewers are simply being more cautious because they're less confident about the origin of the code. I'd really like to see more research into that distinction.

Are we being harder on AI than we are on each other?

There's an uncomfortable question on the other side of this.

Perhaps we haven't always reviewed human-written code as carefully as we should.

It's easy for code review to become routine, particularly within an established team. You know the developer, they've worked on the application for years, the change looks sensible and the tests pass.

Maybe AI-generated code is forcing us to think more carefully about what code review is actually for.

Should the standard really be different depending on whether a developer wrote the code themselves, generated it with AI or used a mixture of both?

I'm not convinced it should.

What I care about is whether the developer submitting the change understands it, whether the team has confidence in it and whether we can support it once it's running in production.

That also makes me question whether identifying individual lines as "AI-generated" will ultimately be particularly useful. As these tools become more integrated into development environments, the boundary between human-written and generated code is likely to become increasingly difficult to define.

Ownership might be a better thing to concentrate on than authorship.

What are other teams doing?

We're starting to get research into how development behaviour changes when teams introduce AI agents, but the results aren't yet giving us one clear answer.

A 2026 study looking at 669 developers across 103 repositories found that developers working with AI agents increased their documentation and testing activity. It also observed changes in review behaviour, although similar changes appeared in repositories without AI agents, so the researchers couldn't confidently attribute them to AI.

Read the study: Does Working with AI Agents Change How Developers Code, Test, and Review?

Other research has started looking specifically at the difficulty of reviewing AI-generated code and the context reviewers need to decide where to concentrate their attention.

I don't think we have enough evidence yet to say that there's one correct way for teams to adapt. That's probably to be expected. The tools are changing quickly and teams are still working out where they fit.

What I wouldn't do is ignore the change.

If a team starts producing substantially more code and pull requests after introducing AI, I'd want to understand what happens elsewhere in the development process. Are reviews taking longer? Are pull requests getting bigger? Are more changes being requested? Are defects increasing? Are developers spending more time testing? Is work simply waiting somewhere else?

Those questions are more useful than asking how much AI the team is using.

Maybe code review itself needs to change

Perhaps the traditional pull request process isn't going to scale particularly well if AI substantially increases the amount of code teams produce.

That doesn't mean removing human review. It might mean being more deliberate about what humans review.

Automated tests can verify behaviour we already understand. Static analysis can catch certain classes of problems. Security tooling can identify known vulnerabilities. Type systems and compilers already give us confidence about other characteristics of the code.

If those checks become better, developers might eventually spend less time examining routine implementation details and more time reviewing architecture, behaviour, security and the assumptions behind a change.

AI could help with some of that too.

I can imagine reaching a point where an agent doesn't simply produce a pull request. It also explains the decisions it made, shows which requirements the change satisfies, identifies the tests that demonstrate the behaviour and highlights areas where its confidence is lower.

That would give a reviewer much more useful context than a large diff appearing in front of them.

I'd be interested in that direction. I just don't think we're at the point where we can remove human understanding from the process.

The danger of optimising the wrong thing

The Harvard research also makes me question how organisations measure the success of AI development tools.

If you measure lines of code, commits or pull requests, the results look impressive.

The study found increases in all three.

But none of those things are what a software team is actually there to produce.

The team is there to deliver working software that solves a problem.

For me, a more useful measure is how long it takes to get from agreeing a piece of work to having it running successfully in production. I'd also want to know about defects, rework, time waiting for review and whether the resulting software remains understandable and maintainable.

If implementation gets faster but everything simply waits longer for review, we've moved the bottleneck.

If review becomes faster but more problems reach testing, we've moved it again.

If we automate testing and then production incidents increase, we still haven't improved the development process.

The whole lifecycle matters.

Where does that leave software teams?

I don't think the Harvard research gives us an argument against using AI coding tools.

I've seen enough value from them myself that I wouldn't want to go back to developing without them.

But I also don't think we should look at faster code generation and assume we've made software development faster.

The interesting part of the Harvard findings is what happened around the code.

Developers produced around 30% more code, 20% more commits and 23% more pull requests. Review cycles became longer, reviewers left more comments and considerably more pull requests required changes. The researchers didn't find a statistically significant increase in completed issues and epics.

We don't yet know exactly why all of those things are happening.

It could be the volume of new code. It could be problems with generated implementations. It could be reviewers being more cautious. It could be a lack of context. It could simply be that the rest of the software development lifecycle hasn't yet adapted to the speed at which AI can now produce code.

It's probably a combination of several of them.

For now, my view is that teams should resist the temptation to remove the scrutiny simply because it appears to be slowing things down. If I'm responsible for software running in production, I still want somebody to understand what we're putting there.

Over time, better testing, tooling and AI itself may give us enough confidence to change how that assurance works. I'd welcome that. There's no particular virtue in manually reviewing code if we can demonstrate its correctness and maintainability in better ways.

But we're still learning what those ways are.

What the research does make clear is that we need to look beyond how quickly developers can write code.

If AI makes coding faster, but the software development lifecycle doesn't get faster with it, that's the problem teams need to understand.