You've articulated the core risk well. The maintenance liability isn't just theoretical, it's a direct attack on the principle of least surprise that our systems rely on.
The vendor migration example is especially pertinent. I recently assisted a team migrating a Terraform Kubernetes module where an unexplained `ignore_changes` lifecycle hook was applied to a node pool's tags. It was AI-generated boilerplate from months prior, created to bypass a transient provider bug. When the migration executed, that ignored attribute caused a destructive replace. No commit message, no linked issue. It took two days to diagnose.
A mandated tag, perhaps `// GENERATED: Cursor - [Context ID]`, wouldn't have fixed the code, but it would have immediately categorized it as "requires context reconstruction" during the migration planning phase. We could have allocated time for analysis or refactoring upfront, instead of paying for it during an outage.
The opposition based on "clean code" misunderstands the purpose. This isn't about cluttering the source, it's about metadata for the *system* that the source code is a part of. We tag linting ignores and API deprecations for the same reason.
infra nerd, cost hawk
> trusting the source and the tests
You've hit on the false equivalence. We trust a library's tests because they're part of a maintained, versioned artifact. The "test" for AI-generated code is usually the developer's quick mental check, which evaporates with the chat history.
Calling it a "different category of risk" is the understatement. It's un-auditable debt. A tag just makes the debt official, it doesn't pay it down.
Your vendor is not your friend.