> Someone in that industry would approach it from the other end, and say that they can write a req and get some commodity software to solve their problem from some developer half-way around the world.
I agree that's how they'd like it to work. But in reality, their in-house teams have become more and more technology-oriented, and programming literacy has become a higher priority in hiring. An "analyst" used to be a clever kid with a finance degree; now they have a finance degree and are comfortable in VBA, SQL, and an analytics package. Badass programmer? No. Software literate? Yes.
> We've removed a ton of overhead and boilerplate, and lowered the barrier to entry tremendously.
Agreed (I'd caveat that by noting that we've also hugely increased our expectations for software functionality, but the point still stands). But note that all of these consultants who can knock out a CRUD Rails app still have to read and write code. What the lower barrier to entry means is that a bunch of people who previously couldn't do it now can, including potentially the business analyst who defined the requirements, assuming they have some basic software literacy.
That's going to quickly translate--is already translating--into the expectation that the analyst can actually write the code. Being able to actually code your solution to a problem makes you more productive, because your employer doesn't have to pay a consultant to accomplish that work, and because there isn't an extra layer of communication overhead. So businesses will begin demanding software literacy as they become more reliant on basic software development (or, depending on prevailing labor conditions, simply paying more for it), because it makes them more efficient. This is similar to how productivity technology (voicemail, email, software calendars) hasn't made secretaries' jobs easier, or turned them into a turnkey commodity; it has largely eliminated secretaries and replaced them with the expectation that you do that work yourself. Same with travel agents. Same with tax accountants. As the tools allow for more productivity, people are forced up the productivity ladder. Progress.
Being literate in software is different than being an expert software engineer, and fortunately for expert engineers, we can simply solve higher-level, or at least harder, problems, so this development is actually good for us. My view is consistent with your idea that there will be a bifurcation between hardcore developers building frameworks and a bunch people who know the basics and can use the tools. The only difference in our views, as far as I can tell, is that in mine, this army of "commodity" programmers fielding client requests will be the clients themselves, and not an outsourced stable of kinda-engineers. Those kinda-engineers will be employed at firms as business analysts, product managers, etc, because their computer literacy will be really valuable there.