I guess the main difference is that code editing is done in collaboration with the author (code review) as opposed to an editor.
If refactoring code did not have the potential side-effect of changing its run-time behaviour (or performance) I'd argue that software engineering would also benefit from a 'code editor' role :)
(metaphor/similar example follows)
In the same sense that someone who reviews a (IT) technical procedure is not necessarily a systems administrator, but someone who sees things from an angle to ensure RACI model is followed throughout without any generalizations such as "backup is taken" (by who? using which tools? which systems/data are backed up? how often? how long do we keep the tapes? how often do we trash the tapes? where do we store the tapes?). I haven't taken a backup for more than a decade, but I would shred a backup procedure to pieces. If you remove me from the review cycle, I won't go back to writing procedures.
Same way as humans? Via training on new inputs?
There are no new inputs in this case because we got replaced editors with NN.
Or their own work, as ranked by readers (e.g. their past posts that had the more views and better engagement).
It doesn't have to understand any of those in any "human" sense, where it would be able to articulate what it understood on a meta level, etc.
It would just have to reinforce the right patterns and fuzzy connections that lead to success in writing credible looking articles....
We're probably at a point where we can manufacture shallow fakes of the current writing style, and I'm sure techniques like this will become prevalent (because convenience), but I feel you're missing the point of what I'm saying. It does need to understand these things. If it doesn't, then what it is is a mechanical reproduction of a current style of writing: that's a completely different category of thing, it's not even close to similar.