You don't fill all the lower levels of details. You're likely not caring about generated machine code, you're likely not caring about details of memory deallocation, you're likely not caring about Unicode quirks when you're comparing strings, you're likely not even aware which algorithm is used when you're multiplying two BigDecimals, you're likely not care which characters are allowed in HTTP header names, and so on and so on. A lot of implementation details are already implemented. There's no reason that programs won't be abstracted further away. Sure, it still is programming, but with less unnecessary details (so more people can do it).

You're thinking of the lower-level details of the computer but the issue is the low-level details of the problem you're trying to solve. The amount of detail necessary to solve even the most basic business problem is far more than the average client can ever describe on their own.

All the computer abstractions help solve computer problems and in turn make it easier to implementation solutions but doesn't make the business problems any smaller.

Yes, what you describe is the point at which abstractions meet your problem from the bottom. You're not developing solutions yourself down to level of pure physics, but that's because we have a solid abstraction layer of digital computing. Your job is to work down from the problem idea until you connect to that layer.

It still doesn't change the fact that the surface area of that layer is enormous, and so is the space between it at the bottom and your problem at the top. All the details in between is what you need to figure out.

I'm not completely sure the bottom can be qualitatively raised very far up. The digital computing abstraction is a qualitative model change, from physics to mathematics. Experience suggests that when you decompose a business problem, the lowest algorithmic details very often end up on, or slightly above, that bottom layer - so you need the ability to work on that level. Of course, if you're willing to limit your scope and problem domain, then a lot of things can be abstracted further - but they won't generalize.

Most programmers/developers don't deal with the problems that you mentioned on a day-to-day basis. They are already abstracted away, and most programmers/developers try to make sure that they deal with the actual problem at hand instead of repeating the same problem in each project. The actual problems are not going to get any easier. The abstraction levels will get higher, but the actual problems dealt with will not.

You're right, but it doesn't seem that hard to teach/guide people to be precise.

The fact that you can get Linux kernel developers who rail strongly and vehemently against compilers because the compiler optimized it against what you said, which wasn't what was wanted, strongly suggests that it's not a matter of precision.

More specifically, people generally have a vague idea of what they want. While you could explain a fully precise mathematical model that corresponds to that idea, people don't really have a good way to know if the model is correct or if there is some hidden corner case that causes problems. So they accept the model until they find one case where it was wrong.

It's hard to impart the true understanding of just how much details a real-world problem has without making someone try and solve some real-world problems.