The headline stat: 97% of enterprise developers now actively use AI coding tools, according to a Black Duck study of 831 software engineers and DevOps professionals surveyed in March 2026. GitHub Copilot leads at 83% team adoption; Claude Code has reached 63%. On average, these tools return eight hours of developer time per week. Nine in ten teams credit them with faster, more productive releases. The problem: only 30% of those teams have a fully governed approach to overseeing AI-generated code. A quarter have no defined AI coding policy at all.
What the governance gap actually means
The most common category of problem: AI coding tools shift effort downstream rather than removing it. A developer uses AI to generate a function or a module faster than they could write it manually — but the generated code contains subtle errors, security vulnerabilities, or assumptions that only surface during testing, integration, or production. The time saved in generation is partially clawed back in debugging and remediation. That is the "productivity paradox" pattern — teams feel faster in the moment, but the downstream review burden is not fully measured or accounted for.
The security dimension is where this becomes directly relevant for business risk. 64% of developer teams in the study said they are moderately or extremely concerned that AI coding assistants will introduce security defects into their software. The heaviest users of AI coding tools — the teams writing the most AI-generated code — are the most worried.
This is not a theoretical concern. AI models generate plausible-looking code that may pass code review by a human who assumes the AI "checked the logic." Common patterns include insecure handling of user input, incorrect cryptographic implementations, and API calls that work correctly in test but fail under production load conditions. The code looks right — it does not behave right.
The tracking problem
Knowing which lines of code in a production system were AI-generated is a governance baseline. When a security issue is found, the question "was this human-written or AI-generated?" determines whether the problem is a one-off or a pattern that needs sweeping across the entire codebase. Without systematic tracking — tagging AI-generated code at commit time, not retrospectively — that question cannot be answered quickly. The Black Duck study found that this tracking gap is not a tools problem: the tooling exists. It is a policy and process problem. Teams that have not made AI code tracking mandatory have no baseline when they need one.
Why this matters for UK businesses that are not developers
This story is often read as a problem for software companies. It is equally a problem for any UK business that:
- Buys bespoke software from development agencies or freelancers. If your software supplier uses AI coding tools (statistically, at 97% adoption, they almost certainly do), the code delivered to you contains AI-generated components. Does your supplier have a governance policy? Do they track which code is AI-generated? Do they have an additional review process for AI output? These are now reasonable supplier questions.
- Has an in-house development or IT team. If your developers use AI coding assistants — which they almost certainly do — do you have a policy on how AI-generated code is reviewed, tracked, and audited? Is that policy written down and enforced, or is it informal?
- Uses software that processes customer or employee data. If a data breach or security incident in that software is traced to ungoverned AI-generated code, the governance gap becomes a compliance question, not just a technical one.
The productivity gains are real — the governance gap is where the risk lives
To be clear: the Black Duck study confirms that AI coding tools deliver real value. Eight hours returned per developer per week is a material productivity gain. Faster releases. Better output. The 97% adoption rate reflects genuine utility, not hype. The governance gap does not mean businesses should stop their developers using AI coding tools — it means they should ensure the adoption comes with appropriate oversight structures in place, not just speed.
What UK operators with dev teams or tech suppliers should do
If you have an in-house dev team: Ask your technical lead whether there is a written policy on AI coding tools. If the answer is "developers can use them" without additional structure, that is the 70% case. A minimal policy covers: which tools are approved, how AI-generated code is flagged in pull requests, and what additional review steps apply to AI-generated security-relevant code (authentication, data handling, API access).
If you commission software from agencies: Add an AI governance question to your supplier qualification process. Ask whether the agency tracks AI-generated code in its deliverables, what its code review process covers for AI output, and whether it carries appropriate professional indemnity for software defects. This is not adversarial — most good agencies will have a policy. The ones who do not are the risk.
If you buy off-the-shelf software: Check whether your software vendors publish anything about their AI-assisted development practices and security posture. Established vendors (Microsoft, Google, Salesforce) have published AI coding policies. Smaller SaaS vendors are less consistent.
The key principle: AI coding adoption is not a risk — ungoverned AI coding adoption is. The 30% with a fully governed approach are the right benchmark. If your team or suppliers are in the 70%, start with a one-page policy, not a 50-page framework.