Here is my own personal policy when it comes to AI usage.
TL;DR:
0% AI in articles. If you want someone to read something, then take the time to write it yourself.
0% AI in human-facing documentation. Same idea as #1. If you want someone to understand something, take the time to understand it enough to write an article on it.
Don't let AI make decisions. AI is fundamentally trained to hack until unit tests are green. It wastes/spends your hard-won design/stability/zen, and accrues tech debt.
Because of #3, Don't let AI program. Programming is full of decisions, and AI usually makes the wrong decisions.
I distinguish programming from changing code. Mechanical refactors and mechanical small changes are fine, because the AI is not making decisions.
Exception to #4: AI-designed code is temporarily allowable if it's in isolated submodules that are pure (don't modify inputs) and only use pure APIs. However, know this is technical debt.
As with all technical debt, it should be tracked, isolated, have its removal planned+designed, and be actually removed before the next (minor) release.
Thoughts
The biggest realization from all this is that AI-designed code is technical debt.
Any experienced software engineer recognizes this when they actually look at the code that Claude generates.
If anyone is unconvinced of this, I recommend they do an experiment: make requirements for, then design, then implement a medium-sized feature. Then, give Claude just the requirements. Compare the outputs.
In my experience, Claude's implementation is worse about 80% of the time.
But, all that said, technical debt can be wielded well, if someone has the discipline.
Of course, while many software engineers have the discipline, very few software engineers have the space, unless they work under particularly good technical directors... in theory. Only in one of the six teams I've worked on has that been the case (never change, Google Earth).