I agree, configs in code are not a bad thing necessarily if they don't change often or at all. Sprawling config files are a significantly higher challenge to get your bearing with.
I’ve been trying unsuccessfully to get buy in on config as code.
Instead we have property / yaml files, read into anaemic “classes” which do not perform validation themselves. Validation duties are also foisted onto other parts of the system.
Stacked onto that we sometimes have file name based convention for defining a hierarchy of configs, to save on repetition between environments.
Config as code is fine as long as it results in a fully realized config that is then consumed by other code. All the big companies have almost certainly done it.
I would make sure when implementing it you have someone who is very opinionated review all configs to ensure that the same behavior is always implemented in the same way until a linter can enforce idioms. I would avoid explicit conditionals and explicit loops, instead relying on implied conditionals and implied loops. I would absolutely not use any "live" data, meaning the code should be relatively pure without any dependencies.
