Sixty-seven percent of developers believe AI-generated code requires more testing than code written by humans. Their organizations haven't built that testing process.
Info-Tech Research Group published a study last month examining how engineering and product leaders are using AI across the software development lifecycle. The headline was the familiar one: 94% of developers report AI productivity gains. The finding that didn't make the headline was more revealing: governance maturity lags significantly behind adoption. No standard operating procedures. No production-readiness criteria specific to AI output. No review requirements that account for the known failure modes of code generated by large language models.
The Black Duck 2026 Open Source Security and Risk Analysis report shows what happens when adoption outruns governance. Mean vulnerabilities per codebase increased 107% year over year — from 280 to 581 known vulnerabilities per application. Eighty-seven percent of audited applications contained at least one known vulnerability. Black Duck identified the rise of AI coding assistants as a contributing driver: more code, generated faster, with infrastructure to evaluate that code not keeping pace.
Only 24% of organizations perform comprehensive IP, license, security, and quality evaluations for AI-generated code. Seventy-six percent don't.
Where the Gap Actually Lands
The governance gap gets reported as an organizational problem. For the developers on the ground, it's a personal one.
You are using AI tools your organization mandated or strongly encouraged. You know — 67% of your peers know — that the output needs more scrutiny than human-written code. But when you sit down to build a feature, there's no institutional checklist waiting for you. No team process for AI code review that differs from human code review. No tooling that flags "this function was written by Cursor, and you should check it against these known LLM failure modes."
What there is: the commit log with your name on it.
The accountability structure hasn't moved. Your organization adopted the tools and handed you the productivity gains, but the responsibility for what ships under your name is exactly where it was before. The 107% increase in vulnerabilities per codebase doesn't get attributed to "AI coding tools." It gets attributed to the developers who committed that code.
This isn't a critique of AI tools specifically. It's a description of where 2026 actually is: the adoption phase is over for most engineering organizations, the governance phase hasn't started, and individual developers are absorbing the gap.
What That Invisible Work Looks Like
When you generate a function with Cursor and commit it after a quick glance, the time-tracking data shows coding time. When you generate a function, read it carefully, run it through your mental model, open the documentation for the library it calls, check whether the edge case on line 12 is actually handled — and then commit it — that's also "coding time" in the data. Same application open. Completely different cognitive work.
The Sonar Source 2026 State of Code survey found that 96% of developers don't fully trust AI-generated code. Only 48% always verify it before committing. The 52% who skip verification aren't being reckless in most cases. They're operating under time pressure in an environment where organizational guardrails don't exist. The verification that should happen at the team level — as a systematic practice with agreed standards — instead happens sporadically at the individual level, on an ad-hoc basis, at individual cognitive cost.
Info-Tech found that 38% of developers report reviewing AI code requires more effort than reviewing code written by human colleagues. That tracks with what the code quality research shows: AI-generated code tends toward redundancy, missed reuse opportunities, and solutions that satisfy the stated requirement while missing implicit constraints. The mental overhead of catching these isn't lower than human code review — it's often higher, because the code is frequently cleaner on the surface than what a junior developer would write, which makes its failure modes less visible.
When you're doing this verification carefully, you're absorbing organizational governance debt personally. The work is real. It doesn't show up in standard productivity metrics. It shows up in your time data, if you're capturing it at the right granularity.
The Metric That Would Help Doesn't Exist
Info-Tech's study recommended that software leaders start tracking defects by generation method — separating AI-generated bugs from human-generated bugs — as a basic step toward understanding what AI code costs downstream. Almost no organization does this. Which means individual developers also have no signal about whether their AI code is actually performing differently from their human-written code over time.
This is the complete measurement vacuum. Organizations aren't tracking AI code quality separately. Developers don't have organizational data to calibrate against. The result is that tooling decisions, verification habits, and AI usage patterns are being set by intuition — and developer intuition about AI quality, as METR's controlled trials and multiple self-report studies have documented, is systematically miscalibrated in the optimistic direction.
The 54% of developers who told Harness they fear AI productivity data being used in performance evaluations are worried about being measured on the wrong thing. What's less discussed is the flip side: the data that would actually help — AI code failure rate, verification time per session, post-merge stability by generation method — isn't being collected by anyone.
What Your Own Data Shows
There is one place where the invisible work surfaces: system-level usage data, if you're collecting it.
A verification session looks different from a generation session at the behavioral level. Cursor → browser (docs) → Cursor → terminal (test run) → Cursor → browser (Stack Overflow) → Cursor → commit is a verification session. Cursor → commit is not. Both register as the same "coding time" in editor-based heartbeat trackers. At the system level, the first session is longer, involves more context switches, and touches more applications.
That pattern, tracked over weeks, starts to tell you something. How much of your "coding time" is verification time? Does heavier verification correlate with fewer follow-up bugs? Do the projects where you skip verification show up later as problem sources? Does your verification overhead vary by type of task — greenfield versus legacy code, new features versus bug fixes?
Your organization isn't measuring any of this. Info-Tech published their recommendations for what leaders should do in July and described the starting point — define what "production-ready" means for AI code, establish review expectations, track defects by generation method — as a goal most organizations haven't reached. Given the adoption numbers (94% using AI in the build phase) versus the governance numbers (24% doing comprehensive evaluation), the gap will be absorbed at someone's desk for the foreseeable future.
The measurement infrastructure to close it exists at the personal level before it exists at the organizational level. Whether you're collecting data on your own verification patterns, your AI code failure rate, and how those correlate with the downstream quality of what you ship — that's what determines whether you're flying blind or navigating with at least some instrument data in an environment where your organization has none.
The governance vacuum won't stay empty. It gets filled either by individual developers developing personal discipline, or by incidents that eventually force organizational response. The data you could be collecting now is a lot cheaper than the second path.