It's very much an area of R&D, and we hope that folks share any ideas they may have. For example, I'm unfamiliar with Kotlin's system and it would be useful if folks could share any vision for how it could be applied to Gleam.
Kotlin recommend ksp [1] but underlying platform's reflection is also available. I am not sure it (or something similar) will be a great fit for gleam but have been planning to explore it deeper for some time.
I now feel that some form of behind-the-scene code-generation or reflection support is generally good to have so that the bulk of the application stays focussed on application logic instead of various dto conversions, mappings, transformations etc. I don't shy away from Quarkus, MapStruct etc. now a days and I think my code is easier to follow because of what they enable.
Typescript is a bit of an exception here because the type system is quite powerful with various type transformation capabilities but Gleam's type system also appears to be quite minimal.
KTor kind of relies on Kotlin serialization which uses code generation behind the scenes (which is why you need to apply a plugin on your build system).
So in theory we could get the raw body, and then use something like Jackson's ObjectMapper.valueToTree to get an untyped object hierarchy and then convert that to properly typed domain objects through some manually authored utility methods. Nobody does that though because it is super convenient to have a library take care of that boilerplate for you with codegen or reflection which was basically the point of my original comment.