How AI software development shifts costs beyond engineering budgets

AI productivity gains bring governance costs into view

Higher engineering productivity can come with higher costs for software governance: reviewing, approving and maintaining the software an organisation uses. ActiveState’s research found that 93% of respondents reported improved engineering productivity, while 83% said developer productivity was advancing faster than governance. For technology leaders assessing AI-assisted development, the financial question is where the extra work falls, because security, compliance and operations can absorb costs outside an engineering productivity calculation.

The research comes from ActiveState, which has a commercial interest in organisations investing in open source governance: managing software whose code is available for others to use and modify. Titled “AI software development adds hidden governance costs,” it surveyed 307 security, governance, platform and engineering leaders and included 10 in-depth practitioner interviews. It covered organisations with 1,000 or more employees in North America and Western Europe, defining the organisational setting for its findings.

Within that setting, confidence in scaling remains high: 71% of respondents to ActiveState’s survey believed their current approach could scale. Yet confidence can coexist with governance strain because producing more software and managing its consequences require separate capabilities. Assessing the return on AI-assisted development therefore means connecting engineering output with the work that follows it.

Faster development increases dependency intake

The additional governance work begins with the components developers select. A dependency is an external software component that an application uses, and 94% of respondents in ActiveState’s research said AI had increased their consumption of open source software. More components mean more decisions about security, approval and maintenance, so faster code generation also increases the volume of software teams must govern.

Security alerts often prompt those decisions: ActiveState found that 63% address open source vulnerabilities only after scanners or security tools identify them. A component enters development, a tool later identifies a weakness, and a team returns to fix it. Review can also lag behind deployment, with half of respondents saying new dependencies can reach production, the environment where applications run, without prior review or approval.

These practices create two control problems: teams must fix weaknesses in components already selected, and some components reach running applications before anyone decides whether to accept them. ActiveState argues that AI accelerates both code generation and the movement of open source components toward production while governance still depends heavily on later scanning. Development can therefore advance before review and correction occur.

Rework consumes capacity across separate budgets

When review happens later, some consequences appear as engineering rework. ActiveState estimates that AI-assisted development creates more than 13,900 engineering hours of rework a year at large enterprises, with each engineer spending at least 139 hours annually fixing or revisiting AI-assisted work. Its example of a workforce of 100 engineers puts the annual workload at roughly seven full-time staff. This measures engineering capacity consumed; it does not represent an actual hiring requirement, recorded expenditure or guaranteed saving.

That capacity cost can coexist with higher productivity because engineers can produce more with AI assistance while also spending time correcting the output. An engineering assessment therefore needs to count both initial production and the effort required to make the work usable. Rework is one part of that balance; security, compliance and operations carry additional responsibilities through their own budgets.

Abby Kearns, Chief Executive Officer at ActiveState, links those separate budgets to the difficulty of seeing the total cost. She advocates making acceptance decisions when components enter the codebase, the collection of code used to build and maintain an application. Her recommendation also aligns with ActiveState’s commercial interest in demand for open source governance.

“AI is becoming a permanent part of how software gets built, but our research found engineers spend significant time fixing or revisiting AI-assisted work. That’s only engineering’s share. Security, compliance and operations pay the rest out of their own budgets, so the full bill stays hidden. The way to keep the gains is to govern open source as it enters the codebase,” said Kearns.

ActiveState’s cost-estimation findings show how organisations currently account for the broader risk: only 31% had formally quantified the cost of unmanaged open source risk, while 47% had an informal estimate. These percentages describe how costs are assessed. They do not measure the amounts spent. Formal quantification and informal estimates also give leaders different levels of detail when deciding how to allocate resources.

The scope of those estimates matters because unmanaged open source risk extends beyond rework on AI-assisted development. A combined assessment needs to connect costs across engineering, security, compliance and operations while keeping those categories distinct. Leaders can then assess operating costs without assigning every open source problem to AI or treating engineering rework alone as the overall productivity balance.

Dependency failures affect delivery, compliance and security

The reported operational consequences make the reason for connecting those budgets clearer. ActiveState found that 76% of respondents had experienced a software release delay caused by unmanaged open source dependencies in the past year. Dependency management therefore affects when teams can deliver software, extending its business impact beyond the hours spent writing and revisiting code.

Alongside delivery delays, compliance work makes another claim on staff time. In ActiveState’s survey, 58% said they had received a compliance or audit finding related to open source governance. Addressing these findings involves teams responsible for checking whether development meets organisational requirements, so work arising from software built by engineers can fall within another department’s budget.

Security incidents add a further operational consequence: 32% of respondents to ActiveState’s survey confirmed an incident in the past two years that could be traced to an unmanaged dependency. Separately, 83% said the overall cost of managing open source risk was increasing. This cost measure tracks the direction of governance spending, while the earlier productivity finding concerns how quickly governance keeps pace with development.

Each measure describes a different part of the operating environment into which AI introduces more dependencies. Release delays cover the past year, security incidents cover the past two years, and compliance findings form a separate measure. Keeping these categories separate preserves their meaning: they describe existing delivery, compliance and security consequences, while AI increases the flow of components requiring attention.

Earlier controls change when dependencies are accepted

Against that operating background, Kearns proposes moving acceptance decisions to the point where open source enters development. Earlier review lets teams decide whether a component is acceptable before it moves toward deployment. This changes where controls operate in the development process, while later scanning continues to address weaknesses found after selection.

Respondents to ActiveState’s survey also favoured putting more effort into prevention before deployment. They said 26% of current open source governance effort goes to that work, compared with the 37% they believe should go there. These figures express their preferred allocation of effort; evaluating the change requires examining how earlier decisions affect the review, correction and operational work teams currently perform.

The timing problem is also central to the explanation from Jim Mercer, Program Vice President, Software Development, DevOps, and DevSecOps at IDC. DevOps connects development with software operations, while DevSecOps incorporates security into that work. Mercer describes how an AI assistant can select a component, generate code that uses it and move the result toward deployment before a later review catches up.

“When an assistant can suggest a secure package, write the code that calls it, and push it toward production in minutes, governance built on static scanning after the fact will always be a step behind,” said Mercer. His reference to minutes illustrates the speed of that sequence. Static scanning examines code without running it, so its timing determines whether it informs component selection or triggers work after the selection has already been made.

To address that timing gap, Mercer recommends controlling entry into the pipeline, the sequence through which code moves toward deployment: “Being able to control what enters the pipeline is key to enabling organisations to scale AI-assisted development.” Like Kearns, he places dependency decisions earlier in development. Teams can assess that change by tracking the review, correction and operational work required after a component is accepted.

Key executive takeaways

• Measure productivity across functions: ActiveState found that 93% of respondents reported engineering productivity gains, while 83% said productivity was advancing faster than governance. CTOs assessing AI returns need to include the resulting work across engineering, security, compliance and operations.
• Review growing dependency intake: AI increased open source consumption for 94% of respondents, and half said new dependencies could reach production without prior review. Platform and security owners can use dependency approval records to identify where components enter production unchecked.
• Account for rework across budgets: ActiveState estimates that engineers spend at least 139 hours annually revisiting AI-assisted work. Finance and engineering owners need to connect that capacity cost with separately funded security, compliance and operations work to assess the full return.
• Track operational consequences separately: Unmanaged dependencies caused release delays for 76% of respondents in the past year, while 32% reported a related security incident over two years. Delivery and security owners need separate measures for these outcomes to establish a baseline as AI increases dependency intake.
• Move acceptance decisions earlier: Respondents allocated 26% of governance effort to prevention before deployment, compared with the 37% they considered appropriate. Platform owners can test earlier dependency review and track its effect on downstream correction, approval and operational work.