One case where this is already eminently possible, is automatically keeping a codebase's dependencies up-to-date. We already have CI scripts that find out-of-date dependency specifications and notify the developer of them. It's not far from there to having said CI script generate a PR for an update to said dependency, hypothetically apply it, and then actually merge it in if all the tests still pass. (And, rather than just giving up if the absolute-newest dep version doesn't work, such a system could easily be extended to bisect the dep's version history to find the newest version it could update to without breaking the build, perhaps constrained by the dependency's version-constraint string.)
You can do this with Dependabot [0], recently acquired by Github.
We use Dependabot, and I love it for our backend repositories, but anything with node dependencies ends up being easier to manually update (because there ends up being so many dependencies that get updated every day, that opening a PR for each one essentially launches a denial of service attack on our CI system)
Configuring it to open pull requests less frequently doesn't help, since dependencies still get updated one by one, rather than in batches. I've found it easier to just run an interactive yarn upgrade every so often.
Actually specifying what we are trying to do is nearly the whole of the programming.
Describing things correctly and with all necessary detail is genuinely hard, because building a mental picture required for that is hard, even with all the information tools we have.
