For real: profitable consulting businesses have been formed to help LLM programmers. BUGFIX 66, for example, and various others. They can charge substantial money to help customers cross that "last mile" and get their LLM-generated pile of code working.
I'm a full-stack engineer with 12 + years of experience building software primarily on the web and mobile at scale for Silicon Valley Tech Giants (ex-LinkedIn), VC backed startups (ex-OpenSea), and Open Source Projects (https://github.com/cncf/cnf-testsuite/).
Would you rather work in the React and Typescript you know leveraging all that experience with a rapidly maturing platform (check out https://expo.dev/ for instance.)?
Or a framework few others use written in a language Google is likely to drop support for randomly?
let me calm down and breathe and I'll take the bait ...
look just because you're not Lebron James or Michael Jordan doesn't mean you can't go to your local basketball court and enjoy a game of pick up.
But the same way you don't conflate what you need to do to be one the of the best people to ever play a game to play at all...
your software engineering team doesn't need to feel completely useless because they aren't immediately using <insert new hot tool> .
Everything in software engineering from side project to unicorn startup service is about tradeoffs.
Tradeoffs happen because of constraints.
I don't expect a consulting shop to build code the same way an open source project does or a publicly traded company that has been profitable for 10 or 20 years.
I'm hoping you can read in this the need to be cognizant about manpower tradeoffs.
So yes I fully appreciate this as someone who has consulted, worked a public companies, and is now at a rapidly growing startup...
Just because your team isn't meeting some imaginary ideal for some other form of team with different constraints doesn't mean you can't ever strive for any ideal or give up...
you just have to be realistic about trade offs...
my favorite example of this is thinking about a system like rails vs early react (loooong next.js or even before the context system) or a lot of things built in the python web ecosystem.
With rails you have scaffolds and endless convenience methods that let you be productive quickly even as a small team or shop...
with early react or python web you were largely left to your own devices out side of the core flows they had solved (painting updates to the dom with react or some rudimentary crud stuff with django or flask) ...
Because they were built by and more importantly FOR different types of teams.
Rails by the relatively slender (and famously against VC type scaling) 37 signals consulting crew and react by facebooks behemoth engineering team.
Of course they are going to build for their own trade offs...
why would you not?
(I intially opened this rant with this final piece thata I thought better of starting with but I still stand on the feeling...
The is the biggest piece of curmudgeonly nonsense I've ever read... its like someone training an ml model on last 5 years of HN comments and churning out a click bait blog post)
but I basically just made it to get better at kubernetes design doc writing, and play around with hasura, next.js, vercel and a bunch of other tech toys.
