Security and Maintainability Life-Cycles for AI-Generated Code

AI coding assistants changed the arrival rate of code, not the laws of software aging. A function that compiled in the IDE is still an asset you will patch, threat-model, and explain during an incident. The research and engineering gap is a life-cycle: how generated fragments are born, how they pick up vulnerabilities and duplication, how you detect that, and how you retire patterns the model keeps reproducing.

I do not treat “did Copilot write this” as a moral question. I treat it as an operations question. Mixed authorship is the default. The process has to survive that.

Who this is for

I wrote this for security and platform teams rolling out GitHub Copilot, Cursor, or in-house code models, for staff engineers watching duplication explode, and for researchers measuring long-term quality—not autocomplete accuracy. Teams in Lahore, across Pakistan, and remote-from-Pakistan often adopt assistants to close a headcount gap. That only works if review, SAST, and ownership scale with the extra diffs.

If you are a founder, token spend is not the cost of AI code. Incident and rewrite cost is. If you are a CISO, you need gates that do not depend on developers volunteering a “generated” label. If you are a developer, you need a policy that does not punish you for using the tool you were asked to use.

What actually goes wrong?

Recurring failure modes I see in review:

Outdated APIs and crypto. Models emit create_cipher patterns, weak random, or old JWT usage because that text is common.
Missing authorization. A CRUD handler that checks authentication and then loads any id.
Hallucinated packages. A dependency name that does not exist—or worse, exists as a typosquat after someone npm installs it.
Copy-paste clones. The same 40-line helper in twelve services, each slightly wrong.
Tests that assert mocks. Green CI, no behavior.

These are software-engineering defects with an AI arrival process. Detection has to be continuous, not a one-off audit after the copilot rollout blog post.

How do you track provenance without a witch hunt?

Ideal: the editor or CI records generated_ratio per hunk with user consent. Realistic: you get labels on some PRs and nothing on others.

Design for mixed:

policy:
  scan: all_diffs
  provenance: optional_label
  block_on:
    - secret_scan
    - sast_high
    - disallowed_dependency
    - missing_tests_on_new_exports
  warn_on:
    - clone_of_deprecated_snippet
    - sast_medium

Optional labels still help research and targeted education. They should not be the control. If the only files you SAST are labeled generated, people will stop labeling.

For organizations that can run internal models, log suggestion accept/reject. That dataset is how you find the patterns your developers keep accepting.

What automated mechanisms belong in the loop?

Diff-aware SAST and secret scan on every PR, including assistant-heavy ones.
Reachability. A CVE in a dependency the generated code actually imports, not a 900-page report.
Snippet fingerprinting. When you ban a vulnerable example (SQL string concat, a bad S3 ACL), hash variants and find them again next month. Models re-emit.
Clone detection (token or AST) with a budget: new clones of known-bad clusters fail CI; clones of healthy internal libraries get a review note.
License and package existence checks before lockfile merge.
Production mapping. Crash groups and error budgets tagged to the introducing SHA.

def reject_hallucinated_deps(added: set[str], registry: set[str]) -> list[str]:
    return sorted(added - registry)

That one function has saved more production pain than another prompt that says “write secure code.”

How does technical debt accumulate specifically from LLMs?

Debt here is not only Sonar issues. It is pattern debt: the assistant teaches a style that is locally fluent and globally inconsistent. Naming, error types, retry policy, and logging all drift.

Mitigations that work:

Golden paths in-repo: small internal libraries the model can copy. RAG-over-your-standards beats a 12-page markdown the model never sees.
Architectural tests (package-dependency rules, import linters) that do not care who wrote the import.
Size caps on PRs. Assistants make 800-line PRs cheap to produce and expensive to review. From Lahore, a reviewer catching a US morning deadline will rubber-stamp. Cap it.
Explicit test obligations for new public functions, generated or not.

How should researchers evaluate long-term impact?

Do not stop at HumanEval. Longitudinal measures:

Vulnerability density by cohort of PRs (pre/post assistant), with the same SAST and human review budget.
Mean time to remediate issues introduced in high-accept weeks.
Clone families of deprecated APIs over quarters.
Change-failure rate and escaped defects, not just throughput.
Reviewer fatigue: comments per KLOC, time-to-first-review.

Control for who uses the tool. Your strongest engineers may accept fewer dangerous suggestions. Naive pre/post will credit the assistant for the team you already had.

What does an aging policy look like?

Generated code has a half-life. Six months later the model that wrote it is gone, the API it called is deprecated, and the author might have left.

Birth: PR label optional; scanners mandatory; tests on new exports.
Youth: clone detector watches for the snippet spreading.
Midlife: when a CVE or deprecation hits a pattern, search by fingerprint, not by “ask the intern.”
Retirement: a campaign PR or a codemod, with a freeze on new clones in CI.

This is how large repos in product companies already treat log4j-class events. Assistants just increase the number of copies you must find. Teams in Pakistan maintaining US-owned codebases should insist on fingerprinting in the client’s CI, not in a spreadsheet.

What should reviewers be trained to see?

Reviewers miss what looks idiomatic. Train on a short catalog:

New HTTP handlers without authz tests
String-built SQL or shell
verify=False, debug CORS *, hardcoded keys in examples the model copied
Dependencies added without a lockfile reason
Tests that only assert a mock was called

A 15-minute weekly review guild on real assistant diffs beats a 40-page secure-coding PDF the model will not read. Pair it with in-repo examples of the approved pattern so the next suggestion is closer.

What should you ship this quarter?

Turn on secret scan and SAST on all diffs. Block unknown packages. Fingerprint two or three known-bad snippets from your last incident and fail CI if they return. Add a test requirement on new exports. Put copilot/standards examples in the repo where the model can see them. Measure escaped vulns, not acceptance rate.

I review production AI and full-stack systems from Lahore. If assistants tripled your merge rate and your incident rate followed, services is how I work with teams, and contact is the shortest path to a life-cycle you can audit.

FAQ

Does AI-generated code have more vulnerabilities than human code?

It has a different mix. Models copy outdated patterns, skip authz, and hallucinate APIs. Humans ship logic bugs and rushed crypto. The operational fact is that generated code arrives faster than review scales, so undetected issues accumulate unless you tag, scan, and age them.

How do I detect LLM-generated code in a large repo?

You rarely get a perfect detector. Use editor telemetry where you have consent, PR labels, commit trailers, and weak statistical detectors as hints—not as courtroom evidence. The life-cycle should assume mixed authorship and still scan every change.

What security checks belong in the Copilot loop?

SAST on the diff, secret scanning, dependency and license checks, and forbidden-pattern rules for auth, SQL, and deserialization. Add evals for "looks right, fails threat model." Blocking only on human-written files teaches people to generate the risky part.

How should teams in Pakistan manage Copilot debt?

Treat generated code as a loan with interest: require tests on generated functions, cap PR size, and schedule debt sprints when duplication and outdated APIs spike. Cheaper tokens do not mean cheaper ownership when the on-call is in Lahore and the traffic is in Virginia.

What is a maintainability life-cycle for generated code?

Provenance at birth, automated quality and security gates, production error attribution back to originating PRs, and a retirement policy for clones of deprecated patterns. If you cannot find the generated copies of a bad snippet, you do not have a life-cycle.