This is your last article that you can read this month before you need to register a free LeadDev.com account.
Estimated reading time: 3 minutes
Key takeaways:
- AI rework costs engineers at least 139 hours a year , and the rest of the bill lands in other teams’ budgets.
- Dependencies outrun review: half of organizations say new dependencies can reach production unchecked.
- Shift effort upstream . Make the approved dependency path the fastest one and track AI rework as its own category.
Your team is shipping faster with AI, yet ActiveState’s new survey finds the gains are offset by rework, delayed releases, and dependencies that reach production before anyone reviews them.
The survey polled over 300 security, governance, platform, and engineering leaders at organizations with 1,000+ employees in North America and Western Europe. Almost half (43%) say at least 10% of an engineer’s time goes on fixing or revisiting AI-assisted code.
Counting every respondent at the bottom of their range, the report calculates a floor of 139 hours per engineer a year, more than 17 working days. For a 100-person engineering org, that’s roughly the annual capacity of seven engineers.
If you’ve ever fought to get headcount approved for two engineers, let alone seven, you’ll know how much that number stings.
Your inbox, upgraded. #
Receive weekly engineering insights to level up your leadership approach.
AI-assisted code doesn’t mean faster delivery #
The report draws on outside research that shows the same pattern. Google’s 2024 DORA report linked greater AI adoption to better code quality and faster code review, alongside lower delivery throughput and stability.
An academic study of GitHub Copilot adoption found productivity gains alongside a 41.6% increase in integration time. As one platform engineering director interviewed for the report put it, individual teams get more productive while other parts of the organization turn into bottlenecks.
The AI rework cost is spread too thin #
Engineering’s 139 hours are only part of the bill and the rest lands in other teams’ budgets:
- Operations: 76% had a software release delayed by unmanaged open-source dependencies in the past year.
- Compliance: 58% received a compliance or audit finding tied to open-source governance.
- Security: 32% confirmed a security incident traceable to an unmanaged dependency in the past two years.
Only 31% have formally quantified the cost of unmanaged open-source risk. Another 47% have an informal estimate, which in most companies means a number somebody said once in a meeting and nobody wrote down.
For engineering managers, the gains show up in velocity metrics while the rework hides in sprint carryover and unplanned tickets. Leadership sees the speed and rarely the full price.
Dependencies arrive faster than anyone can review them #
Nearly every respondent says AI has increased open-source consumption (94%) and dependency growth (96%). Governance mostly happens after the fact: 63% deal with vulnerabilities only once a scanner flags them, and half say new dependencies can reach production with no prior review.
In the TeamPCP attack the report cites, a compromised LiteLLM package reached a developer as the dependency of a dependency of a plugin. Nobody on the team chose it, and neither did the assistant in any meaningful sense. It arrived several levels down the tree, and then it became somebody’s incident.
Jim Mercer, program VP, software development, DevOps, and DevSecOps at IDC, argues that when an assistant can suggest a package, write the code that calls it, and push it toward production in minutes, scanning after the fact “will always be a step behind.”
Being able to control what enters the pipeline is key to enabling organizations to scale AI-assisted development, he adds.
More like this #
Half of open-source policies are followed inconsistently #
Most organizations (92%) have a formal open-source policy, but only 52% say it’s consistently followed.
When the governed path is slow and development is fast, developers ship. If you’re setting AI norms for your team without a company playbook, that gap matters more than the policy document.
Prevention is where the hours come back #
Of all the effort organizations spend managing open-source risk, only 26% goes into stopping problems before code ships. The rest goes on finding and fixing them afterward.
Respondents say prevention should be closer to 37%, and much of that shift sits inside workflows you already control:
Berlin • November 9 & 10, 2026
Close the gap between what leadership expects and what’s actually possible at LeadDev Berlin.
- Make the approved path for adding a dependency the fastest one.
- Treat dependency review as part of code review , including for AI-generated pull requests.
- Track rework on AI-assisted work as its own category, so the 139 hours stops hiding in sprint carryover.
Most respondents (83%) admit developer productivity is outpacing their governance, yet 71% believe their existing approach can scale. When that gap catches up with an organization, engineering teams do the cleanup.