How AI can increase engineering velocity

Every engineering leader has been told, at least once this quarter, that AI will make their team ten times faster. Usually by someone selling AI. Sometimes by a board member who just discovered ChatGPT on a plane.

So let’s talk about what actually happens when you give a team of developers an AI assistant, and where the speed really comes from. Spoiler: it’s not where the slide deck says.

The easy part: writing code got faster

AI is genuinely good at producing code. Boilerplate, tests, migrations, that regex nobody wants to own. Developers who lean into it can ship a first draft in a fraction of the time it used to take.

This is the part everyone celebrates. Lines of code go up. Pull requests multiply. Someone puts a chart in Slack with an arrow pointing to the sky.

And then, mysteriously, nothing ships any faster.

The hard part: everything after the code

Writing code was never really the bottleneck. It was just the most visible part.

The real time goes into everything around it:

• Understanding the problem. What are we actually building, and why?
• Understanding the system. What will this touch, and what will it quietly break?
• Reviewing the change. Is this correct, safe, and consistent with what we already decided?
• Remembering why. Why is this service like that? Who said we couldn’t write to that database? Was it a decision, or just Steve?

AI made the code part faster. It did not make any of these faster. In some cases it made them slower, because now there is more code to understand, more pull requests to review, and more confident-sounding output to double check.

Congratulations, you have automated the creation of reading material.

Where AI actually increases velocity

If the bottleneck is understanding, then the real gains come from using AI to help humans understand faster, not just type faster.

1. Faster context, not just faster code

The slowest part of most tasks is getting up to speed. A good AI setup can pull together what’s relevant: the components involved, past decisions, known constraints, the incident from last March that nobody wants to repeat. That turns an hour of archaeology into a few minutes of reading.

2. Reviews that start with the why

Most pull request descriptions are some variation of “fix bug” or “updates”. The reviewer then reverse engineers the intent from the diff, which is a bit like reading a novel backwards to work out the plot.

AI can fill that gap: summarise what changed, explain why it matters, flag what it touches, and point out where it conflicts with something the team already decided. The reviewer starts with context instead of a puzzle.

3. Showing less, not more

Here’s a controversial idea: the most useful thing AI can do in a review is hide stuff. Lockfiles, formatting changes, renamed variables, a file moved from one folder to another. None of it needs a human’s full attention. Let AI set the noise aside (visibly, so nothing sneaks past) and let the reviewer focus on the changes that actually carry risk.

 4. Capturing knowledge as a side effect

Every team says they’ll write better docs. Every team means it. Every team doesn’t.

Instead of asking people to write documentation, AI can capture knowledge from the work they’re already doing: pull requests, review discussions, Slack threads, incidents. Ask a quick question at the right moment (“Is this service still being phased out?”) and the answer becomes knowledge that helps the next person. No wiki gardening required.

5. Keeping humans in charge

The fastest way to slow a team down is to ship something nobody understood. AI auto-approving pull requests sounds efficient right up until the first 2am incident.

Velocity that lasts comes from humans making good decisions quickly, with AI doing the legwork. Not from removing the humans and hoping for the best.

Measuring the right thing

If you want to know whether AI is actually helping, stop counting lines of code and pull requests. Those numbers will go up regardless, and they mostly measure how much reading you’ve created for someone else.

Instead, look at:

• How long it takes a reviewer to understand a change
• How long a pull request waits before it’s reviewed and merged
• How often the same questions get asked twice
• How quickly a new team member can contribute without asking “why is it like this?”

If those are improving, AI is increasing your velocity. If they aren’t, you’ve just bought a very expensive way to produce more code to read.

The short version

AI can absolutely make engineering teams faster. Just not by writing more code. The real gains come from helping humans understand changes faster, review with context, and stop losing the knowledge that explains why things are the way they are.

That’s the problem we’re working on at Prodigent: AI-guided, human-led code review, powered by your team’s own knowledge. Your team never writes docs, and Prodigent still knows why.

Start free