The Dark Code Dilemma

Something fundamental has shifted in how software gets built. AI is no longer just assisting developers in small ways. It is generating meaningful portions of production code across most organizations. GitHub reported that more than 97 percent of developers have used AI coding tools, and DORA’s 2025 research shows roughly 90 percent of technology professionals now use AI in their daily work. That level of adoption means AI-generated code is no longer the exception. It is becoming part of the baseline for system creation.

The part most organizations have not adjusted to is what that implies. When a significant portion of your system is being generated rather than written line by line, the responsibility to understand that system does not go away. It becomes more important.

Enter the inevitable industry crisis

The problem is not that AI generates imperfect code. The problem is that teams are not consistently reviewing that code deeply enough to check and understand it. In many cases, review has shifted toward confirming that the code "works" rather than understanding "how and why" it works.

Industry reporting on software supply chain practices shows that while AI-generated code adoption has surged to over 90 percent of organizations, only about 12 percent apply the same level of security rigor to AI-generated code as they do to traditionally human-written code. A small but meaningful percentage of teams admit to doing little or no auditing or code verification.

That gap matters because code can look fine in a pull request and still carry risk nobody has really uncovered. It may run, pass tests, and solve the immediate problem, yet remain brittle, insecure, or difficult to change later.

When the review focuses on whether the code works right now rather than whether people truly understand it, the organization starts accumulating software it depends on but cannot confidently explain how it works or maintain it. Let that sink in... Code that nobody can confidently explain or maintain. How risky is that?

This is how dark code forms

Dark code is not broken code. It is code that runs in production but is only partially understood by the people responsible for it. It gets there in a very predictable way. AI generates working output. A developer superficially checks that it solves the immediate problem. It gets merged into the system. At no point does anyone fully unpack the design choices, edge cases, or long-term implications of what just entered a production baseline.

Over time, those decisions accumulate. Systems grow, but the shared understanding of those systems does not grow at the same rate. That is when teams start to feel it. Certain parts of the system become harder to explain, harder to change, and quietly avoided.

The danger signals are already showing up

This is not just a theoretical concern. The data is already pointing in a consistent direction. Veracode’s 2025 research found that roughly 45 percent of AI-generated code samples failed security checks and included known vulnerability patterns.

Academic studies examining thousands of AI-attributed code files in public repositories have identified thousands of weaknesses across dozens of vulnerability categories, many of which persist in the codebase over time rather than being quickly corrected.

The important detail is not just that issues exist. It is that they persist. That persistence suggests teams are not fully seeing or understanding what has been introduced into their systems, which is exactly what you would expect if code and design reviews are shallow.

The risk is not as simple as a bug... It is much larger

The impact is not limited to application defects. It shows up in areas that directly affect business risk and longevity. GitGuardian reported that nearly 29 million secrets were exposed in public repositories in 2025, with AI-assisted development contributing to increased leakage patterns. A large percentage of those secrets remain active long after exposure, which indicates they are not being detected or remediated quickly.

Anthropic, ironically, a leading AI company, offered a sharp example of how this kind of risk can surface in practice when it accidentally exposed "the full source code" for Claude Code in March 2026 by shipping a source map file in a public npm package update. Reports indicated roughly 512,000 lines of code were exposed. It was not a sophisticated breach. It was a release mistake, which is exactly the point. As development speeds up with AI, basic lack in review, packaging, and release discipline can create real exposure without anyone breaking in.

This is where the problem moves beyond engineering hygiene. When organizations cannot fully trace what has been introduced into their systems or where sensitive data may have been exposed, they lose visibility, control, and trust. That is not just technical debt. That is an operational and security risk, like something we have not seen in our industry before.

Speed is the problem

One reason this issue is not getting more attention is that AI is clearly improving short-term productivity. DORA’s research shows that more than 80 percent of developers believe AI has made them faster. That is real. Teams are shipping more, and doing so more quickly.

But speed is masking the tradeoff. Organizations are increasing output without increasing understanding or governance. That works until something needs to change, scale, or be fixed under pressure. At that point, the missing understanding shows up as a blank face with no clue as to how or why our system broke. That is a CTO nightmare.

Accountability belongs to humans

Some of the strongest signals that this is a real issue are coming from disciplined engineering communities. The Linux kernel community has begun requiring explicit disclosure of AI-assisted contributions while holding humans fully accountable for the code they submit. That move reflects a clear recognition that AI changes authorship, but it does not remove responsibility.

The implication is simple. If a human cannot explain the code, they should not be shipping or contributing it. I am glad to see this being embraced by open source teams and companies.

What companies need to understand and change

Organizations do not need to slow down AI adoption, but they do need to change how they define completion. If AI is generating more of the system, then the review needs to shift from merely verifying behavior to also establishing an understanding of the code base. Teams need to know how the code works, what risks it introduces, and how it can be safely changed. They also need stronger practices around provenance, security scanning, and ownership so that generated code is not treated as inherently trustworthy. After all, AI systems are always confidently wrong until called out.

Without that shift, companies are not just moving faster. They are accumulating complexity and risk faster than they can manage it. Perhaps we need a dark code metric?

Closing thoughts... Well, more of a warning

This is the warning embedded in many AI transformation efforts right now. Leaders are seeing faster output and assuming they can reduce engineering capacity before they have built the disciplines needed to govern AI-generated code.

That is backward. If human understanding is already lagging behind machine-generated output, cutting staff only widens the gap. It removes the people who provide review, context, architectural judgment, and recovery when things go wrong. Before any organization turns AI productivity into a workforce reduction story, it should first prove it can still understand, secure, and safely evolve what it is building. Otherwise, the transformation is not reducing risk or building capability. It is stripping out the human judgment needed to govern what is being built and replacing it with a larger, more dangerous blind spot.