You can, but those "incredible things" have a shit lifespan and they die at unpredictable times, and it costs enormous amounts of money to fix or replace them (in part, because business requirements devolve into the "make it work exactly like the old system" style of project that makes good hackers leave and consultants ask for $50,000-per-week budgets-- in part, because they recognize the unpleasantness of the work and need to hire a team to do it; anyone savvy is going to find a way to collect the benefits while managing rather than doing that kind of work).
Mediocre programmers generate write-only code and systems that work well on launch but start to shake shortly after, like American cars in the 1980s.
Here's another thing. You can get seriously good (1.6+) engineers to maintain Postgres or the Linux kernel, because even though the work is hard and painful (and in the OS world, often gratis) it's an opportunity to learn from excellent (2.0+) programmers who built the thing. What were their concerns, and why'd they solve the problem this way? It's a learning process. But no one good is going to maintain the complexity sprawl generated by mediocre programmers for a typical programmer salary. The market rate for a good engineer to do that kind of work is $500-1500 per hour (because there's no career benefit to the work). Pay less and you'll deal with rapid turnover and evaporative cooling (i.e. the good leave and the bad stay). Or, the typical corporate solution is to put powerless junior programmers (who are not competent enough to maintain a system that is falling apart faster than they can fix it) on that type of work, which prolongs the death spiral only slightly.
