Early phases will involve the introduction of no/low-code automations that integrate existing APIs, services, and systems within businesses for the purposes of automating existing processes.
That's good for the APIs, systems and automation platforms because they become essential and encumbent components of operating those businesses.
The later, and I suspect much longer, phases will involve identification of business processes that aren't really needed and that can be removed by thinking about the ways that organizations function in entirely new ways, or that can be streamlined.
By that point some of the integrations may have become so baked-in that they'll require significant maintenance to update. And as we see with some cloud-based IoT devices, it's possible for service providers to encounter outages or cease operating, in which case internal businesses processes may halt.
All this is similar to the gradual automation and improvement of physical assembly lines; it's a case of applying the same principles to organizations. And yep, the cheapest, most efficient and reliable component is one that doesn't have to exist.
To simplify things, the early phase you mentioned is simply computing, and has been proceeding since the 1960s. The latter phase is called business process management (aka BPM) [1] and has been a thing since ~1980(?).
In promise, BPM says "Encode all your business processes and their relationships into our tool, and we'll optimize and automate them." In practice, BPM is doomed to failure because (1) it's invariably implemented in an organization by management consultant types who care more about billable hours than actual solutions & (2) it's fundamentally an imperfect abstraction over your actual business processes, leading to leaks / hacks in implementation, leading to yet another system that further slows down the business.
SAP is illustrative here, with the adage that smart businesses change their business to fit SAP, rather than try to change SAP to fit their business.
[1] https://en.m.wikipedia.org/wiki/Business_process_management
It questions whether one should automate something that will only need to be done a few times.
My own experience has led me to the point where if I'm thinking about automating something, I stop and ask "is there a way that this can be done away with completely?"
The most reliable, easiest to maintain scripts are those with zero lines of code. They also perform best and consume least resources.
With a bit of thought and/or flexibility in how things are achieved, it's surprising how often this question produces a good result.