"Here" and "there" are anything that expects or provides data.
Just seems to me that a substantial portion of the work of the programmer is "here to there" data mapping work.
The more you tie meta-data to your data the more this can be automated. And the more you use "standardized" formats the more this can be automated as well. (Unless the standard format can be read in more than one way, then you have a mess.)
In real-world projects, it is very often the case that much of what I do (maybe 75%?) is basically what I think of as "plumbing."
Not just in web development, where it manifests as marshalling and packing and unpacking data, but in multi-threaded embedded programs, where it manifests as packing data into structures and sending it between tasks using queues and serialization, maybe managing checksums and supporting retries and error-handling, transmitting between chips via serial, I2C, SPI, etc), and in GUIs (managing state, moving data between formats and cascading state changes while trying to keep everything sane and consistent in a multi-threaded environment. It's often a basic design element I've seen plenty of times before but it still needs to get written and it has to run flawlessly.
The remaining 25% or so can involve some real algorithmic thinking, or and state machine thinking, and that's more interesting, but there is almost always some tedious boilerplate around it unless I'm working on, say, a side project in Haskell, but even using a nice pure functional approach which makes gleaming, beautiful functions to express an algorithm, there's the "plumbing" and the tooling, monadic and weirder.
That's just something that is inherently hard about maintaining a long career in software development -- keeping yourself motivated to get through the duller parts so that you can enjoy the more interesting and challenging parts, and not just doing the minimal, but writing quality code and comments, not skipping steps, documenting your design, writing whatever documentation someone will need later to understand it later, etc. Even simplifying and revising it just for the sake of reducing complexity of working code, when something can be simplified.
Try looking at it differently. When you take data for a database and present it to the user, you aren't moving data from here to there but you are creating information. This is why we call it IT not DT.
Creating information for people is a much more interesting problem and you have to know a lot more about their workflow and requirements.
Alot of the programming work done today to achieve this will go away.
We are on the way there now clearly.
We do, it's the languages we use every day. Any higher level of abstraction will take almost as much work and be much less flexible. We're already in the sweet spot.