Blog / English
10x with AI—or only 2x? How to measure productivity without counting lines and PRs
Your team is producing more code. That does not prove it is delivering more value.
With AI, lines, commits, and pull requests became cheap. A team can double all three while increasing its review queue, rework, and the number of decisions nobody can explain.
The question is not how much AI accelerated typing. It is how long the company takes to turn a need into an accepted, sustainable outcome.
The feeling of speed is misleading
In a controlled study published by METR in 2025, 16 experienced developers completed 246 real tasks in projects they knew well. They believed AI had made them faster, but in that specific setting the AI-enabled group took 19% longer. METR explicitly warns against generalizing the result to every team and tool.
That contrast reveals something more useful than another “AI works” versus “AI does not work” debate: individual perception does not measure the delivery system.
DORA's 2025 report reached a compatible conclusion: AI acts as an amplifier of an organization's existing strengths and weaknesses. A clear workflow tends to move faster. A confused workflow produces more confusion.
Metrics AI can inflate
These measures can show activity, but they are weak evidence of productivity:
- lines of code generated;
- suggestions accepted;
- commits per developer;
- number of PRs;
- tasks marked complete;
- tokens consumed;
- time to first draft.
Every one can grow without a user receiving value. Rewarding them can also encourage larger changes, unnecessary code, and artificial task splitting.
Activity is cost. Accepted outcomes are value.
A scorecard for what survives
Use a small set of metrics tied to the entire cycle:
| Question | Metric | What it reveals |
|---|---|---|
| Did it reach users? | time from need to production | actual system speed |
| Was it accepted? | changes accepted without structural rework | first-delivery quality |
| Did it stay correct? | rework during the next 30 days | hidden cost after merge |
| Was it safe to operate? | rollbacks, incidents, escaped defects | delivery stability |
| Did it consume attention? | human review and correction time | cost shifted to specialists |
| Did it respect the design? | architecture violations per change | conformance to system boundaries |
| Did it survive? | code retained after 30 and 90 days | usefulness of the output |
| Was it worth the cost? | total cost per accepted outcome | return on tools, tokens, and labor |
Do not choose a single metric. Speed without stability rewards shortcuts. Stability without flow can hide paralysis. Cost without outcomes rewards the cheapest option even when it delivers less.
Measure by type of work
AI does not create the same gain across every task. Separate at least four groups:
- Exploration: prototypes, spikes, and learning.
- Known implementation: boilerplate, predictable tests, and repeated patterns.
- Product change: business rules, integrations, and user experience.
- High-risk change: security, data, migration, and critical infrastructure.
An agent may excel in the second group and require deeper review in the fourth. A single average hides that difference and drives poor investment decisions.
The 30-day experiment
Choose two comparable workflows and establish a baseline. In one, use AI with the current process. In the other, give the coding AI a specification, architecture decisions, and verification criteria before implementation begins.
For 30 days, track:
- time to production;
- minutes of human review;
- reopened changes;
- defects and rollbacks;
- AI cost;
- architecture violations;
- percentage of code retained without rework.
Then calculate:
cost per accepted outcome = tools + AI consumption + implementation time + review + rework
The number does not need to be perfect. It needs to be comparable. It shows whether speed was created or merely transferred to review and maintenance.
Where ArchGenerator.com changes the equation
The team keeps coding with the AI it already uses. ArchGenerator.com organizes the work that is usually repeated, lost, or assumed: discovery, architecture, specification, and governance.
SPEC keeps intent, rules, and acceptance criteria in a company-controlled space. Architecture decisions make boundaries explicit. Reports observe the code through evidence. The SDD Kit gives the coding AI a context package prepared for execution.
That reduces the need to retell the system in every new session, model, or tool. It also creates a reference for measuring conformance: the team can compare what was defined, what was built, and which sensors actually approved the change.
The biggest saving is not generating the next line faster. It is avoiding the cost of rediscovering, reviewing, and correcting the same intent.
The scorecard leaders should see
At the next productivity review, replace “how many lines did AI generate?” with five questions:
- Did time to production fall?
- Did 30-day rework fall?
- Did human attention per accepted change fall?
- Were stability and architecture conformance preserved?
- Did total cost per accepted outcome improve?
If the gain appears only in generation speed, it has not been proven yet.
Try ArchGenerator.com in a real workflow. Keep your coding AI and give it specifications, decisions, and boundaries owned by your company. When intent and evidence travel with the code, productivity stops being a feeling and becomes a verifiable outcome.