To a certain extent all of them do. "devs who can't code" is hyperbole, but the whole point of a framework is to provide a framework that allows you to fill in the details without building all the plumbing underneath.
This is distinct from a reuse library where you write the plumbing while someone else has written the details of some functionality.
Often you get these super-frameworks that do all the plumbing for you and throw in veritable kitchen sinks of reuse libraries with the intent that you glue it all together to match your business logic. Very frequently this is the stated aim of these super-frameworks -- reason only about your business logic and leave all the details to us.
It is a compelling story, but usually one that doesn't have a happy ending. The devil is in the details. Your business logic usually requires you to hack something that the framework/library authors didn't anticipate. That hack leads to 10 more as you route around the "it isn't supposed to be done this way, but what could we do" mess. Over time it degenerates.
Then you hire old guys like me who are willing to accept money to grind out all the problems without quitting in a huff and running to the new shiny ;-) (only because our legs are tired from running after shinies when we were young).
There are lots of reuse libraries and even minimal frameworks who specifically say, "You're going to have to wire this up yourself. We're not going to make it easy for you. That's because we can't anticipate the problems you will run into and we are trying to give you as much space as possible to figure out how it should be done".
I like frameworks and libraries like that. I don't like the other ones, even though they generally pay my salary.