Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Does AI coding increase technical debt?
Updated
Evidence on AI-assisted coding and technical debt is mixed and mostly correlational: higher short-term output can raise churn and rework unless you measure debt, enforce review, and pair speed with quality gates. This page is not legal advice.
AI coding and technical debt, last verified 10 September 2026 against the 2024 DORA / State of DevOps Report (Google Cloud, 2024), GitClear 2024 code-churn methodology (lines changed within 14 days of authorship), SEI technical-debt literature (CMU SEI, ongoing), and Accelerate (Forsgren, Humble, Kim, 2018). Vendor and observational claims are labelled by kind. Not legal advice.
Audience and what this page does not claim
Audience: a CTO, engineering leader, or founder weighing AI coding tools against long-term maintainability. This page is engineering guidance distilled from published research and industry frameworks. It is not legal advice. It does not determine that any tool is safe, compliant, or fit for YOUR context.
The question is not whether AI writes code — it is whether YOUR organisation's practices convert AI-assisted velocity into durable software or into deferred rework. That outcome depends on review depth, architecture guardrails, and how you measure debt — not on the editor brand alone.
What the evidence says — with methodology and recency caveats
Published evidence on AI-assisted development and code quality is recent, vendor-influenced in places, and rarely causal. Treat every figure as context-bound to the study's population, tool version, and measurement window. Last verified 10 September 2026. Not legal advice.
Correlation is not causation. Teams that adopt AI assistants often also change branch strategy, review rules, or staffing at the same time. A rise in churn or defect rate after adoption does not prove the assistant caused it — and a flat defect rate does not prove the assistant is harmless if review load shifted off-metric.
- Do not quote a single vendor blog percentage as an industry fact. If a number is not in a cited primary source with stated methodology, omit it from YOUR board pack.
- Short-term line volume is a poor debt proxy. Debt shows up in change-failure rate, incident recurrence, time-to-understand, and the cost to modify a module safely.
- The measure-technical-debt guide on this site is the companion page for instrumentation. The measure-ai-generated-code-risk guide on this site covers risk framing for AI-authored changes.
| Source | What it measured | Methodology caveat | Correlation vs causation | Recency |
|---|---|---|---|---|
| 2024 DORA / State of DevOps Report (Google Cloud, published 2024) | Organisational outcomes including delivery throughput, stability, and platform practices among surveyed teams. | Cross-sectional survey and metrics aggregation across respondents; self-reported and platform-derived signals vary by participant. | Associates practices with outcomes; does not isolate AI tooling as a controlled independent variable in a randomised trial. | 2024 edition — check for newer annual releases before citing as current. |
| GitClear 2024 code-churn analysis (public methodology) | Share of lines changed within 14 days of authorship — a proxy for rework, not a full debt ledger. | Repository-mining across open and customer repos; churn definition is time-boxed line edits, not semantic duplication or architectural drift. | Temporal association between AI-adoption periods and churn movement; causation not established. | 2024 publication window — methodology page should be re-read if GitClear updates definitions. |
| Peer-reviewed churn and change-failure literature (e.g. work citing change-failure rate and rework) | Relationship between change volume, review practices, and defect escape. | Peer review helps but populations and definitions differ by paper; do not merge results into a single headline percentage. | Establishes that high change rates without quality gates correlate with rework; AI assistance is a recent confounder not always in older cohorts. | Varies by paper — cite the specific study when you use it internally. |
| SEI technical-debt literature (CMU Software Engineering Institute) | Technical debt as deliberate shortcuts with measurable future cost — architecture, test, and documentation gaps. | Conceptual and case-study framing; not a single universal debt score for AI-generated code. | Describes mechanisms (e.g. missing tests, tacit knowledge) that AI suggestions can accelerate if unchecked; not an AI-specific causal study. | Ongoing SEI corpus — last verified 10 September 2026 at sei.cmu.edu technical-debt materials. |
| Accelerate (Forsgren, Humble, Kim, 2018) | High-performing organisations balance speed with stability via culture, architecture, and continuous delivery. | Book synthesises prior DORA research; pre-dates widespread generative AI pair programmers. | Causal claims are about capabilities and culture, not AI tools; still the baseline for 'speed without stability is fragile'. | 2018 — principles remain; AI-specific evidence must be layered on, not inferred from the book alone. |
Mechanisms — how AI assistance can add debt without malice
AI assistants propose locally plausible patches. Without architectural context they can duplicate utilities, skip edge cases, weaken typing, or import dependencies YOU would not have chosen. That is not unique to AI — junior contributors do the same — but AI lowers the cost of producing the first draft.
Debt compounds when suggestions merge without tests, without ownership assignment, or without updating docs and runbooks. The SEI framing treats debt as a trade-off that must be visible and repaid; hiding it behind green CI is still debt.
- Duplication: similar helpers across services because the model does not see YOUR whole repo unless retrieval is wired.
- Churn: rapid accept-and-ship cycles that GitClear-style metrics flag as lines rewritten within days.
- Dependency drift: suggested packages that are popular but unmaintained, typosquatted, or incompatible with YOUR licence policy.
- Test gaps: generated code paths without matching unit or contract tests.
- Tacit-knowledge loss: reviewers skim AI output assuming 'the tool checked it'.
Standard practice vs industry best practice vs SRM recommendation
The table labels each control. SDLC security and engineering standards are what mature teams already do; best practice is what high-performing organisations add for AI-assisted workflows; SRM recommendation is how this product surfaces signals — not an industry standard or audit opinion.
| Practice | Kind of guidance | What it does |
|---|---|---|
| Code review on every merge to protected branches | Standard SDLC | Human gate on correctness, security, and fit. |
| Definition of done includes tests and docs for non-trivial changes | Standard SDLC | Prevents untested AI drafts from becoming permanent surface area. |
| Track DORA metrics (lead time, deployment frequency, change-failure rate, MTTR) | Industry best practice — DORA / Accelerate lineage | Balances speed with stability; flags when velocity rises but failures follow. |
| Measure debt proxies: churn, duplication, coverage, and change-failure on AI-touched files | Industry best practice | Makes debt visible before architecture review backlog explodes. |
| Pair AI ROI inputs with engineering risk score and delivery health | SRM recommendation — vendor methodology | Composite estimate, not audited financials; coverage-as-confidence honesty. |
Practices checklist to contain AI-driven debt
Use this as an operating checklist, not a certification. Walk it with YOUR engineering leadership. Not legal advice.
- Define what counts as technical debt in YOUR context (SEI-style: deliberate shortcuts with tracked repayment).
- Instrument churn and change-failure rate on branches or paths where AI assistance is common — compare to baseline, not to a fabricated industry average.
- Require tests for generated logic before merge; block on coverage regression where policy demands it.
- Run duplication and dependency analysis on AI-touched modules; reject typosquatted or unapproved packages.
- Cap unreviewed AI suggestion volume per PR; large agent diffs need architecture review.
- Document ownership: every merged AI-assisted module has a named maintainer in CODEOWNERS or equivalent.
- Schedule debt repayment sprints when debt proxies trend up while deployment frequency also rises.
- Re-read DORA annual findings when published; do not treat a 2024 snapshot as eternal.
What you need to do now
As of last verification on 10 September 2026, no primary source offers a causal, organisation-agnostic proof that AI coding always increases or decreases debt. Act on mechanisms and measurement instead of slogans.
- Baseline YOUR churn, change-failure rate, and lead time before expanding AI seat count.
- Adopt the measure-technical-debt guide on this site for debt instrumentation; the measure-ai-coding-roi guide on this site for pairing cost with throughput.
- Treat GitClear-style churn and DORA stability metrics as correlates — investigate when they move together.
- Keep human review non-negotiable on auth, payments, crypto, and data-handling paths regardless of assistant confidence.
- Record which tools and models are approved; the ai-coding-governance-checklist guide on this site is the governance companion.
Checklist
Question list for CTOs and engineering leaders. Not legal advice. Not an audit checklist.
- Have we baselined debt proxies (churn, change-failure, duplication) before scaling AI assistance?
- Do we distinguish correlation (metrics moved together) from causation (tool caused the move)?
- Is every AI-assisted merge reviewed by someone who understands the subsystem?
- Do definition-of-done rules require tests for generated logic?
- Are dependency and licence policies enforced on suggested imports?
- Do we track repayment work when debt proxies rise?
- Have we read the latest DORA / State of DevOps edition rather than a stale slide?
Where this shows up in ShipReady Metrics
Signed-in Delivery Health uses DORA-style signals from connected CI and deploy sources; gaps show as Not measured rather than fabricated green.
AI ROI scoring pairs admin-entered cost inputs with throughput signals; figures are estimates, not audited financials. Trial AI-ROI entitlement exists; per-team views respect cohort minimums.
Engineering risk score is a composite vendor methodology — not an industry standard, not a debt ledger, not legal advice.
AI-authored-code floor counts git-marker or attributed-AI commits in the signed-in AI Code Readiness report — a provenance signal, not a classifier that proves authorship with certainty.
This product does not certify low debt, does not replace architecture review, and does not determine legal or regulatory compliance.
Primary sources (last verified 10 September 2026)
Every research claim on this page traces to one of these or is labelled vendor commentary. Re-check publication dates before board use. Not legal advice.
2024 DORA / State of DevOps Report (Google Cloud, 2024). GitClear public churn methodology (2024). CMU SEI technical-debt publications. Accelerate (Forsgren, Humble, Kim, IT Revolution, 2018). Peer-reviewed software-engineering churn and defect literature as cited in YOUR internal reading list — this page does not invent merged percentages.
The measure-technical-debt guide on this site is live. The measure-ai-generated-code-risk guide on this site is live. The measure-ai-coding-roi guide on this site is live. The technical-debt glossary on this site is live. The dora-metrics glossary on this site is live.
Frequently asked questions
Does AI coding always increase technical debt?
No primary source proves that as a universal causal law. Observational work and churn analyses report mixed associations whose direction depends on review depth, testing, and architecture guardrails. Treat adoption as a change programme you measure, not a fate.
Can we use code-churn percentage from a vendor blog in our board deck?
Only if you cite the vendor's stated methodology, sample, and date — and you do not present correlation as causation. This page deliberately avoids inventing a single industry-wide churn percentage.
Does ShipReady Metrics measure technical debt directly?
No. It surfaces DORA stability signals, engineering risk score, AI ROI estimates, and AI-authored-code provenance floors. Those are inputs to YOUR debt conversation, not a SEI-certified debt balance or audit opinion.
Is this legal advice?
No. It is engineering guidance from published research and frameworks. Licensing, liability, and regulatory questions belong with counsel on YOUR facts.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.