AI coding assistants made your developers faster. Almost nobody disputes that anymore. In our new research with 307 enterprise security, governance, platform, and engineering leaders, 93% report higher engineering productivity from AI-assisted development.

The harder question is what that speed costs, and who pays for it.

Our answer: everyone pays a little, in a different budget, so no one sees the total. We call it the AI remediation bill. It is the downstream work created when code and open source dependencies enter the development flow faster than governance can review them. Engineering pays in rework. Operations pays in release delays. Compliance pays in audit findings. Security pays in incidents. Only 31% of organizations have formally quantified the cost of unmanaged open source risk.

The one line item we could put in hours is engineering. Counting every respondent at the minimum of their reported range, engineers spend at least 139 hours a year, more than 17 working days, fixing or revisiting AI-assisted development. For an organization with 500 engineers, that is nearly 70,000 hours, or roughly 34 full-time positions of capacity.

And that is the floor, for one team.

Where the AI remediation bill lands

AI did not create the open source governance problem. It made it move faster. 94% of respondents say AI has increased open source consumption, and each new dependency has a life after it enters the codebase: someone has to review it, secure it, and maintain it.

When governance cannot keep up, that work shifts downstream and splits across owners:

• Engineering: rework on AI-assisted code. At least 139 hours per engineer, per year.
• Operations: releases held up by unmanaged dependencies. 76% had a release delayed in the past year.
• Compliance: findings, evidence requests, and remediation plans. 58% received an OSS-related audit or compliance finding.
• Security: incidents traced to components no one approved. 32% confirmed an incident in the past 2 years.
• Everyone: staff time, tooling, reviews, and audit response. 83% say the cost of managing OSS risk is rising.

Each charge arrives in a different system with a different owner. Developer time sits with engineering. Scanning tools sit with security. Audit response sits with compliance. So most organizations respond to each one separately: another scanner here, another review step there, more people wherever the pressure is worst.

Each fix helps a little. None of them shows the total, and none of them changes why the bill keeps growing.

Why governance keeps falling behind

Most enterprise governance was built for human-paced development. A developer picks a component, a scanner flags an issue, a security or platform team reviews it, and someone patches, replaces, or accepts the risk. That loop worked when decisions moved at the speed of people.

AI-assisted workflows can recommend a package, generate the code that calls it, and move it toward production in one step. The dependency might be chosen by a person, suggested by a model, or pulled in as the dependency of a dependency. The Axios software supply chain attack showed how that plays out: the risk arrived through a transitive dependency no team had chosen.

Leaders see the gap, but many have not accepted what it means. 83% acknowledge that developer productivity is outpacing their governance capability, yet 71% still believe their existing approach can scale. Meanwhile, 63% address open source vulnerabilities only after scanners or security tools find them, and half say new dependencies can reach production without prior review or approval.

Respondents also know where the balance should move. Today they put 26% of open source governance effort into prevention before deployment. They say it should be 37%.

That 11-point gap points to a problem with the model itself. More scanners create more findings. More staff process more findings. Neither reduces how many preventable problems enter in the first place.

Where to start: add up the bill

You cannot reduce a bill you have never seen in full. The first step is to connect the costs your organization already absorbs: engineering rework, release delays, audit response, incident work, staffing, and overlapping tools. The goal is a shared view, so each team stops treating its share as a separate problem.

From there, the question becomes where your current model depends on people and processes that cannot scale with AI-assisted development, and what a control model would need to do to keep pace with it.

The full report goes further. It itemizes each charge with the method behind it, identifies the enterprises hitting the limits of today's governance model first, and lays out a five-step path from remediation to prevention.

Download The AI Remediation Bill