Definition · updated 31 October 2026
What Is Dark Code?
Dark Code is 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 to production, while nobody responsible for it can say why it does what it does. The term comes from the book Dark Code: The Software Architects Guide To Traveling At The Speed Of AI by Tony Griffith (2026), which defines it, explains why it is a new category of management risk, and sets out how to govern it.
The definition, in the book’s words
Dark Code is functioning software created by Ai that passes tests and appears to meet requirements, but whose internal logic and intent are not reliably recoverable by the humans responsible for operating it. It is opaque by nature. It is the product of a black-box generation process that produces an artifact humans may be able to run without fully being able to explain.
Dark Code, Chapter 1: The Definition
The definition has three parts. Code is dark when the humans deploying it do not possess one or more of these:
Its reasoning
Why the algorithm chose this strategy over that one. With generated code there is often no “why” to recover: the thought process dissolved into the probabilistic weights of a neural network.
Its authorship path
Who asked for it, with which prompt and context, who approved it and how it reached production: the chain of custody.
Its implementation logic
How it actually works, line by line, at a volume no reviewer can read: inspection stops scaling long before generation does.
The word that matters is possessed. Dark Code can be useful, elegant and correct. What is missing is human ownership of how and why it works.
Dark Code is not technical debt
The most common mistake engineering leaders make, the book argues, is to file the risks of AI-generated code under “technical debt”. That is a category error, and it leads to the wrong governance.
| Technical debt | Dark Code | |
|---|---|---|
| How it arises | A deliberate trade-off: ship by Friday, refactor next month | Generated by a probabilistic engine, often faster than anyone can read it |
| What the team knows | Where the debt lives and what it costs; the author is usually still in the building | The code exists, but the intent behind it is obscured or was never recorded |
| Code quality | Usually visibly poor: shortcuts, TODOs, hard-coded values | Often elegant: it looks like professional code, which is part of the danger |
| How you pay it off | Refactoring | Refactoring assumes an understanding the code obscures; you govern it with intent, verification, runtime evidence and provenance |
| The book’s metaphor | A mortgage you took out to buy a house | A mysterious, fully furnished mansion in the forest that you moved into |
Dark Code is not dead code, and not a code theme
Dead code is code that never runs. Dark Code runs every day, in production. Older code can be dark too: the Dark Code Risk Calculator counts four sources of it: AI-generated code, legacy undocumented code, third-party vendored code and orphaned code with no owner. AI is simply the source that is growing fastest. The name is also used for unrelated things, such as a dark syntax-highlighting theme for WordPress, the Dark programming language and several thriller novels; none of them is about this subject.
Related: comprehension debt
Addy Osmani has described comprehension debt: the growing gap between how much code a team ships and how much of it the team understands. Dark Code is what that gap contains, and the book is about governing it rather than only measuring it.
How others define Dark Code
The term surfaced in 2026 from several directions at once. Each definition below captures one side of the problem; the book’s definition covers reasoning, authorship path and implementation logic together.
| Who | Their definition | Focus |
|---|---|---|
| Jouke Waleson 19 March 2026 | “lines of software that no human has written, read or even reviewed” | Authorship and review |
| Sarah Guo 1 April 2026 | “behavior in production that nobody can explain end-to-end” | Runtime behaviour |
| Nate B. Jones 13 April 2026 | “code that was never understood by anyone at any point in its lifecycle” | Comprehension |
| Upsun 14 July 2026 | “code that compiles, passes review, and reaches production with no auditable record of why it was written” | Provenance and intent |
| Dark Code, Tony Griffith book, first edition 2026 | “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” | Reasoning, authorship path and implementation logic |
Quotes from the linked pages as published; dates are their publication dates. As far as we could find in October 2026, Dark Code is the only book devoted to the subject.
Signs you are already living with Dark Code
- Green Paradox: The false confidence created when builds, tests, or lint checks pass even though the underlying system may still be semantically wrong or unsafe.
- Illusion of Familiarity: The false sense that code is understood merely because it looks like familiar software patterns or resembles human-written structure.
- Illusion of Competence: The mistaken belief that a system is reliable because it produces polished outputs, even when its actual reasoning or correctness is weak.
- Syntactic Mimicry: The production of code that looks structurally correct and familiar while still missing the intended semantics or real-world correctness.
- Rubber Stamping: Superficial approval that preserves the ritual of review without supplying real scrutiny or evidence.
- Semantic Drift: The gradual movement of generated output away from the intended meaning, constraints, or domain logic over time.
- Configuration Drift: The silent divergence of environments, settings, or dependencies that causes systems to behave differently from what teams think they deployed.
- Shadow Prompting: Unapproved or hidden prompt usage that bypasses formal governance, review, or traceability.
Why it matters now
For decades the industry ran on one axiom: to ensure quality, inspect the code. AI generation breaks that axiom as a sufficient default control. The volume and velocity of generated code make line-by-line inspection impossible as a routine in many environments, and its alien logic makes inspection a weak primary control. Applying traditional review to Dark Code as the main safety system is often theater rather than quality assurance. The book’s answer is verification over inspection.
How to govern Dark Code
Dark Code is not a temporary anomaly to be wished away. It is a new operating environment for software delivery, and the book governs it with five layers that only work together:
- 01
Intent
Prompts become architectural artifacts: version-controlled, peer-reviewed and standardized, so you know why the code was written even when you did not write it.
- 02
Generation
A "constitution" for the codebase (a system prompt with security protocols, architectural patterns and performance constraints) and code that leaves breadcrumbs and "why" comments.
- 03
Verification
Property-based and contract testing instead of the vanity metric of coverage. The AI is treated as a brilliant but untrusted vendor that must honour the contract.
- 04
Runtime
Runtime truth resides in execution: pervasive telemetry, distributed tracing and anomaly detection show exactly where the code broke.
- 05
Provenance
Prompt history, the prompt audit trail and versioned intent records explain how a behaviour entered the repository in the first place.
“Dark Code is governed the same way at every scale: by making intent explicit, verification non-optional, runtime visible, and responsibility unmistakably human.”
More answers: Dark Code questions and answers · every term: the Dark Code Glossary.
The book
Read the book
Dark Code is the field guide for engineering leaders who will be accountable for systems they did not fully author line by line.