DARK CODE

Software whose behavior may be operationally useful but whose full internal reasoning, authorship path, or implementation logic is not directly possessed by the humans deploying it. In practice it is AI-generated code that works, passes its tests and ships, while nobody responsible for it can explain why it does what it does. The full definition.

Nobody owns it. It surfaced in 2026 from several people at once: Jouke Waleson wrote about it on 19 March 2026, Sarah Guo on 1 April 2026, and others followed. Tony Griffith’s book Dark Code (copyright 1 March 2026) gives it a precise definition and a full governance framework. How the definitions compare.

No. Technical debt is a known trade-off: the team knows where it lives and how to pay it off by refactoring. Dark Code is code whose intent is obscured; you cannot refactor what you do not understand. The book calls treating it as technical debt “a category error that leads to disastrous governance strategies”.

It is not dead code: dead code never runs, Dark Code runs in production. Legacy code can be dark when it has no documentation and no owner, which is why the Dark Code Risk Calculator counts legacy, vendored and orphaned code alongside AI-generated code.

Not necessarily. The book insists we must dispel the notion that AI generates weak or novice code. Dark Code is often elegant and passes every test. The risk is not quality you can see but understanding you do not have.

Line-by-line review cannot keep up with generation, and as a default ritual it often becomes rubber stamping. The book argues for verification over inspection: approval rests on behavioural evidence and independent testing, with selective inspection where risk, failure or regulation justify reading the code.

Define the contract before generation (contract-first generation), then verify behaviour: contract testing, property-based testing with thousands of randomized inputs, and behavioural validation. Scale the depth of control with risk (governed asymmetry): billing, authentication and data-integrity changes do not ship on hope alone.

Not on their own. Passing builds and tests can create the Green Paradox: false confidence while the system is still semantically wrong. The book defines verification as independent proof that a system behaves correctly enough for its intended use and risk level.

As support, yes: a Guardian AI can check another system’s output, a Watchdog AI can watch runtime signals for anomalies, and consensus checking compares several model analyses. None of these replaces human accountability.

With provenance: code labels on generated code, a ledger of intents, a prompt audit trail and a documented chain of custody showing who requested, approved, generated, modified and shipped each change.

Humans. The book’s closing principle is that responsibility stays “unmistakably human”. Intellectual ownership means understanding the purpose, risk and operational consequences of a system even when much of its code was generated.

Five layers that work only together: Intent, Generation, Verification, Runtime and Provenance. Intent tells you what should happen, verification what was admitted, runtime what actually happened and provenance how that reality was produced.

A proposed structured record that explains what an AI-generated change was meant to do, under what constraints it was created, and how that intent should be reviewed. It belongs to intent-based engineering, where reviewed intent, not raw implementation, is the main control surface.

Estimate it with the free Dark Code Risk Calculator: enter your team size, monthly lines of code, review coverage and the share of AI-generated, legacy, vendored and orphaned code, and it estimates your monthly dark code, its cost and a risk score.

Yes. At enterprise scale the principles become context managers, prompt gatekeepers, compliance workflows and tiered approvals. At small scale they may live in a prompt library, a deployment checklist, a rollback plan and a personal rule that critical changes do not ship on hope alone. The pattern does not change; only the weight of the machinery does.

Engineering leaders, CTOs, architects and senior technical operators who will be accountable for systems they did not fully author line by line. It is not primarily a prompt-writing handbook; it is about governance, architecture and operational discipline.

The eBook (PDF, 158 pages) is $19.99 on this site, with immediate access. The paperback is sold by Blurb: Dark Code on Blurb. Because the eBook is a digital product, refunds are handled case by case within 7 days through the contact form.