The AI Productivity Paradox: More Starts, Fewer Finishes

AI didn’t give developers more free time. It gave us more starts.

I’m a senior full-stack engineer and I use coding agents every day. Our capacity to implement ideas has grown much faster than our capacity to think them through. The numbers show it too. In Faros AI’s telemetry from more than 10,000 developers, high-AI teams merged 98% more pull requests, but PR review time rose 91% and delivery at the company level didn’t improve (Faros AI).

I think that’s the real shift, and it’s a management problem, not a tooling one.

TL;DR

• Cheap implementation removed the old filter. When a feature took a month, the cost made you choose. Now a prototype takes an afternoon, so nothing makes you choose.
• The data backs this up. In Faros AI’s telemetry, developers on high-AI teams touched 47% more pull requests a day, and PR review time rose 91% (Faros AI). A Berkeley study found that AI intensified work instead of reducing it (HBR).
• Better tools won’t fix it. Google’s DORA research found friction and burnout “unaffected by AI” (Jellyfish on DORA 2025). A tool can’t decide what’s worth doing.
• Three rules I’d protect: one thing in progress per product, a written “done” before any code, and a weekly review of what to kill.

Why does AI make developers busier instead of freer?

Before coding agents, the cost of building did your prioritisation for you. If a feature took three weeks, you argued about it first. You wrote it down, cut scope and said no to the other four ideas, because you could see what they would cost. Most bad ideas died in that conversation, before anyone wrote code.

That filter is gone. Starting something now costs a prompt and a coffee. Finishing it costs what it always did: review, tests, edge cases, deployment, docs, support and, above all, the decisions. Every thing you start keeps a claim on your attention. It might be an open branch, a prototype that half works, or an agent waiting for an answer.

In practice it looks like this. You have three agent sessions open. None of them needs you all the time, but each one periodically needs a decision, a review or an answer. Every one of those is a context switch. A new model ships, the ideas come faster, you start more, and a few weeks later the review queue and the switching catch up with you.

Simon Willison described this pattern in February. He often runs two or three projects in parallel and gets a lot done, but his mental energy is mostly gone after an hour or two (Simon Willison). That isn’t a complaint about the tools. It’s what happens when the number of open loops goes up and the person holding them stays the same.

What the research says about AI and workload

The work got more intense, not smaller. Aruna Ranganathan and Xingqi Maggie Ye of Berkeley Haas spent April to December 2025 studying about 200 employees at a US tech company where AI use was optional (HBR). People took on a wider range of tasks, and work spilled into more hours of the day. Engineers spent more time reviewing and cleaning up colleagues’ AI-generated output (The Star, via Inc.). The authors describe “a growing number of open tasks” and “a sense of always juggling, even as the work felt productive” (Simon Willison, quoting HBR).

People produced more, but companies didn’t deliver more. Faros AI analysed telemetry from more than 10,000 developers across 1,255 teams (Faros AI). Here is what changed on teams with high AI adoption:

Faros’s conclusion: “no significant correlation between AI adoption and improvements at the company level” (Faros AI). Read the table as one story. People started more, touched more and opened bigger changes. Then all of it queued up for the same few reviewers.

This was visible before agents. In 2024, 77% of employees who use AI told the Upwork Research Institute the tools had added to their workload, and 39% pointed to time spent reviewing or moderating AI content (Upwork). In Atlassian’s 2025 survey of 3,500 developers and managers, 68% said AI saved them more than 10 hours a week, while 50% lost 10 or more hours a week, mostly to organisational inefficiency (Atlassian). Saving time on typing doesn’t help if the system around you can’t take in what you produce.

Switching costs aren’t new either. Gerald Weinberg’s rule of thumb, as Johanna Rothman summarised it: a person on two tasks spends about 40% of their time on each and wastes 20%, and a person on four tasks spends 10% on each and wastes 60% (Rothman). Weinberg meant those as estimates, not measurements. A 2017 study in an educational setting measured a smaller but real cost: developers on two or more projects spent about 17% of their effort on cross-project interruptions (Tregubov et al., via Never Work in Theory). Gloria Mark’s lab found that interrupted people work faster to compensate, but report more stress, frustration and time pressure (Mark et al., CHI 2008). That describes running five agents at once pretty well.

The case that this is fine

I want to be fair to the other side. The 2025 DORA findings are more positive than the anecdotes. Individual effectiveness rose the most with AI adoption, throughput and time on valuable work improved, and burnout didn’t get worse on average (Jellyfish on DORA 2025). I’ll add my own experience: the work is more fun without the boilerplate.

I agree with all of that, and it supports my point. DORA’s headline is that AI is “an amplifier,” magnifying an organisation’s existing strengths and weaknesses (DORA 2025). If you already had a filter, AI makes you faster at the things that pass it. If cost was your only filter, AI took it away and gave you nothing in its place.

DORA’s own follow-up says this plainly. Two of its seven AI capabilities are working in small batches and keeping a user-centric focus. As DORA puts it, “Speed is irrelevant if you are moving in the wrong direction” (Google Cloud).

It’s a management problem, not a tooling one

The common response to “I’m drowning in agent output” is more tooling: an orchestrator, a dashboard of sessions, an agent that manages your agents. Every one of those makes starting even cheaper, so you end up with more starts.

What’s scarce is attention and judgement, so manage them the way teams have always managed scarce capacity: limit work in progress. The Kanban Guide’s rule is that you “must explicitly control the number of work items in a workflow from started to finished” (Kanban Guide). Basecamp’s Shape Up makes the same point about scope: “Estimates start with a design and end with a number. Appetites start with a number and end with a design” (Shape Up, ch. 3).

Here’s how I think about it. For years, the cost of building did three jobs we never had to do on purpose. Now each one needs a rule.

Rule 1: One thing in progress per product

“In progress” means it has a branch, an agent session waiting on you, or a PR that isn’t merged. Each product gets one of those at a time. It’s one per product, not one per person, because most of us (me included) work across several codebases. The point is that every product has a single lane.

Agents can still run in parallel inside that lane. One writes tests, one drafts the migration and one updates the docs, all for the same feature. What the rule stops is five agents building five different features that all land on your review queue on Thursday.

New ideas go on a list, not into a branch. A list costs nothing to keep. A branch costs attention every time you see it.

There are two exceptions. A production incident overrides everything. A spike (a short experiment to answer a question) is allowed, but it gets a time box, a label, and by default it’s thrown away when the time runs out.

Rule 2: A written “done” before any code

Two lines is enough. If you can’t write them, you don’t understand the work yet, and an agent will happily build the wrong thing very fast. This is the thinking that the cost of building used to force on you. Now you have to do it on purpose.

I keep a short file at the root of the branch:

# DONE.md: checkout-retry
Done when: a failed card payment retries once after 24 hours and the
           customer gets exactly one email, not three.
Not doing: dunning sequences, SMS, admin UI changes.
Appetite: 2 days. Not merged by Friday = cut scope or kill it. No extensions.

“Not doing” is the line that matters most. It keeps the agent from gold-plating, and it keeps me from “while I’m in here” detours. The “Done when” line goes straight into the agent prompt, which is the same habit I covered in Use AI Coding Agents Like a Pro. The appetite line comes from Shape Up: you decide how much the work is worth before you see the design.

Do the thinking away from the LLM. Write the done on paper or in a plain file before you open the agent. Once a chat session is open, it pulls you toward starting.

Rule 3: A weekly look at what you started and should kill

Every Friday I spend 20 minutes listing everything open: branches, draft PRs, prototypes, agent threads, and anything I called a “quick experiment”. Each item gets one of three verdicts:

1. Finish it next week. It moves to the single in-progress slot, or waits for it.
2. Park it. Write one paragraph on what you learned, then delete the branch. The paragraph is what you were actually keeping anyway.
3. Kill it. This is the default.

The default comes from Shape Up’s “circuit breaker”: “If they don’t finish, by default the project doesn’t get an extension” (Shape Up, ch. 8). Basecamp’s reasoning is that one runaway project should never freeze newer projects that could matter more. With AI that matters even more, because restarting is cheap. A killed idea that turns out to be good costs you an afternoon to rebuild, and it’ll be better the second time because you’ll write the done first.

To get the list, I run this in each repo:

# Local branches with no commits in the last 7 days, oldest first
git for-each-ref --sort=committerdate refs/heads/ \
  --format='%(committerdate:short) %(refname:short)' |
  awk -v cutoff="$(date -v-7d +%F 2>/dev/null || date -d '7 days ago' +%F)" '$1 < cutoff'

# Your open pull requests (GitHub CLI)
gh pr list --author "@me" --state open

The date fallback covers both macOS and Linux. Anything that shows up two Fridays in a row doesn’t get a third.

From the field

[PAPAN: add a real project example. Client type, the moment AI made it easy to start too many things at once, which of the three rules you applied, and what changed: features shipped, review backlog, or how the week felt.]

Before you start the next thing

Ask yourself these before you open a new branch or agent session:

• Is something already in progress on this product? Finish it or kill it first.
• Can I write “done when” in two lines, with a “not doing” line?
• What’s the appetite, and what happens when it runs out?
• Who reviews this, and do they have room this week?
• If this took a month instead of an afternoon, would I still build it?

The last question is my favourite. It puts back the filter that cost used to provide, without the cost.

The short version

AI made implementation cheap and left judgement as expensive as ever. If you don’t decide what not to build, you end up with a pile of half-finished work and a tired team. Shipping fast still matters, but speed without a filter just turns into a longer to-do list.

If you’re a founder planning an MVP and you want speed that turns into shipped features, this is how I run my projects: one lane per product, a written done for every feature, and a weekly cut. I build React/Next.js and Node.js products for clients in Texas, Singapore, Lisbon and Delhi. Get in touch. If you’re a developer, the agent-side habits are in Use AI Coding Agents Like a Pro, and my two-agent review loop is in Claude Code vs Codex: How I Use Both on One Repo.

Sources

1. Faros AI: The AI Productivity Paradox Research Report
2. Harvard Business Review: AI Doesn’t Reduce Work—It Intensifies It
3. Simon Willison: AI intensifies work
4. The Star (Inc./TNS): AI promised to save time. Researchers find it’s doing the opposite
5. Upwork: Employee workloads rising despite C-suite investment in AI
6. Atlassian: State of Developer Experience 2025
7. DORA: 2025 State of AI-assisted Software Development
8. Jellyfish: AI as Amplifier, the 2025 DORA Report with Nathen Harvey
9. Google Cloud: Putting the DORA AI Capabilities Model to work
10. The Kanban Guide
11. Shape Up, Chapter 3: Set Boundaries
12. Shape Up, Chapter 8: The Betting Table
13. Johanna Rothman: Multiprojecting, the Illusion of Progress
14. Never Work in Theory: Impact of Task Switching and Work Interruptions
15. Mark, Gudith and Klocke: The Cost of Interrupted Work, CHI 2008