Your CEO Sees 5x. Your Engineers See a Longer Review Queue.

Two surveys, one season, and two very different companies.

Between December 2025 and January 2026, WRITER and Workplace Intelligence surveyed 1,200 C-suite executives. 87% said their AI "super-users" are at least 5x more productive than colleagues who aren't using AI.

In April 2026, Harness surveyed 700 engineering practitioners and managers at large enterprises. 81% said developers now spend more time in code review since AI coding tools arrived. 28% said review time had gone up by more than 30%.

Both numbers can be true at once. That's the problem.

This is part 2 of a series on how engineers who learned their craft before AI see what's happening now. Part 1 looked at their trust. This part looks at the distance between their view and the view from the top floor.

The Gap Has Numbers Now

For a while, "leadership doesn't get it" was just something people said at the pub. It shows up in the data now.

Atlassian's State of Developer Experience 2025 surveyed 3,500 developers and managers across six countries. 63% of developers said leaders don't understand their pain points. A year earlier it was 44%. That's a 19-point jump in twelve months, during the year AI rollouts sped up.

Upwork found the same shape back in mid-2024, across workers in general rather than developers specifically: 96% of C-suite leaders expected AI to raise productivity, and 77% of employees using AI said it had added to their workload. 47% said they had no idea how to deliver the gains their employer expected.

Look at what that gap is made of. It's not one side saying AI is great and the other saying it's useless. Both sides agree the tools are powerful. They disagree about where the time went.

The 10-Hour Wash

The Atlassian data has the neatest version of this.

The good news: 99% of developers reported saving time with AI, and 68% said they save more than 10 hours a week.

The bad news, from the same survey: 50% said they lose more than 10 hours a week to organizational inefficiency. Hunting for information. Adopting new tools. Context switching. Working with other teams.

Atlassian's own summary: "we're right back where we started."

The detail that explains it, from the same Atlassian write-up: developers spend only about 16% of their time actually coding. Most AI investment went to coding assistants, so the part that got faster was the 16%. The other 84%, the meetings and tickets and "who owns this service?", mostly stayed the same.

From the executive side, the 10 saved hours are real and show up in a dashboard. From the engineer side, the 10 lost hours are just as real and show up nowhere.

If you saved ten hours and lost ten hours, did you get more productive?

Leaders Believe Their Dashboards. Engineers Don't.

The Harness report is almost uncomfortable to read, because the contradiction sits right there in the numbers.

• 89% of engineering leaders say productivity has improved since adopting AI coding tools.
• 89% say their current metrics accurately reflect AI's impact.
• But 94% say key factors are missing from those metrics: tech debt, validation time, developer burnout.
• Only 6% think their current frameworks can fix that.

Organizations in the survey estimated that about 31% of developer time now goes to "invisible work": reviewing AI-generated code, fixing bugs, switching between tools. It's time that doesn't get tracked anywhere.

Then there's the question of who's afraid of the numbers. Managers were almost four times more likely than practitioners to say they had no concerns about how AI productivity data would be used (15% vs 4%). 54% of respondents feared individual performance reviews based on AI data.

So the people who build the dashboard trust it, and the people being measured by it don't. That says something about the dashboard, not only about the people.

Where the Two Visions Actually Split

This is my read of the data rather than a finding from it. I think the gap comes down to three differences in what each side is looking at.

Time horizon. Leadership thinks in quarters and board meetings. An engineer thinks in terms of when this code will page them. A feature shipped in two days instead of five is a win this quarter. Whether it's a win in six months depends on things no quarterly dashboard captures.

Unit of measure. Executives count output: PRs, features, tickets closed, tokens used. Engineers count the cost of keeping it running: review time, rework, incidents, the service nobody understands anymore. GitClear's finding that copy-pasted code overtook refactored code in 2024 is exactly the kind of thing that looks like output going up.

Who holds the risk. When AI speeds up delivery, leadership gets the credit. When it adds instability, engineers deal with the incident. Google's 2025 DORA report found AI adoption now correlates with higher throughput and also with continued instability, and that the instability hurts product performance and burnout.

Neither side is lying. They're standing in different places and describing what they see.

Here's the Part Engineers Miss: The C-Suite Doesn't Fully Believe It Either

It's easy to picture executives as naive optimists. The WRITER data says otherwise.

In the same survey where 87% of executives praised their 5x super-users:

• 75% said their company's AI strategy is "more for show" than real guidance.
• 48% said AI adoption at their company has been "a massive disappointment."
• Only 29% reported significant ROI from generative AI.
• 64% of CEOs said they fear losing their job if they don't get the AI transition right.

Put that together and you get a clearer picture. The executive telling your all-hands that AI will double your output may privately think the strategy is mostly theater, and may be afraid of the board if it doesn't work out.

The C-suite isn't naive. It's cornered. Engineers who treat that as stupidity will argue with the wrong person.

What Would Actually Close the Gap

The sources agree on this part more than on anything else.

Atlassian's step one is to talk to your developers, "(always)" in their own words. They also make a point engineers don't hear often: developers need to describe their problems in terms of impact, so leadership can act on them instead of dismissing them as complaints.

Harness found developers asking for three specific things: a clear line between improvement data and performance reviews (55%), transparency about what's being measured (50%), and a say in defining the metrics (49%).

None of that is a technology purchase. All of it is cheaper than another round of licenses.

The Takeaway

Leadership is measuring how fast code arrives. Engineers are measuring how long it stays broken. Until those two show up on the same dashboard, both sides will keep calling the other one wrong.

Your turn:

• Does your leadership's AI story match what your Tuesday actually looks like?
• If you could add one metric to your org's AI dashboard, what would it be?
• Leaders reading this: when did you last ask an engineer where their saved hours went?

Next in the series: the memo went out. Shopify, Coinbase and Meta all turned "use AI" into policy, in three very different ways.

Sources

• WRITER / Workplace Intelligence, 2026 AI Adoption in the Enterprise survey (2,400 knowledge workers, Dec 2025 – Jan 2026)
• Harness, The State of Engineering Excellence 2026 (700 practitioners and managers, April 2026)
• Atlassian, State of Developer Experience 2025 (3,500 developers and managers)
• Upwork Research Institute, Employee workloads rising despite C-suite AI investment (2,500 respondents, July 2024)
• Google DORA, 2025 State of AI-assisted Software Development · summary via IT Revolution
• GitClear, AI Copilot Code Quality 2025