First, assume good taste comes from doing work yourself. Maybe this is not true if you can get good feedback from what your AI struggles with, or if your AI itself gets feedback and improves. But assuming you do need to touch the code yourself to learn and develop good judgement, won't people who rarely or never use AI create the best building blocks for AI? Will there be a pattern of this hurting the original people involved?
For example, languages like gleam and zig, in order to engage contributors in the language, don't take AI contributions. Of course once a language is released people can use it however they want, including with AI, but there are at least a group of core users who make cool stuff by hand. When people exercise the language by hand, they get feedback and improve it. These improvements might be just "ergonomics" but they make it possible to manage more complexity and larger contexts.
Wait, larger contexts...sounds like this would be good for AI?!
So second, assume what's good for the goose is good for the gander, ie what helps humans work on code also helps AI work on code (apparently a gander is a male goose, but that's neither here nor there). Funnily enough this works both directions, for instance oh chatgpt seems to read and edit JSON pretty well with jq, so when I want to copy snapshot.element out of StructureDefinition-SEBasePatient.json, maybe I should try that jq thing. Importantly though in the human->AI direction, the strengths that make gleam nice for humans - simple sum types and immutable data, and explicit (maybe even verbose) data and functions rather than more powerful features - are also nice for AI. gleam check catches a lot of errors at compile time for humans and for robots too.
The potential problem though is AI polluting these pristine pools of human taste. Imo AI doesn't write great gleam. Getting some APIs wrong is fine as you can just point it at the current stdlib, and some problems you can check mechanically, like no assert in library code. But other problems are more domain specific. One annoying style is lots of local defensive checks rather than types that model the overall domain correctly. The AI will never say "does this really need to be a library - has anyone even tried using it in an application yet?" and in general there's just a much higher ratio of lines of code to contact with reality. Maybe if many gleam applications and gleam libraries are steaming piles of slop, that makes gleam less fun for AI haters, many of whom made gleam nice in the first place. Uh oh...
And could this pattern repeat in general? People developing good taste by manually working on something, then using that feedback to make something useful for people, as well as for AI, which reduces the human feedback that made the thing good in the first place?
(Not quite the same but related - in math, problems are interesting and worthwhile because of what we learn in the process of solving them, so ending a problem with a correct answer nobody understands does more to discourage mathematicians than help them.)
Or, who knows, maybe AI judgement is good enough and you can 100% AI rewrite it in rust and still make a useful tool, as hopes bun. Or maybe super dense code golf is good for AI but not humans, or reversed, more explicit/verbose code is good for humans but bad for AI. Or maybe a bunch of AI enjoyers descending on a project doesn't stop you from saying I'm going to ignore all of you and keep working on what feels nice to me, leading to fishbowl conversations where AI users listen but don't contribute.