Wow, I was SO off-base. I read http://idratherbewriting.com/2017/06/02/when-docs-are-not-like-code/ and have to say, I had a TOTALLY different definition of "Docs Like Code" so thank you for posting this.
Maybe this is called something else, but I haven't found the buzzword yet.
I was thinking along the lines of the technical writer controlling the content much like a programmer does for the system they create. If someone wants a change to the way the system works, they have to log a request to have the change made and then the programmer has to evaluate how that change would impact the system. I had also seen requests from customers that requested adding a value to a drop-down on a single screen turn into changing many more screens. The reason was because the customer had no idea that drop-down was used on more than that single screen - that was their "pain point" where they couldn't select the value they really wanted to see.
Thus, for documentation, if someone wanted a wording change or a different style, they would have to log a request, I would evaluate the request to identify the impact. They may have been suggesting a change to a snippet that was used in many more places. And I wouldn't have expected the customer to know that - that would be my job, just like it would be the programmer's job to figure out where their suggestion impacts the system.