Harness published The State of Engineering Excellence 2026 in April, and the number that matters is 31%. That is the share of a developer's working day now consumed by what the report calls invisible work: reviewing AI-generated code before merging it, debugging the bugs AI introduced, and steering agentic sessions that drift without constant human correction.
That is a third of a work week that shows up in no commit count, no PR metric, no DORA calculation. Your AI tools increased your code output. They also created a second shift you are not getting credit for.
What the 31 Percent Actually Looks Like
The invisible work is not abstract. It has a specific shape that anyone using agentic coding tools has encountered.
You ask an agent to refactor a service. It produces something that compiles. You spend 45 minutes reading through it to verify it did not introduce subtle behavioral changes, miss edge cases, or make assumptions about state that do not match the actual runtime. The agent made the change. You validated it. The commit history shows the change. It does not show the 45 minutes.
Or: you delegate a multi-file feature to an AI session. The session completes, sort of. The first pass introduced a dependency conflict in a different module. You redirect the agent. It corrects the conflict but misses an interface the original code was implementing. You redirect again. Three passes later, the feature works. The total elapsed time across those passes is twice what the raw agent time would suggest. The extra time is steering overhead, and it is not tracked anywhere.
The Harness report surveyed 700 engineers across the US, UK, India, France, and Germany. Ninety-four percent agreed that tech debt accumulation, validation time, and developer burnout were missing from their organization's current metrics. The invisible work is not invisible to the developers doing it. It is invisible to the measurement systems those developers are being evaluated against.
The Part That Should Make Engineering Leaders Uncomfortable
The 31% figure is the average. It is also not the most significant finding in the report.
Fifty-four percent of developers fear their AI productivity data will be used against them in individual performance evaluations. That is not paranoia. It is a reasonable inference from how most engineering metrics work. If your organization measures code output, commits, and accepted AI suggestions — and AI tools have increased all of those numbers — then the developers who generate the most AI output look the most productive by the metrics that exist.
What those metrics do not capture: how much of that output needed substantial correction, how much human review time it consumed, whether the code that shipped clean and fast is accumulating hidden complexity that will surface as bugs in six months. The metric that makes you look productive and the metric that measures your actual contribution are now different things.
The leadership-practitioner divide makes this sharper. Managers were nearly four times more likely than practitioners to report no concerns about how AI productivity data might be used in performance evaluations — 15% versus 4%. The people designing the measurement systems are not the people who feel the distortion. The gap between those two groups is where the misalignment lives.
This is the structural problem underneath the 54% number. Developers are not worried about measurement in the abstract. They are worried that the measurement systems being built right now capture the work AI does and not the work they do to make AI outputs usable. That worry is correct.
Why Traditional Metrics Cannot See This
PR count was always a flawed proxy for productivity, but it was at least roughly correlated with work done. The introduction of AI-generated code broke even that correlation.
A developer using AI tools aggressively might open more PRs than before — while doing significantly more validation, debugging, and correction work per PR. The PR count went up. The work per PR also went up. The metric sees the first change. It is structurally blind to the second.
The same problem applies to accepted suggestion rates, which is what tools like Copilot surface in their dashboards. A high acceptance rate tells you a developer accepted many AI suggestions. It tells you nothing about whether those suggestions were correct on first read, or whether the developer accepted them while moving too fast to review carefully. The bugs that come back from those PRs in three weeks do not link back to the acceptance decision that created them.
The Harness report does not present this as a failure of individual developers. It presents it as a failure of measurement frameworks to keep up with a fundamental shift in what software development work looks like. The frameworks were designed to measure an activity where humans wrote the code. Auditing and steering machine-generated code is a different activity with a different cost structure, and most organizations do not have instruments that can see it.
What Your Session Actually Contains
The metrics that could close this gap exist in the raw data of your working sessions. They are just not being collected or surfaced by any mainstream tool.
The ratio of time spent in an AI session to time spent in the terminal and debugger after the session ends is a rough proxy for how much correction work the AI output required. If your AI generation blocks are consistently followed by long debugging stretches, the net time cost of that task is not what the AI completion time suggests.
The same goes for context switches during an agentic session. Each time you interrupt to correct course, there is overhead — reading the agent's current state, formulating the redirect, waiting for a new completion. Those interruptions accumulate. A session with many steering events is more expensive than the raw output volume implies.
At xeve, we track working sessions at the system level: what applications ran, in what order, for how long, with what switching patterns between them. The developer who spends two hours in Cursor followed by ninety minutes in a terminal running tests and fixing output is doing different work from a developer who ships code directly. Neither is less productive — they are working differently. The difference matters for understanding what the session actually cost.
This is the measurement gap the Harness report describes. Not that developers are hiding something, but that the visible artifacts of modern software development — commits, PRs, accepted suggestions — do not contain the information that would tell you what the work actually required. A third of the workday is invisible because nobody built the instrumentation to see it.
The Incentive Structure This Creates
Fifty-four percent of developers are worried their AI productivity data will be used against them. That fear, if it is accurate, produces a predictable outcome: developers who are aware of measurement optimize for the measurement.
If accepted suggestion rate is what gets tracked, developers accept more suggestions. If commit count is what gets tracked, developers break work into smaller commits. Neither of those behaviors necessarily makes the software better. They make the numbers better, which is the rational response when the numbers are what performance reviews use.
The measurement systems being built now, in the months when AI tooling is becoming the default rather than the exception, will shape developer behavior for years. Organizations that capture only the output side of AI-assisted development — lines generated, suggestions accepted, PRs opened — will create incentive structures that ignore the validation and steering work that determines whether that output is actually good. The 31% becomes a cost that is borne but not seen, which is a different kind of problem than a cost that is measured and accepted.
The Harness report came out in April. Four months later, most engineering organizations are still using the same metrics they had before agentic coding tools became common. The measurement hasn't caught up with the work, and the developers doing the invisible third of it are keeping track of that fact even if the dashboards are not.