Skip to main content
FeatureFactory

Guide

Measuring the ROI of Engineering (and AI Coding Tools)

Engineering ROI is value shipped per unit of cost. Here is a defensible approach: combine velocity, quality, and rework, attribute AI vs human honestly, and frame it as outcomes, not surveillance.

The question
Value shipped per unit of cost
Three inputs
Velocity, quality, rework
AI angle
Attribute AI vs human honestly
Wrong framing
Surveillance and per-person ROI
Report as
Outcomes, not activity
Pairs with
DORA and benchmarks

Engineering ROI is the value your team ships relative to what it costs to ship it. It is one of the hardest things to measure honestly, because the easy proxies (hours, tickets, lines) measure activity rather than outcome, and because AI coding tools have made "who produced this" genuinely ambiguous.

This guide lays out a defensible approach: combine velocity, quality, and rework rather than any single number; attribute AI versus human contribution transparently; and frame the whole thing as outcome measurement, not surveillance. The aim is a number a CFO can trust without a number an engineer would resent.

1

Anchor ROI to shipped outcome, not activity

The numerator of ROI must be value that reached production, not effort spent. Tickets closed, hours logged, and commits pushed all measure motion, not results. Tie ROI to merged, impactful work and, where you can, to the business outcome it drove. This keeps the metric honest and resistant to gaming.

2

Combine velocity, quality, and rework

No single metric is ROI. High velocity with high rework is expensive churn. High quality with no throughput is not shipping value. Read the three together: velocity for how much, quality for how well, and rework for how much you had to redo. A healthy ROI story shows throughput holding or rising while rework stays low.

3

Attribute AI versus human honestly

To measure the ROI of an AI coding tool you must know what it actually produced. That means attributing lines and changes to AI versus human based on evidence (declared trailers, per-commit signals), not vendor claims. An honest split lets you compare quality and rework for AI-assisted versus human-only work and see whether speed gains came at a cost.

4

Put cost on the same footing

The denominator is loaded cost: engineer time plus tool spend (including LLM token cost). Convert shipped outcome and cost into the same units so ROI is a ratio you can defend. Keep the assumptions explicit and editable; a fabricated precise number is worse than a clearly-stated estimate.

5

Avoid the surveillance trap

ROI framed as per-person productivity ranking destroys trust and produces worse data, because people optimize the metric instead of the outcome. Keep ROI at the team and initiative level, never rank individuals, and be transparent about how it is computed. Measurement that engineers believe is fair is measurement they will not fight.

FAQ

Attribute what the tool actually produced (AI vs human lines and changes based on evidence), then compare velocity, quality, and rework for AI-assisted work against human-only work. Divide the shipped outcome by loaded cost including token spend. The honest attribution step is what separates a real ROI number from a vendor claim.

Related guides