Open to new projects — Angular, TypeScript, Node.js, AI Get in touch →
← Back to blog
6 min read

AI Was Supposed to Save Us Time. So Why Are Developers Drowning?

AI writes code faster than ever, yet developers work more and review more. Why the load moved to review, and how to make AI actually reduce your work.

AI can write a feature in minutes. So why does your week feel longer than it did two years ago?

Most developers I talk to say the same thing. They ship more code than ever. They also review more, context-switch more, and go home more tired. The promise was “less work”. What we got was “different work, and more of it”.

The work didn’t disappear. It moved.

Writing code was never the slow part. Understanding it was. AI made the cheap part cheaper and quietly pushed more volume into the expensive part: reading, reviewing, verifying.

Writing
Reviewing
Same developer, same week. The time didn't vanish — it changed lanes.

The numbers back this up:

  • Faros AI looked at telemetry from over 10,000 developers. Teams with high AI adoption merged 98% more pull requests. Review time on those PRs went up 91%, and PRs got much bigger.
  • METR ran a randomized trial with experienced open-source developers. With AI tools they were 19% slower on real tasks — while believing they were about 20% faster.
  • In the 2025 Stack Overflow survey, 66% of developers named “almost right, but not quite” AI output as their top frustration. More developers distrust AI accuracy than trust it.

“Almost right” is the key phrase. Code that is obviously wrong is cheap to reject. Code that is almost right costs you a full, careful read.

Why review is the new bottleneck

A human writing 300 lines leaves a trail: commits, questions in Slack, a design doc. You can follow their thinking. An AI writing 300 lines leaves only the 300 lines.

So the reviewer has to rebuild the intent from scratch. And there is more of it, every day.

Before AI With AI, used badly
Typical PRSmall, one concernLarge, several concerns
Author's understandingDeepSometimes shallow
Reviewer's jobCheck the approachReverse-engineer the approach
Who feels the loadSpread across the teamSeniors and maintainers

That last row is the painful one. The people who review the most are usually the most experienced. They get buried first.

The real problem: we measure output, not outcome

Lines written, PRs merged, tickets closed. All of these go up with AI. None of them mean the team is doing less work.

The 2024 DORA report saw the same pattern at scale. More AI adoption came with slightly lower delivery throughput and stability. Individual speed went up. The system didn’t get faster.

Key insight: If AI makes writing 2× faster but every change still needs a human to fully understand it, you haven't removed work. You've moved it to the slowest, most expensive person in the loop.

Make AI reduce work, not create it

AI should reduce the load on developers. It can — but only if we point it at the bottleneck, not the part that was already fast.

Small scope
→
AI writes
→
Machines check
→
Human reviews intent

1. Cap the size of every change

Big PRs are where review time explodes. Put a hard limit in CI so nobody — human or AI — can dump 1,500 lines on a teammate.

import { execSync } from "node:child_process";

const MAX_CHANGED_LINES = 400;

const stat = execSync("git diff --shortstat origin/main...HEAD").toString();
const count = (label: string) =>
  Number(stat.match(new RegExp(`(\\d+) ${label}`))?.[1] ?? 0);

const changed = count("insertion") + count("deletion");

if (changed > MAX_CHANGED_LINES) {
  console.error(`PR changes ${changed} lines. Limit is ${MAX_CHANGED_LINES}. Split it.`);
  process.exit(1);
}

AI is great at splitting work. Ask it for three stacked PRs instead of one giant one. It costs the author a minute and saves the reviewer an hour.

2. Make the author explain the change — even if the author is AI

The reviewer’s hardest job is rebuilding intent. So require it up front. A PR without intent, risk and test steps doesn’t get reviewed.

const REQUIRED = ["## Intent", "## Risk", "## How to test"];

function missingSections(body: string): string[] {
  return REQUIRED.filter((section) => !body.includes(section));
}

const body = "## Intent\nAdd retry to payment webhook\n## Risk\nmedium";
console.log(missingSections(body));

That prints ["## How to test"]. Fail the check, and the author fills it in. Let AI draft the brief from the diff — but the human author must read and own it.

3. Let machines review first

Humans should never spend attention on things a tool can catch. Formatting, types, lint rules, test coverage, and a first AI review pass for obvious bugs all run before a person opens the PR.

By the time you look at it, the only question left should be: is this the right change?

4. Protect review time like deep work

Reviewing well needs focus. Twenty notifications a day kill it. Batch reviews into one or two blocks, and treat the review queue as real work — because it is now most of the work.

The takeaway

AI didn’t fail us. We just aimed it at the wrong problem. Writing code was already the easy part.

This week, try one thing: add a PR size limit to your CI. It’s ten minutes of work. It forces smaller changes, cuts review time, and turns AI from a code firehose into a tool that actually gives you your evenings back.

Sources: