Why Organisations Need to Rethink How They Measure Engineering Performance in the AI Era | Chandrashekar | Regional Director – People & Talent | Harness

For decades, engineering leaders have searched for better ways to measure productivity.

Lines of code gave way to story points. Story points evolved into velocity metrics. Velocity expanded into DORA metrics, developer experience surveys, and business outcomes. Each step brought organisations closer to understanding how software is built and delivered.

But with the advent of AI, much of the conversation around software development has focused on speed. Developers are generating code faster, completing routine tasks more quickly, and moving through workflows that once consumed significant time and effort.

Those gains are real, but are the metrics we rely on today still measuring the work that matters most?

Recent findings from Harness’ State of Engineering Excellence 2026 report illustrate this contradiction clearly. While 89% of engineering leaders report improved developer productivity after adopting AI coding tools, and an equal percentage believe their current metrics accurately capture AI’s impact, 94% simultaneously acknowledge that important factors such as validation time, technical debt, and developer burnout are missing from those same frameworks.

The numbers show that engineering organisations are increasingly confident in systems they also know are incomplete.

When Output Becomes Easy, Measurement Gets Harder

For much of software development’s history, output served as a reasonable proxy for productivity. More code often meant more progress and completed work often meant more value.

Today, code can be generated in seconds, tests can be written automatically, and documentation can be drafted instantly. The volume of output is no longer constrained by the speed at which humans can type.

Yet software engineering has never been solely about producing code.

The real work lies in understanding problems, making trade-offs, designing resilient systems, managing risk, maintaining quality, and delivering outcomes that matter to customers.

As the cost of producing software declines, the challenge shifts from measuring activity to understanding impact.

The Rise of Invisible Engineering Work

Recent research from Sonar found that AI now accounts for 42% of committed code, yet 96% of developers do not fully trust that code.

The findings from Harness’ State of Engineering Excellence 2026 report point in the same direction. Nearly 31% of a developer’s day is now spent reviewing code produced by AI tools, resolving defects, explaining machine-generated logic, and navigating between tools. At the same time, 81% of engineering leaders report increased code review effort since introducing AI coding assistants.

These activities rarely appear in traditional productivity frameworks, yet they are becoming an increasingly important part of software delivery.

Organisations can easily measure how much code is being generated, but understanding the effort required to validate, refine, and operationalise that code is considerably harder.

As AI adoption grows, this layer of work will become increasingly important to understand.

Engineering Performance Is Becoming About Judgment

Engineering teams have always needed some way to understand performance, so they have often leaned on what was easiest to observe: commits, tickets closed, cycle time, and delivery velocity.

Today, the most important differentiators sit beyond those visible markers. The work that creates the greatest value often involves problem framing, architectural thinking, risk assessment, sound decision-making, and the ability to guide increasingly capable tools toward meaningful outcomes.

These contributions rarely show up neatly on a dashboard.

As a result, engineering impact is becoming less about generating output and more about applying judgment. Yet many performance systems still emphasise visible activity over the deeper work that drives long-term outcomes.
The challenge is not that existing frameworks are wrong, but that they were designed for a world where engineering value was far more visible.

That shift is turning measurement from an operational exercise into a leadership challenge.

Measurement Is Becoming a Trust Challenge

Teams engage differently with measurement when it is used to improve performance rather than judge it. That distinction is becoming increasingly important as engineering workflows evolve.

Atlassian’s 2025 State of DevEx research found that while AI is helping developers save time, many continue to lose significant hours to fragmented workflows, poor collaboration, and difficulty finding information. The study also highlighted a growing gap between leadership perception and developer reality, with many developers feeling that the friction affecting their day-to-day work is not fully understood.

In this environment, better measurement cannot simply mean collecting more data. It requires clarity of purpose and confidence in how information will be used.

This distinction between measurement that enables improvement and measurement that enforces compliance is becoming one of the defining leadership challenges of the AI era. Without trust, even the most sophisticated dashboards struggle to produce meaningful insight.

Evolving the Framework

The answer is not to replace existing frameworks, but to evolve them.

Measures such as DORA, developer experience, and business outcomes remain essential. What has changed is the nature of the work they are being asked to capture. As AI becomes embedded across the software development lifecycle, leading organisations are expanding their view beyond throughput to include factors such as validation effort, rework, code quality, technical debt, cognitive load, and the downstream impact of AI adoption on delivery and customer outcomes.

As these dimensions become part of the measurement conversation, engineering effectiveness can no longer be understood through speed alone. The organisations that navigate this transition well will be those that develop a clearer understanding of how value is created, where it is being lost, and what needs to improve over time.
To begin that transition, leaders should consider four practical steps. First, audit existing metrics for blind spots by identifying which activities, such as code review, AI validation, and cross-team collaboration, remain invisible in current dashboards. Second, involve developers in metric design. The people closest to the work are often best placed to identify gaps that existing frameworks overlook. Third, track cognitive load and wellbeing alongside delivery metrics, since burnout and invisible workload are often early indicators of retention risk. Finally, revisit performance conversations so managers are equipped to discuss judgment, influence, and strategic contribution, not just output, in regular 1:1s and reviews.

Ultimately, the goal is to build a more complete understanding of engineering performance in a world where the nature of the work is rapidly changing.