1.5x as the realistic first-year target: measuring AI productivity beyond lines of code

Key numbers at a glance

• 1.5x acceleration in 90 days is the realistic first-year target — not the 10x from the vendor pitch.
• +55 percent faster on scoped tasks (GitHub Copilot RCT), but −19 percent slower for experienced devs in complex codebases (METR 2025). Both numbers are true, depending on setup.
• 40 percentage points perception gap: devs believe +20 percent, are actually −19 percent. Measuring on gut feel is measuring self-deception.
• +28 percent ticket velocity at SHD Düsseldorf after 90 days, measured per size class — not per story point.
• 53 percent of adopters fail on missing capability (Bitkom 2026), not on technology. KPIs without a capability layer remain cosmetic.
• 80 percent of companies see zero measurable productivity gain from AI (PwC 2026). Mostly because they measure the wrong thing.

TL;DR

• Hook: The market tells two stories about AI productivity — +55 percent (GitHub) and −19 percent (METR). Both are true. Which one lands at your shop depends on your setup, and you need your own measurement.
• Stakes: 80 percent of companies see no measurable gain (PwC 2026), mostly because they measure LoC, story points, or "feels faster" — i.e. exactly the 40-pp METR perception gap.
• Action: Four KPIs as the must-have axis, DORA as cross-validation, baseline set up in one day. 1.5x in 90 days is honest; anything above that comes in wave two.

---

The market is telling two stories about AI productivity right now, and both are true.

Story one: GitHub measured in a randomised controlled experiment that devs with Copilot complete a defined task in 1 hour 11 minutes versus 2 hours 41 minutes without. That is 55 percent faster. Same story at Accenture, one of the largest Copilot studies ever: +8.69 percent pull requests per developer, +11 percent merge rate, +84 percent successful builds.

Story two: METR measured in a 2025 RCT that experienced open-source developers with AI tools in complex codebases are 19 percent slower. The kicker: those same developers believed they were 20 percent faster. A 40-pp perception gap. As a reminder, these are not beginners — these are maintainers of repos with over 22,000 stars and millions of lines of code.

Both stories are true because outcome depends on setup: task type, codebase complexity, developer experience, tool integration, context support. Pick one and ignore the other and you're not doing KPI work — you're doing vendor pitch or sceptic pitch.

Across multiple DACH engagements over the past 18 months we measured what really lands. From that practice came a KPI framework we apply at Sentient Dynamics in every 90-day program. It gives you your own truth for your own stack, your own devs, and your own tickets — not external headlines.

Why lines of code, accepted suggestions and story points all fail

Before we get to the framework, a quick tour of why the obvious metrics are useless.

Lines of code (LoC): AI tools tend to inflate code on average. More LoC does not mean more business value — it often means more maintenance load. A GitHub-internal analysis shows AI-generated code is refactored 41 percent more often than hand-written. Measuring LoC actively encourages this pattern.

Accepted suggestions: Popular in vendor reporting, but empty. An "accepted" says nothing about correctness, security, test coverage or maintainability. Devs often accept suggestions just to manually correct them seconds later. The metric stays unimpressed.

Story points: Hangs on human estimation, which drifts with every tooling change. After a short period devs unconsciously estimate AI-assisted tickets smaller, which inflates velocity but only as a statistical artefact, not real output growth.

Commits per day: Reinforces micro-commit behaviour that gets squashed away anyway. Also an anti-signal for code-review discipline.

Subjective surveys ("do you feel more productive?"): Exactly the perception gap METR measured. 40 percentage points of self-deception. Survey KPIs should run alongside, never as the primary metric.

If LoC, accepted suggestions, story points, and surveys all fail, what's left?

The Sentient KPI framework: four KPIs, one axis

We measure four KPIs in every 90-day program. Together they give a complete picture. They correlate, but they don't substitute for each other.

KPI 1: Adoption rate

Definition: Share of licensed devs who complete at least 5 productive sessions with the AI tool in a 30-day rolling window. Productive means: tool used in the context of a real ticket, not for play.

Baseline: From the tool logs (Copilot, Cursor, Claude Code, Codex). When logs are not granular enough, we add wrapper metrics on the AI knowledge platform.

Realistic first-year target: From a typical 10 percent to 70+ percent. At SHD Düsseldorf we hit 72 percent after 90 days.

Why it matters: Without adoption, every other KPI is licence waste. If the tool doesn't land, the best setup doesn't help.

KPI 2: Productivity gain as cycle time per size class

Definition: We take 12 to 18 months of ticket history from the backlog and classify tickets by size class (small, medium, large) based on code-diff volume, number of files touched, and complexity markers. Then we measure median cycle time per size class before and after the program.

Why the detour through size classes: The sheer number of tickets per sprint says nothing. What counts is how fast a ticket of a given size class moves through. This eliminates story-point bias and the temptation to estimate tickets unconsciously smaller.

Realistic first-year target: 1.5x cycle time, i.e. roughly halving time-to-done with a generous safety margin. McKinsey 2026 measures 16 to 30 percent productivity gain at the top 20 percent. Set 1.5x as an entry target and you are conservatively in that band after 12 months.

Anchor against the METR perception gap: This KPI is objective and auditable. Nobody has to ask their gut.

KPI 3: Ability-and-willingness score per developer

Definition: Two sub-scores, each 0 to 100.

• Ability: Tool mastery measured by success rate on structured hands-on tasks (test generation, bug reproduction, refactoring), updated weekly.
• Willingness: Self- and peer-perceived readiness to adopt AI workflows, plus actual adoption behaviour from tool logs.

Quadrants: High ability, high willingness are the champions. Low ability, high willingness are the adopters (with coaching needs). High ability, low willingness are the sceptics (often the most senior devs — argued positions, take seriously). Low ability, low willingness are the risk candidates.

Why it matters: The workforce is not homogeneous. Blanket trainings fail because they treat everyone the same. With a per-developer score we steer coaching, pair-programming pairings, multiplier selection, and honest career conversations.

Data basis for HR: Personnel decisions stay 100 percent with the company. We deliver the numbers, not the verdict.

KPI 4: Workforce segmentation

Definition: Consolidation of the three previous KPIs into three segments, plus extra data points from code reviews, per-person velocity gain, and tool logs.

• High performers: Top 20 percent of adoption and velocity gains, high ability, high willingness. These are your multipliers.
• Adopters: Solid adoption, mid-range velocity, well-steerable with hands-on coaching. The majority — typically 50 to 60 percent of the team.
• Non-adopters: Low adoption even after 90 days, low velocity change. 15 to 25 percent typical, depending on industry and seniority mix.

Why it matters: This is the question every board asks in 2026, and the question every executive asks in steering meetings: "who in our team is taking the trend with them, and who isn't?". Gut feel doesn't cut it any more. Workforce decisions need an auditable data basis.

Anchor against market reality: Stack Overflow Developer Survey 2025 shows 38 percent of devs explicitly have no plans to adopt AI agents. Those 38 percent will not move into the adoption quadrant on their own. They become non-adopters if no one takes them along structurally.

DORA as cross-validation

The four KPIs above are our must-have axis. As cross-validation we look at DORA metrics in parallel:

• Lead time for changes: should drop if AI is helping.
• Deployment frequency: should stay flat or rise slightly.
• Change failure rate: must stay flat or drop. If cycle time falls but change failure rate rises, you don't have acceleration — you have error displacement.
• MTTR: should stay flat.

If all four DORA metrics are neutral or positive while cycle time per size class drops, the acceleration is real. If DORA tips, the acceleration was an artefact.

ROI calculator: what would 1.5x be worth to your team? →

How we set up a baseline in one day

The honest answer: without a baseline, every AI-acceleration story is unverifiable. We set up the baseline in one day with this sequence:

Hour 1–2: Ticket export from Jira or Linear for the last 12–18 months. Filter to closed tickets. Anonymise descriptions if required.

Hour 3–4: Size-class definition. We cluster tickets by code-diff volume, number of files affected, and complexity markers. Three classes are usually enough (small, medium, large). Validation with two or three senior devs from the team.

Hour 5–6: Cycle-time analysis per size class — median and percentiles (P50, P75, P90). That is your baseline.

Hour 7–8: Tool-log export from Copilot, Cursor, Claude Code (if already in use). Plus the adoption-threshold definition for the adoption rate KPI.

By end of day you have a baseline table in Excel or Google Sheets that becomes the comparison axis for the next 12 months. The question "was the workshop worth its money?" stops being gut feel and becomes auditable.

What we measured at SHD Düsseldorf

At a 120-FTE mid-cap in Düsseldorf we applied the framework to nine devs in the engineering tech team. The program ran for 90 days. Here are the verifiable numbers:

KPI	Before program	After 90 days	Change
Adoption rate	10 %	72 %	+62 points
Cycle time, medium tickets	4.2 days	3.0 days	−28.5 %
Cycle time, large tickets	11.8 days	9.1 days	−22.9 %
PRs per dev per sprint	6.1	7.4	+21.3 %
Change failure rate	8.2 %	7.8 %	flat
Workforce segments	n/a	3 / 5 / 1 (HP/A/NA)	data basis for HR

The headline ~28 percent velocity gain comes from the weighted cycle time per size class, not from story points. Extrapolated across the 120-FTE tech team we identified €120,000 of annual savings from the productive tech-team share alone, without downstream effects.

Three things we learned from the measurement:

1. Cycle time on large tickets falls more slowly than on medium. That is expected — large tickets often contain architecture discussions where AI tools have less leverage. Even so, −23 percent is a clear signal.
2. PRs per dev per sprint rose less than cycle time fell. That suggests devs invested the saved time not just in more tickets, but in deeper reviews and refactors. Qualitatively valuable, but invisible in a pure "velocity-up" metric.
3. Workforce segmentation produced three high performers, five adopters, and one non-adopter in the 9-person sample. The non-adopter was an experienced senior who argued the case substantively. That is not a "must go" signal — it is a "needs coaching plus senior sparring" signal.

Why 1.5x is the right entry target

If you've been in the market, you've heard 10x, 50x, 100x. McKinsey 2026 cites 16 to 30 percent at the top 20 percent. GitHub's RCT cites 55 percent on scoped tasks. Realistically, sustainable, organisation-wide acceleration in year one sits between 30 and 80 percent depending on stack, seniority mix, and program discipline.

We set 1.5x (i.e. 50 percent cycle-time reduction at constant quality) as the entry target because:

1. It is ambitious enough that you need a program lever to hit it. Nobody hits 1.5x with a licence rollout alone.
2. It is honest enough for the CFO extrapolation to hold. For a 50-dev team at €60,000 annual salary per dev, 1.5x cycle time equals 50 percent of engineering capacity freed up — at a conservative 50 percent realisation rate, that's a net €750,000 a year. That is a number that survives the steering meeting.
3. It leaves room for the second wave (multi-agent, larger skill libraries, cross-model review), where another 30 to 50 percent becomes realistic.

Anyone promising 10x has either seen a demo, or is selling. Anyone delivering 1.5x in 90 days while pulling adoption from 10 to 70 percent has built a productive engineering system.

Start the AI readiness check (5 min, free) →

What your next step should be

If you have no baseline today, that's the first step. We set up baseline and KPI tracking in one day at your shop. Fixed package, clear output: cycle-time table per size class, adoption thresholds, KPI dashboard setup, plus 12-month comparison plan.

If you have a baseline but no measurable AI acceleration yet, we walk through 30 minutes on which of the four KPIs the lever sits on. Adoption is the most common bottleneck, followed by a weak size-class definition that masks velocity effects.

In every case: success-based fees. 60 percent of identified annual savings are our fee, 40 percent stay with you, plus the full productivity uplift of your remaining workforce.

Book a 30-minute assessment call →

FAQ

How long does setting up a baseline take?

Usually one day if Jira or Linear data from the last 12–18 months is available. With missing data or inconsistent ticket history it can take up to three days, because a minimum data quality has to be established first.

Which tools deliver reliable adoption logs?

GitHub Copilot Enterprise, Cursor (via Trust Center API), Claude Code (via Anthropic Admin API), and Codex Enterprise all deliver granular session logs. In mixed setups we add a wrapper layer on the AI knowledge platform.

What's the difference between 1.5x cycle time and 1.5x velocity?

Cycle time is time-to-done of an individual ticket per size class; velocity is the sum of completed tickets per sprint. 1.5x cycle time means a ticket of a given class needs one-third less time. 1.5x velocity means 50 percent more tickets get closed per sprint. They correlate but are not identical. We measure cycle time because it is less prone to story-point inflation.

What is the METR perception gap?

The METR 2025 study measured in a randomised controlled experiment that experienced open-source devs with AI tools take 19 percent longer on their tickets — while at the same time being convinced they are 20 percent faster. That 40-pp perception gap is the main reason subjective survey KPIs are not enough.

What does workforce segmentation into high performers, adopters and non-adopters mean?

We consolidate adoption, velocity, and ability data into three segments. High performers are the top 20 percent (multipliers). Adopters are the solidly steerable 50 to 60 percent (coaching addressees). Non-adopters are 15 to 25 percent with no visible adoption or velocity uplift after 90 days. Personnel decisions stay 100 percent with the company; we deliver the data basis.

Which DORA metrics do you use as cross-validation?

Lead time for changes, deployment frequency, change failure rate, mean time to recovery. If cycle time per size class falls but change failure rate rises, you don't have real acceleration — you have error displacement. A serious AI adoption must not tip DORA.

How does this work alongside AI Act compliance?

KPI capture runs GDPR-compliant and auditable. The AI knowledge platform logs every session per developer with tool calls, inputs, outputs, and review status. That is the same data basis for AI Act Art. 4 (demonstrable team-level AI capability) and for KPI evaluation. Compliance and performance measurement collapse into one, instead of blocking each other.

Sources

• Bitkom AI study 2026
• PwC AI Performance Study 2026
• GitHub Research: Copilot productivity
• McKinsey: Unleashing developer productivity with generative AI
• METR study 2025: 19 percent slowdown
• Stack Overflow Developer Survey 2025
• DORA: State of DevOps Report
• Accenture: Measuring the impact of GitHub Copilot