It is understanding that there is a problem which is solvable, understanding the shape of that problem well enough to arrive at a way to solve it, working out that solution, and then expressing it clearly to another entity, whether human or computer.

None of these things are special to programming; they are all specialized skilled work that is still hard in fields that do not involve computers.

Mathematicians create and communicate theorems. Legislators create and communicate law. Engineers create and communicate designs for mechanisms. Chefs create and communicate recipes.

All but the most trivial fields involving one person talking to another rely on a large body of knowledge shared by the participants, and use domain specific language in order to communicate ideas clearly and unambiguously. It is not absolutely required, but it saves an incredible amount of time, misunderstanding and wasted effort. When discussing matters of any complexity, clear communication is vital.

There is certainly room for the jargon and workflow to improve; for us to come up with languages that are more expressive in their domain, and for processes that are more intuitive - whether by being closer to what communicating your ideas to another skilled human would be like, or some other way.

But the actually hard work can no more go away than in any other human endeavour.

Much of what you seek is there. payment services, banks, networks have an API or an SaaS (Stripe, Paypal etc) that mean you're dealing with much simpler entities.

Back when I was first messing with code you'd first have to get the banks to agree to allow access to account data. Then you'd probably be writing in C or C++ to conform to whatever standard arose, perhaps over X25. There's libraries and services covering so many of the basics, usually with a JSON API, now it's sometimes hard to believe. You can be astonishingly productive building on that.

What's left are the parts that are frequently going to be solution or preference dependent. The unique to the app parts, and the code that glues that and the building blocks, frameworks, and APIs together.

[1] https://en.wikipedia.org/wiki/The_Last_One_%28software%29

I disagree. It's just that the big disruptions in the task of programming happened earlier than the other disruptions.

> In my mind, in the 21st century programming should have been essentially abstracted and behind the scenes, only a few experts need to know it and tweak it.

It is. That's why the interesting apps are so much more complex than they used to be, and all the developers are working in highly-abstracted frameworks on top of high-level language, and only a small minority are working even in C (which wasn't considered a particularly low-level language in the 1980s.)

> We should be able to create our business logic for our applications, not through complicated SQL statements and backend codes, but by simply training a model on expected behavior through examples or discrete visual rules.

Sufficiently large training sets for complex applications don't exist, and for complex business processes, we write detailed processes for humans, too, to assure clarity of expectations. Why would we expect even with AI, which aims ultimately to mimic human intelligence, to not need that?

However, much of it is abstracted away now - if you're making a payment app, you're probably going to use stripe, because that's a hell of a lot easier than bootstrapping your own credit card processing system. If it has a web version, you're probably going to use a js framework or two, to abstract away boring things like handling state and manipulating the DOM.

Until a computer can read your mind to know exactly what program you want, you'll still need to do some programming

Frameworks, high level languages and other abstractions are supposed to make it easier for us meatbags to compose and organise our instructions.

Somebody - be that a human, an AI or some other mechanism - still has to compose those instructions in the first place. And if you remove humans from the application programming side, you still need to create and maintain the mechanism for figuring out what instructions to dispatch in any given circumstance.

I think there is much more room to disrupt the process of programming, to remove much of the domain knowledge and break down barriers to entry, but ultimately the core problem of telling a dumb machine which bits to flip won't go away with current architecture.