I'm probably extremely biased (I'm a sysadmin), but this feels like a terrifying way to make your infrastructure entirely implicit and remove anybody's ability to coherently reason about the stuff underneath your application.
I'm not entirely averse to magic infrastructure beans but having an intermediate step where things are explicitly spelled out would make me far less nervous. Using shuttle to spit out a TF file – cool, using shuttle to automagically spin stuff up – terrifying.
This exact problem is my main beef with an unfortunately common and popular style of functional programming : stuff so condensed, so abstracted and so focused on describing the problem all the while hiding the actual execution / implementation / solution layers it's quasi-impossible to reason about and understand what actually happens when the program runs.
> this feels like a terrifying way to make your infrastructure entirely implicit and remove anybody's ability to coherently reason about the stuff underneath your application.
There's two parts to this. The first is understanding what is happening under the hood since we're automatically provisioning so much for you (subdomain, LBs, DBs, etc.). Right now this is a little opaque, but a dashboard is in the roadmap to give users visibility on what's happening 'under the hood' - showing your provisioned infrastructure as well as how it's all wired up.
The second point is about potentially destructive actions - here we're going to be following a 'terraformesque' philosophy where infrastructure diffs are presented to the user and need to be accepted explicitly when deploying (or via a `--auto-approve` flag).