You're spot on with shifting the complexity to the cloud layer; our thought was that it would free up time for dev teams to focus on other layers of their application.
Maybe I'm misinterpreting your question though, I'm happy to annotate that code snippet with a walk-through.
That's probably a bit too philosophical and nothing a company should have to worry about. Again, I think you're doing great work here, I'm just unsure whether this is the best solution for the overarching problem.
But with Unison Cloud, most of the complicated API is written as a library in Unison itself[0]. This `cloud` library is technically optional (and editable), and you can build and share your own abstractions as you like, so you don't have that hard rough edge between AWS APIs and your own code.
[0]: https://share.unison-lang.org/@unison/cloud/code/releases/9....
If you treat infrastructure as a problem that has to be solved by code, obviously you'll run into code specific issues like type safety. In the real world I've never root caused a production issue back to that.
Your definition of type safety might not include validation + using the type to carry proof of that validation throughout the life of the program.
For examples see:
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...
A YAML configuration file missing a required key, or a misspelling, or a disallowed mixing of parameters, are all things that can be solved by type-safety, rather than getting a deploy-time or run-time error.