Prompt debt is technical debt caused by unclear, sensitive or undocumented prompts that reduce reproducibility and degrade code quality. Faster Code, Deeper Debt? A Multivocal Literature Review on Technical Debt and Its Early Signs in LLM-Assisted Software Development identifies it as one of six debt categories emerging from LLM-assisted development that established technical debt taxonomies do not cover, and it is discussed in both literatures the review surveys — 8 formal sources and 5 grey ones.

The condition the term names is a mismatch in how two kinds of artefact are treated. Prompts directly shape generated implementations, which makes them consequential in the way source code is, yet the review reports they are often not preserved, versioned or maintained with the same rigour.

Usage

The review reports prompt debt as the primary source of LLM-specific debt in the formal literature. One study it draws on describes prompt debt as resulting from poorly structured, inefficient or suboptimal inputs to LLM systems, and finds instruction-based and few-shot prompts particularly vulnerable, because both depend on something fragile — instruction clarity in the first case, example quality in the second.

Practitioner accounts emphasise brittleness and traceability. Developers report prompt brittleness, where minor changes produce drastically different outputs — one source the review quotes describes small inconsistencies drifting into large-scale architectural entropy — alongside ambiguous instructions and a lack of prompt versioning. A further concern the review folds into this area is the constant need to determine the proper contextual information to include in a prompt.

The review also connects prompt debt to a knowledge-management problem it calls prompt sprawl: because prompts and interaction patterns increasingly function as development artefacts yet are often undocumented or scattered across tools and repositories, the result risks loss of system knowledge, weakened accountability and complicated collaboration.

When It Applies

Prompt debt accrues wherever prompts are load-bearing — that is, wherever the shape of shipped code depends on inputs that are not themselves under the controls applied to code. On the review’s account, what makes this a debt rather than a one-off cost is that prompts directly shape generated implementations yet are often not preserved, versioned or maintained with the rigour applied to source code.

Mitigations reported in the reviewed literature are correspondingly about making prompts durable and explicit: maintaining prompt templates to improve reproducibility and consistency, using structured prompts or explicit style and quality constraints to steer models toward more maintainable output, and segmenting LLM usage by clearly delineating when to use generative AI and when to code manually. At the organisational level the authors point to prompt registries, versioned documentation and review workflows for LLM inputs as ways of preserving organisational knowledge.

One reported result gives a sense of how much prompt quality can move: a study of Copilot-generated Python code found that well-structured and specific prompts mitigated up to 87.1% of the code smells observed. The review cautions more broadly, however, that prompt-based mitigation has limits — another study it cites combined prompt engineering and retrieval-augmented generation with an architectural debt detection tool and found the techniques improved results for smaller code debt cases while proving less effective for more complex issues.