The 67-point gap: who carries the risk when 97% of developers code with AI and 30% have rules for it

Black Duck's June survey reports that 97% of enterprise development teams now use AI coding tools, while only 30% have full governance in place for that use. The 67-percentage-point gap between adoption and oversight is not a transitional lag. It is a redistribution of risk from the firm to the developer, and from the developer to the open-source ecosystem upstream.

The headline that isn't the story. The 97% number is the kind of figure that gets framed as inevitability — this is just how software is built now. The more interesting figure is the one underneath it. Seventy per cent of development teams are using these tools without the policy, audit, and oversight structures that would normally accompany a production tool with this much surface area into proprietary code, third-party licences, and customer data.¹

That 70% is doing real work under real deadlines. They are pasting code into models, accepting completions, shipping the output. The governance that would tell them what they can paste, what gets logged, what counts as an audit trail, and who is liable when an AI-generated function turns out to contain a GPL-licensed fragment lifted from training data — that governance is, for most of them, not there yet.

Who actually carries the risk. The Law and Economics Center's review of the empirical evidence on AI coding tools is useful here, because it is not written from a labour perspective. It finds that the productivity gains are real, Peng and colleagues measured a 55% speed-up on assisted tasks, and that those gains accrue primarily to firm throughput. The review also finds limited evidence that the gains translate into wages for individual developers.²

So the firm gets the throughput. What does the developer get? In the best case, a tool they prefer using and eight hours back in their week. In the worse case, which is the case 70% of teams are currently operating in, they get personal exposure to a set of risks that have not been formally assigned to anyone. If an engineer at a bank pastes a snippet of proprietary risk-model code into a public model endpoint to debug it, and that snippet shows up in someone else's completion six months later, the question of whose fault that is has not been answered inside most organisations. The absence of a policy does not mean the absence of a consequence; it means the consequence will land wherever the org chart lets it land, which is rarely upward.

The junior tier is thinning. The other number worth holding next to the 97% is Stanford's finding that entry-level developer hiring fell by roughly 20% between 2023 and early 2026, with AI tool adoption cited as a meaningful driver alongside the post-ZIRP correction.³ Attribution is contested and I want to be honest about that — some of this is cyclical. But the direction is consistent across reports, and the mechanism is intuitive. If a mid-level engineer with Copilot can do the work that two engineers used to do, the role that gets cut is the one that was being trained on the job.

This matters beyond the immediate labour story. Junior developer roles are how the industry has historically produced its mid-career and senior engineers — the same engineers who, in the governance models being built now, are supposed to review AI-generated code, catch the security defects that two-thirds of teams say they are moderately or extremely concerned about, and decide what gets shipped.¹ The tool that is shrinking the apprenticeship tier is the same tool that, used safely, requires more experienced human oversight, not less. That is not a contradiction the market resolves on its own.

The 97% probably isn't 97%. I want to push on the adoption number, because the governance number depends on it. Survey methodology in this space typically counts an organisation as having "adopted" AI coding tools if any meaningful number of developers are using them. That is a different claim from "this organisation has integrated AI tooling into its production development pipeline with controls". If adoption is being measured loosely, "full governance" is almost certainly being measured loosely too. The 30% figure may be optimistic about what counts as oversight in practice. The real gap could be wider.

The market is building governance, for the firm. The counter-argument, which I take seriously, is that enterprise security has always worked this way. Tools arrive, point solutions follow, formal policy lags by years, and the gap closes eventually. Silverfort's identity controls inside Microsoft Copilot Studio and the push to enforce Zero Trust (a security model that requires continuous verification of every user and request) at the hardware layer for AI agents are real responses to a real problem, and they are arriving faster than any regulator would.¹

The honest question is what those point solutions protect. Identity controls and hardware-layer enforcement protect the firm from liability and from the worst data-exfiltration scenarios. They do not, on their own, protect the developer who has been using an enterprise tool for two years without a written policy on what code they were allowed to submit, and who finds themselves on the wrong end of an IP investigation when something surfaces. They do not protect the open-source contributor whose permissively-licensed code is being used to generate completions that downstream firms ship without attribution. Governance for the firm is not the same thing as governance for everyone the tool touches.

What to watch. Three things. First, whether the 30% governance figure improves materially over the next year, and whether the improvement is in formal policy or only in vendor tooling. Second, whether the entry-level hiring decline reverses as the cyclical correction works through, or whether it sets a new baseline. Third, and this is the one most likely to be invisible until it isn't, whether the first wave of disputes over AI-generated code in production lands on individual developers or on the firms that deployed the tools without telling them what the rules were.

A 67-point gap between adoption and governance is not a number that closes on its own. It closes through specific decisions about who is responsible for what. Right now, in most organisations, those decisions have not been made. That is not the same as the risk not existing.

Footnotes

¶