The idea behind it
Technical debt is the future cost of shortcuts taken in code today. Ward Cunningham coined the term in 1992 to explain why code that works can still cost a team later. AI coding assistants create a specific form of it. They can produce code faster than a team can review, understand or test it. The code may pass its checks and still be code that no one on the team can explain, change safely or debug. Andrej Karpathy's term vibe coding, for accepting AI output without reading it closely, describes the habit that produces this debt.
Guardrails for AI-generated code apply familiar engineering controls with stricter rules for authorship. Review has to mean that a human can explain what the code does and what would break without it. Tests need a human check, because tests generated by the same assistant can confirm the implementation instead of the intended behavior. Each file needs a named owner, recorded in a CODEOWNERS file, the feature in GitHub and GitLab that assigns code to reviewers. Dependencies need vetting because assistants can suggest packages that are abandoned, vulnerable or do not exist, which attackers exploit by publishing malicious packages under those names. A regular debt review keeps the backlog visible.
What's inside
- Guardrail 1, review capacity: a ceiling of 40% AI-generated code per sprint as a starting point, human review of every AI-generated pull request, and reviewers who can explain the code.
- Guardrail 2, test coverage: the same coverage gate for all code, human review of AI-written tests, and merge blocking.
- Guardrail 3, ownership: a named owner for each AI-generated file, recorded in CODEOWNERS or equivalent, with documented transfers.
- Guardrail 4, periodic debt review: a quarterly review, a four-level risk classification and a share of each sprint for remediation.
- Guardrail 5, dependency vetting: vetting with the AI-Suggested Package Vetting Checklist, version pinning and vulnerability scanning in CI/CD.
- Each guardrail is marked Policy, Required or Recommended, with a status column.
- A one-page policy: effective date, owner, purpose, scope, five core principles, a summary table of each guardrail with its policy and enforcement, consequences and how to request an exception.
Format: PDF (4 pages) and Word document.
A look inside
Pages 1 and 2 of 4 of the PDF. Select an image to enlarge it.
Who uses it
- CTOs and VPs of engineering, to set team-wide rules for AI coding assistants before the debt builds up.
- Engineering managers, to run the quarterly debt review and protect sprint capacity for remediation.
- Tech leads and senior reviewers, to set the standard for what counts as a real review of AI-generated code.
- Platform and DevSecOps teams, to configure coverage gates, version pinning and dependency scanning in CI/CD.
When to use it
- A team rolls out an AI coding assistant or coding agent to all developers.
- Review queues grow faster than the team can clear them after AI adoption.
- An incident traces back to AI-generated code no one on the team could explain.
- A developer who generated much of a module leaves the team.
- An AI-suggested package turns out to be abandoned, vulnerable or malicious.
How to use it
Agree the thresholds with the team, adapt the policy summary, and check the guardrails at each quarterly debt review.
- Agree the review-capacity ceiling with the team; the file proposes no more than 40% of a sprint's merged lines as AI-generated. Every AI-generated pull request still gets human review.
- Go through the five guardrails and set the Status column for each row as In place, Not in place or In progress.
- Put the Required items in place first: human review by someone who can explain the code, the same coverage gate for all code, named owners in CODEOWNERS and pinned, scanned dependencies.
- Adapt the one-page policy, with its principles and the table of each guardrail's policy and enforcement, into your team's written policy.
- Hold the first quarterly debt review and classify AI-generated code as Critical, High, Medium or Low, based on how well it is understood and whether it sits in a critical path.
- Reserve at least 10% of each sprint for remediation, in the order the debt review sets.
- Track AI-generated code debt on the engineering health dashboard alongside change failure rate, lead time and restore time.
You leave with: An agreed set of team rules for AI-generated code, a status for each guardrail, and a policy summary that says how each rule is enforced.
Where it goes wrong
- Treating a quick approval as a review when the reviewer cannot explain the code.
- Letting the assistant write the tests for the code it generated, with no human check of what the tests cover.
- Leaving AI-generated files without a recorded owner, so they are orphaned when the author moves on.
- Allowing floating dependency versions such as "latest", which can pull in a malicious update.
Get the policy and checklist
It is free. Enter your work email and we send the download link.
Questions
Does AI-generated code create technical debt?
It can. Debt builds up when code is merged faster than the team can review, test and understand it. The risk is code that works today but that no one can explain, change or debug later.
How should a team review AI-generated code?
The reviewer should be able to explain what the code does, why, and what would break if it were removed. If they cannot after a reasonable effort, the code should be rewritten until it is understandable. Review must not be a quick approval.
Why do AI-suggested dependencies need vetting?
Coding assistants sometimes suggest packages that are abandoned, have known vulnerabilities or do not exist. Attackers publish malicious packages under names assistants tend to invent. Vet each package before merging, pin it to a specific version and scan dependencies in CI/CD.