Agency Reviews 4 910 Project Estimates: Authorization Now Budgeted at 2.2x Fewer Hours

When CEOs say AI writes 20%, 30% or even 90% of code, the customer is left with one question: how much does an app cost now? Sergey Nikonenko, head of a mobile and web development agency, decided to answer it in hours and rubles. He used internal data: project estimates, time logged in Jira and GitLab commits. He did not factor in percentages of generated code.

What the estimates showed

The archive holds 4 910 estimates, but few were suitable for comparison: the documents need an identical structure. Authorization could be matched in 12 estimates from 2025 and 19 from 2026. The median budgeted hours fell from 124 to 56, a 2.2x drop. The spread also narrowed: the middle 50% of estimates used to run 64–178 hours and now run 24–70.

The hourly rate changed more modestly. Across seven estimates from each year, the median development rate fell from 3 900 to 3 600 ₽, about 8%. The author does not multiply the two medians to get a feature price. The hours and rates come from different samples, and such a calculation requires pairs taken from the same estimates.

In practice, this means it is time to revisit familiar tasks in estimate templates. But the minimum of 12 hours for authorization cannot go into a template: under the same epic name, different products hide different implementations.

Jira and GitLab: where the numbers get trickier

The actual outcomes are harder to read. Landing within the estimate says little on its own. A mobile app with an admin panel came in at 100% of budget (1 359 of 1 360 hours). A personal-development product planned with AI in mind reached 101% (520 of 515), although the project is still running. But it was already estimated with agents in the picture: the expected savings may have been subtracted in advance, so 101% does not show whether AI helped or not. A project with scope growth hit 182%, but it has 23 re-estimates, and the original budget is the right baseline for comparison.

Another accounting problem: for the expedition service, Jira showed 311 hours, while roughly 120 hours of work never made it into the tracker. The author added them as an estimate. Without this correction, the savings would have looked better, but the calculation would have been worse.

GitLab is used to see agent involvement through the Co-Authored-By: Claude trailer in the commit message. On the cosmetics website, 92% of 802 commits are marked as AI co-authored, and a single developer made them over 37 working days. The mobile app is more telling: there are no marks before June 2026, and by autumn they appear in almost every commit. Still, the trailer only reflects declared co-authorship. It does not reveal how many lines the AI wrote or how many hours it saved. And if a developer used AI but did not add the mark, that work stays off the record. So projects without trailers cannot be called AI-free development.

Final coefficients and their limits

The main result works like this: budget divided by actual hours. For the cosmetics website, that gives about 2.5x (594 budgeted hours against 240 actual). But 594 is 80% of the original 742 hours, and the 80% completion figure came from the project owner. There is no independent check against closed tasks. For the expedition service, 1 627 budgeted hours against roughly 431 actual give about 3.8x. In the conclusion, the author cautiously rounded this down to 3x. That is his choice, not a statistical bound.

He lists the limitations himself:

• Projects were not randomly assigned to work with or without agents.
• There are only two AI-first cases comparable with the old budgets. Both are web projects, built on Next.js and Nest.js.
• Project managers are excluded, so these are development hours, not full cost.
• Calendar delivery times were not compared.

There is also a counterargument. In METR's randomized experiment, experienced developers using AI tools on familiar open-source tasks worked 19% slower. The author does not claim to have refuted that study. His comparison is of a different type, and his data does not explain why the results diverge.

What to do with this

For teams that build estimates, the takeaway is down-to-earth. First: revisit hour norms for standard tasks like authorization, and don't carry old figures into new projects automatically. Second: don't promise clients that everything will get several times cheaper, because the hourly rate moves much more slowly. Third: set up proper time tracking. If part of the work doesn't reach the tracker, any speedup coefficient will be inflated. Fourth: don't take the share of commits marked as AI-assisted for a measure of productivity. It is only a trace in the repository history.

The study itself is honest, because it openly shows its weak points. For the industry, it is useful as an example of how to test claims of "several-fold speedup" against your own data, and not pass off a comparison with estimates as a controlled experiment.