I use code-gen for my own experimental framework. I write a C# file that contains a few classes, where each class represents group of settings. These settings use custom attributes to add additional UI parameters, like descriptions and min/max values. This file is processed by a small C# app that I call "SettingsCompiler", which invokes the C# compiler to compile the .cs file containing the settings. Once compiled into an assembly, the settings and their attributes are reflected by the settings compiler and pulled into a list. From there, the settings compiler generates C++ code for initializing the settings using my framework's runtime classes. It also generates a matching HLSL file containing the constant buffer layout, as well as C++ code for filling that constant buffer with the current settings values.
The whole thing took a while to set up, but it's definitely worth the time savings now that I don't have to manually add and remove UI + cbuffer definitions. I was able to get it integrated nicely into a VS solution so that the SettingsCompiler is invoked as a custom build step right before the C++ code is compiled, so it's pretty transparent. I also rarely mess with that code now that it's working.
If you want to have a look at my implementation, it's all up on GitHub under the MIT license. The older version that uses D3D11 and AntTweakBar is here, and the newer version that uses D3D12 and ImGui is here.
Even if you go down the code-gen route, I would still recommend getting basic shader reloading to work. It's really nice being able to make quick changes and have them re-load without having to re-start the app. It's also not too hard to get going with basic timestamps. A lot of people will go down the path of using the Windows file watching API's for doing this, which certainly works but can be a real PITA to get right. But if you only have a few files to monitor, then you can just brute force it by checking the file timestamps occasionally.