[holoway]

1. I'm sympathetic to your doubt - I had the exact same doubts, and part of why it's taken us so long to build is we refused to sacrifice what was good about IaC to get "simplicity". If this was ClickOps, they should be allergic to it. But it isn't. Under the hood is a very powerful new primitive - a reactive hypergraph of functions. The UI is there because it's a fast way to compose things together, and to radiate more information than you can get from an editor alone. But everything you do is tracked, it's fully open and extensible by writing code, and it's much easier to use to communicate with your team members who might not know all the intricacies of IaC.

2. There is how it is better today, and there is how it can be better in the future. Focusing on just today - frequently the kind of review that needs to be done is by an external subject matter expert. Being able to bring those people in to a change set, show them what the change you are proposing is, and have them inspect and alter it with you in real time is great. An example here is one of our early users wanted to use ECS, but had never used the service before. So they put things together in SI, asked someone who had that expertise to look it over - they could see the architecture, they could change properties, add a few missing things. It was much more straightforward than a back and forth in a PR.

But that's not to say that, in the future, there isn't more to do. We need to have more functionality around who needs to review things, build more specialized views for the review (there's no reason you should be stuck doing a review only in a single view of the architecture), use the snapshots we have of the entire graph to build more insightful ways of communicating what's changed (and what actions will happen when you apply.)

Think multiplayer and powerful review and approval semantics.