AI coding tools create net negative value for most enterprises

At a glance

What this is: This article argues that AI coding tools are producing net negative value for most enterprises because teams lack the metrics, operating model, and product fit needed to translate model capability into useful output.

Why it matters: It matters because IAM, platform engineering, and security leaders need to govern how AI-assisted work is measured, adopted, and controlled before productivity claims become unreviewed operational risk.

Context

AI coding tools are often sold as productivity accelerators, but enterprise value depends on whether organisations can measure output, define quality, and create enough structure for adoption to stick. In this case, the governance gap is not access control or authentication, but the absence of a shared productivity model that makes the tool’s impact legible.

The panel described a market where many teams still judge productivity by feel, then layer in metrics such as PR throughput, review latency, and code-to-production time. That shift can help, but it also creates a trap if the metrics reward volume while the tool is still generating friction, rework, or hidden future cost.

Key questions

Q: How should enterprises measure productivity when using AI coding tools?

A: Measure productivity with a balanced model that includes delivery speed, review quality, defect escape, and downstream maintenance cost. PR counts or commit volume alone can be misleading because they reward output quantity even when the tool is creating rework or reducing code quality. The right metric set should show whether AI assistance is improving the system, not just increasing activity.

Q: When does an AI coding tool create more cost than value?

A: It creates more cost than value when faster output increases review burden, maintenance debt, or customer friction faster than it improves delivery. That is common when teams adopt the tool without a clear workflow, consistent usage conventions, or a defined success metric. In that situation, apparent productivity gains can be offset by hidden operating costs.

Q: What are the signs that an AI coding agent is failing on a development task?

A: Common warning signs include repeated attempts with similar changes, hallucinated code, failure to resolve dependency errors, and inability to recover from timeouts or incomplete understanding. If the agent keeps circling the same problem or produces broad, non-incremental edits, it is usually beyond the point where autonomous execution is efficient.

Q: Should teams rely on AI coding tools for core engineering workflows?

A: Only if the team has already defined the workflow boundaries, the quality gates, and the success measures that separate useful assistance from noisy automation. For core engineering work, the question is not whether the tool can produce code, but whether the organisation can control how that code is reviewed, maintained, and judged over time.

Technical breakdown

Why agentic coding tools create a productivity measurement problem

Agentic coding tools do not just assist with typing code. They can generate drafts, expand tasks, and reshape how work is decomposed, which means traditional productivity signals can become misleading. If teams measure only PR volume or commit frequency, they may mistake output inflation for delivery improvement. The core technical issue is that the tool changes the unit of work, but many organisations still measure the old unit. That makes the system hard to evaluate because the same dashboard can show higher throughput while actual engineering value falls.

Practical implication: Define productivity around delivery quality and business outcome, not just code volume or review count.

Why prompting friction is often a product and operating-model issue

The panel’s point about users being told they are ‘prompting wrong’ reflects a broader implementation problem. When a tool requires a hidden vocabulary, a specific naming convention, or a lot of tribal knowledge before it works well, the burden shifts to the user instead of the system. In enterprise settings, that creates uneven outcomes because only a minority of users will invest the time needed to get value. The problem is not merely user error. It is a mismatch between product design, team enablement, and the organisation’s ability to standardise usage.

Practical implication: Treat prompt quality, naming conventions, and usage patterns as governed operating inputs, not personal preferences.

Why AI-generated velocity can increase future operational cost

Faster code creation does not automatically reduce engineering cost. AI-generated output can introduce maintainability debt, weaker quality checks, and a larger downstream burden on review, testing, and support. The panel’s framing is important because it recognises that future cost can be pulled forward into the present. When that happens, apparent efficiency today can become rework, customer friction, or security exposure later. The enterprise decision is therefore not whether the tool is fast, but whether speed is being purchased at the expense of long-term operability.

Practical implication: Assess AI-assisted development for lifecycle cost, not only for immediate delivery speed.

NHI Mgmt Group analysis

Enterprise productivity has become a governance problem, not just a tooling problem. The panel’s 80 percent net-negative finding shows that capability alone does not create value when organisations lack shared definitions of productivity. In practice, this is a lifecycle and operating-model issue: teams can buy the tool, but they still need decision rules for how it is used, measured, and judged. The implication is that productivity tooling now belongs in the same governance conversation as access, workflow, and operating standards.

Metric theatre is the new failure mode. Once organisations start managing developer productivity by proxy metrics like PR count or commit velocity, they can optimise the appearance of progress without improving outcomes. That is especially dangerous in enterprises where different teams control different stages of the workflow, because local optimisation can mask systemic drag. The practitioner takeaway is that governance must inspect whether the metric reflects customer value, not whether it is easy to collect.

Productivity tools are exposing a familiar enterprise truth: adoption is not the same as value realisation. A tool can be widely available, frequently tried, and still fail to change outcomes if the organisation never operationalises how it should be used. This is why the 20 percent who extract value matter. They are not just better users; they are usually operating inside clearer rules, tighter workflows, and more explicit expectations. Teams should read this as a signal that enablement and governance matter as much as feature depth.

Productivity definition debt: The article shows that many enterprises still cannot articulate what productivity means in measurable terms, which leaves vendors and end users arguing past one another. That debt becomes visible the moment a team tries to justify AI coding adoption with data. Practitioners should treat definition debt as a core programme risk because it determines whether any measurement, procurement, or rollout discussion can be trusted.

What this signals

Productivity definition debt: Enterprises that cannot define productivity in measurable terms will keep arguing about AI coding tools at the level of sentiment instead of evidence. That is a programme risk because it blocks procurement decisions, makes pilot outcomes hard to compare, and leaves adoption to informal enthusiasm rather than governance.

The practical signal for identity and platform leaders is that AI-assisted work now needs its own operating standard. If the organisation can govern access, but cannot govern how tools are used, success will keep depending on a small number of power users instead of being repeatable at scale.

For practitioners

• Define productivity before expanding AI coding use Set a measurable definition of engineering productivity that combines delivery speed, review quality, and downstream impact so the tool is judged on outcomes rather than excitement.
• Create a governed usage model for AI-assisted development Document where the tool is appropriate, what conventions users must follow, and which tasks still require human review so adoption does not drift into inconsistent practice.
• Track future cost alongside velocity metrics Monitor rework, defect escape, maintenance burden, and customer friction so faster code generation does not hide operational debt.
• Separate experimentation from production readiness Use pilots and sandboxes to learn what actually improves output, then require explicit success criteria before broader rollout into core delivery teams.
• Build an enablement path for power users Identify the minority who already get value, capture their workflows, and turn that into shared guidance so the organisation does not rely on accidental expertise.

Key takeaways

• Most enterprises are not failing because AI coding tools lack capability. They are failing because productivity is still poorly defined and inconsistently measured.
• The article’s 80 percent net-negative figure shows that a large majority of users are not yet capturing value from these tools in real enterprise workflows.
• The control point is not model quality alone. It is the combination of measurement, enablement, and workflow governance that determines whether AI-assisted development helps or hurts.

Key terms

• Productivity definition debt: The gap that appears when an organisation cannot state what productivity means in measurable, operational terms. In AI-assisted work, that gap makes it easy to mistake more output for better outcomes, which creates confusion in procurement, rollout, and performance review.
• Metric theatre: A situation where teams optimise for visible metrics that are easy to report but do not reliably reflect real business value. In software delivery, this often means chasing PR counts, commit volume, or turnaround times while missing quality, maintainability, and customer impact.
• Future cost: The downstream expense created when present-day speed shifts work into later review, maintenance, support, or remediation. With AI-generated code, future cost can be hidden by faster delivery in the short term, so practitioners need controls that account for lifecycle impact.
• Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.