Nope. I would consider the opposite. I would pay more for candidates not reliant on frameworks, AI, and other helpers.
AI? In the hands of a craftsman AI is just another tool that can help boost productivity. In the hands of a junior developer trying to use AI to make it appear that they're a senior developer - no. There are too many downside risks in that scenario because the junior developer doesn't have enough experience to know when the tool is providing bad results.
Frameworks solve two business problems:
1. Candidate selection
2. Clearer division of labor
That’s it. Everything else is an imaginary quality from the developer. In most cases the well reasoned arguments from developers in favor of large frameworks can be performed faster without the frameworks, both in human writing speed and software execution speed. Typically these imaginary qualities taken a defensive tone from developers who have never learned to execute without the frameworks, which becomes an argument from ignorance because you know what you are arguing for but not what you are arguing against.
At any rate the result is the same that the article makes about AI: output of brittle toolchains.
I really can't put frameworks in the same bucket as AI. At least frameworks describe an abstract model for a developer to rationalize and think through. AI allows (but doesn't mandate) a developer to write code that they don't understand.
Perhaps I've worked on business logic so long instead of esoteric efforts; what real world use case would benefit from not leveraging a framework where applicable?
In fact, I see your publicly posted resume; are there really developers out there rawdogging Javascript? What problem space do you hire for that mandates the ignorance of >15 years of JS libraries?
And does your business pays above market rate for these skilled developers? Without understanding the problem space I just assume your business tries to hire talented people at exploitative wages. Regardless it appears to be a staggering waste of talent unless the higher quality significantly reduces the cost center of downtime, bugs etc (I find this hard to believe)
Performance, security, and portability to start. If you work in a high security environment you should expect to NOT have access to things like Maven or NPM.
I hear so very many people on HN and the real world complain about web bloat. Even the people who contribute to that bloat and cannot live without the contributing factors complain about it. As somebody who is only writing personal software now and working in a completely unrelated field I certainly wouldn't punish myself with bloat that requires far more work than executing without it.
There are a myriad of other benefits from using frameworks, so many in fact that to me it's a red flag when someone advocates against them.
With regards to AI, like I said in my original comment it's a tool, not a panacea. Experienced software tradesmen are learning how to effectively wield AI - hint: it's not for writing all your code. I'm kind of excited because we could be on the verge of another great productivity boost like we experienced 30 years ago when we adopted frameworks.
That is the primary reason I wanted to change employment from writing JavaScript to something else. If I could find JavaScript employment without this insanity then maybe I will reconsider my options. I see AI as more of the same.
Frameworks may not bring magical perfection but they bring a lot of objective benefit to the table.
Contrasted with specific acronyms frameworks, languages and similar buzzwords that dominate computing recruitment.
If you have a tool that can basically take someone who's really good at programming, architecture, analysis, etc, and eliminates the barriers of domain specific knowledge, syntax idiosyncracies, library peculiarities away ..
It should mean a talented IT professional should actually be more useful across more domains. And hiring should reflect that. It's hard to tell right now because hiring is zero apparently.
For example, I haven't coded at rust. I have encoded in c++ in 20 years. Assuming of course that I am a genius, which of course I am right? Assuming that, llm should allow me to both code in a language I don't have a lot of experience in, and adapt to you or enterprises particular code base far more quickly.
Does my value go up? Probably not. Because now I compete with everyone else. That's pretty smart without domain barriers. That's a large increase in supply.
However, large amounts of IT people who don't even know the basics of computer science architecture or those types of things, Will not have any real value compared to an llm.
With the hypnosis of the executives, they do not see a difference between those two different types of professional. They see an IT budget that they want to axe.
One of the fundamental tensions in it management/labor dispute is that someone that manages and maintains a service and codes... is actually a manager. Good it professionals are providing both technical service and managerial service to a company.
Consider what computers used to do. There used to be a room full of actual human computers on calculators doing things, and of course, a manager that oversight oversaw them.
That manager was clearly considered part of the managerial class.
Then came computers and the room of people disappeared and you still had a manager managing an IT application. But without the head count, Management decided that that person wasn't a manager or a member of the manager class.
Yet they had to pay him like that.
See. I think ultimately llms are taking away some of the technical overhead on managing and Enterprise system for a company. But it still needs to be managed. And that person will still be "IT".
And if you don't pay that person reasonably well, your Enterprise will suffer.
Yes, there are some fundamental skill deficits and a lot of liars out there. The historical solution to this problem is to ignore it, use some tool to flatten the bell curve, and then hope for the best. If AI is just an evolution of things already tried, then we already know what the results will look like: less accountability, less credibility, less selection risks for candidate selection, and more expensive development processes. For example frameworks allowed substantially wider developer participation at lower product quality and high costs without change to business ambitions. We should expect developers to become more of a less capable commodity than they already were.
Then when the technical debt becomes to expensive to maintain just call in consultants to tell everybody what is already commonly known.
But you're right, it's not going to happen