AI agents write more code — why doesn't the product come out faster

In short: writing faster does not mean releasing faster

An AI programming agent can independently read a repository, change several files, run commands, and prepare a pull request. This is useful when the task is clear. But a software product is not just the sum of lines of code. Changes still need to be understood, tested, aligned with requirements, safely merged, and verified to ensure the user actually received the desired result.

Therefore, the right question is not "how much code did the agent create?", but "how many verified tasks reached the user without new problems?". A new working study by economist Fiona Chen provides rare data on this exact difference.

What the study actually measured

Working version of the study Artificial Intelligence in the Firm: Bottlenecks in Software Production dated August 4, 2026. The author analyzes anonymized data of approximately 300 million work events from 725,938 employees across 718 companies from January 2021 to March 2026. Companies implemented AI assistants and more autonomous agents at different times, allowing for comparisons of changes before and after implementation.

These percentages should not be read as a universal forecast for every team. For assistants, only the increase in commits was statistically significant. For agents, the increase in activity was higher, but estimates for completed Jira tasks and epics remained small and statistically insignificant. The study also found no measurable change in employment during the studied period.

Where the gains are lost: reviews and other "invisible" work

After the appearance of agents, the average pull request review time in the sample increased by 49%. Change requests nearly doubled, comments per pull request increased by 35%, and the share of employees involved in reviews increased by 14%. This does not prove that every AI-generated pull request is bad. But it shows: a larger flow of changes shifted the work from writing code to reviewing it.

The study provides a useful estimate: engineers spend only 30–40% of their time directly writing code. The rest is task definition, design, testing, review, coordination, deployment, and support. If you speed up only one link, the system hits the next one.

For a solo developer, the bottleneck is less noticeable because the author and reviewer are the same person. The risk is even higher: it is easy to accept a large patch that looks convincing without understanding all the changes. Therefore, limiting task size is more important than another "smarter" prompt.

Practical process: from prompt to verified result

1. Start with behavior, not files. Write down what the user should be able to do after the change. "Add a form" is vague. "A visitor submits a name and email, sees a confirmation, and an incorrect address is rejected" is verifiable.
2. Limit the change. One pull request should have one goal. Ask the agent to first show a plan, files, and risks. If the change affects authorization, payments, data migration, or production secrets, leave the decision to a human.
3. Demand proof. Verification commands, tests, or a clear manual scenario must be added to the code. "Everything works" is not proof until the command is executed in your environment.
4. Read the diff before running. Look not only for explicit bugs, but also for unnecessary dependencies, deleted checks, changed permissions, and code that the task did not require. Send irrelevant parts back to the agent to be reduced.
5. Verify in three layers. First static checks and tests, then a real user scenario, and after that—security and recovery. For a web page, add phone, keyboard, network error, and direct URL opening.
6. Merge only what is clear. If you cannot briefly explain why a critical fragment is needed, do not move it to production. Break up the changes or request a competent review.
7. Check the result after release. Open production, repeat the main scenario, and look at real errors. "Merge" is not the finish line; the finish line is confirmed behavior for the user.

For GitHub pull requests, use our separate Copilot Code Review guide. But remember: a second AI reviewer does not replace tests and human responsibility.

A prompt that reduces the review queue

This template intentionally asks for less code. Insert the actual behavior, your project's commands, and access boundaries.

What to measure instead of line counts

A small team doesn't need a complex dashboard. Take the last 10 AI tasks and record four things: time to production, review time, number of reworks, and post-release bugs. Compare identical task types. It's not a scientific experiment, but it's better than the impression of "it feels faster."

Security, constraints, and a 20-minute check

Don't give an agent unnecessary permissions just for convenience. Secrets should stay on the server, production commands should require confirmation, and external texts and issues should be treated as untrusted input. Review before every release: API key protection checklist.

• 0–3 min: reread the task and the definition of done.
• 3–8 min: review the diff; remove unnecessary files, dependencies, and refactoring.
• 8–13 min: run the build, linter, and relevant tests yourself.
• 13–17 min: walk through the happy path and error scenarios as a user.
• 17–20 min: check secrets, permissions, logging, and the rollback plan.

If you are just starting, follow the path «What is Vibe Coding» or try the free service site sample: there you can copy a narrow prompt and test the result without purchasing.