> Junior developers: Make yourself AI-proficient and versatile. Demonstrate that one junior plus AI can match a small team’s output. Use AI coding agents (Cursor/Antigravity/Claude Code/Gemini CLI) to build bigger features, but understand and explain every line if not most. Focus on skills AI can’t easily replace: communication, problem decomposition, domain knowledge. Look at adjacent roles (QA, DevRel, data analytics) as entry points. Build a portfolio, especially projects integrating AI APIs. Consider apprenticeships, internships, contracting, or open source. Don’t be “just another new grad who needs training”; be an immediately useful engineer who learns quickly.
If I were starting out today, this is basically the only advice I would listen to. There will indeed be a vacuum in the next few years because of the drastic drop in junior hiring today.
> be an immediately useful engineer who learns quickly
Then also nothing has really changed. This was, verbatim, the advice everybody was giving when I was a grad student almost 20 years ago.
Back then, the conclusion was to learn the frameworks du jour, even if it was unfulfilling plumbing and the knowledge had a half-life of a few weeks. You needed it to get hired, but you made your career because of all the solid theory you learned and the adaptability that knowing it gave you.
Now, the conclusion is to learn how to tickle the models du jour in the right way, even though it's intellectually braindead, unaspiring work and knowledge with a half-life of a few days. It's still the theoretical foundation that will actually make the junior become a valuable engineer.
The more I read between the lines of AI evangelists' posts like this, the more I'm convinced that expectations will return to grounded reality soon. They are new tools to help the engineer. They enable new workflows and maybe can even allow a two-digit percentage increase in speed while upholding quality. But they're in no way a revolution that will make possible "10× engineers" or considerably replace engineering positions beyond the "it doesn't really matter" area of PoCs, prototypes, one-offs, cookie-cutter solutions, etc.
A humble way for devs to look at this, is that in the new LLM era we are all juniors now.
A new entrant with a good attitude, curiosity and interest in learning the traditional "meta" of coding (version control, specs, testing etc) and a cutting-edge, first-rate grasp of using LLMs to assist their craft (as recommended in the article) will likely be more useful in a couple of years than a "senior" dragging their heels or dismissing LLMs as hype.
We aren't in coding Kansas anymore, junior and senior will not be so easily mapped to legacy development roles.
I have been telling people that, titles aside, senior developers were the people not afraid to write original code. I don’t see LLMs changing this. I only envision people wishing LLMs would change this.
The author has a bizarre idea of what a computer science degree is about. Why would it teach cloud computing or dev ops? The idea is you learn those on your own.
The outlook on CS credentials is wrong. You'll never be worse off than someone without those credentials, all other things equal. Buried in this text is some assumption that the relatively studious people who get degrees are going to fall behind the non-degreed, because the ones who didn't go to school will out-study them. What is really going to happen generally is that the non-degreed will continue to not study, and they will lean on AI to avoid studying even the few things that they might have otherwise needed to study to squeak by in industry.
My experience hasn't been LLMs automate coding, just speeds it up. It's like I know what I want the solution to be and I'll describe it to the LLM, usually for specific code blocks at a time, and then build it up block-by-block. When I read hacker news people are talking like it's doing much more than that. It doesn't feel like an automation tool to me at all. It just helps me do what I was gonna do anyways, but without having to look up library function calls and language specific syntax
Yeah I also sense this disconnect between the reality and hype.
In part, I think what people are responding to is the trajectory of the tools. I would agree that they seem to be on an asymptote toward being able to do a lot more things on their own, with a lot less direction. But I also feel like the improvements in that direction are incremental at this point, and it's hard to predict when or if there will be a step change.
But yeah, I'm really not sure I buy this whole thing about orchestrating a symphony of agents or whatever. That isn't what my usage of AI is like, and I'm struggling to see how it would become like that.
But what I am starting to see, is "non-programmers" beginning to realize that they can use these tools to do things for their own work and interests, which they would have previously hired a programmer to do for them, or more likely, just decided it wasn't worth the effort. I think for those people, it does feel like a novel automation tool. It's just that we all already knew how to do this, by writing code. But most people didn't know how to do that. And now they can do a lot more.
And I think this is a genuine step change that will have a big effect on our industry. Personally, I think this is ultimately a very good thing! This is how computers should work, that anybody can use them to automate stuff they want to do. It is not a given that "automating tasks" is something that must be its own distinct (and high paying) career. But like any disruption, it is very reasonable to feel concerned and uncertain about the future when you're right in the thick of it.
I think it does both: you can have an LLM automate bad coding (that's the vibe coding part), and you can have an LLM speed up good coding.
Many times, bad code is sufficient. Actually too many times: IMHO that is the reason why the software industry produces lower quality software every year. Bad products are often more profitable than good products. But it's not always for making bad products: sometimes it's totally fine to vibe code a proof or concept or prototype, I would say.
Other times, we really need stable and maintainable code. I don't think we can or want to vibe code that.
LLMs make low-quality coding more accessible, but I don't think they remove the need for high-quality coding. Before LLMs, the fraction of low-quality code was growing already, just because it was already profitable.
An analogy could be buildings: everybody can build a bench that "does the job". Maybe that bench will be broken in 2 months, but right now it works; people can sit on it. But not everybody can build a dam. And if you risk going to jail if your dam collapses, that's a good incentive for not vibe coding it.
Love the article, I had a struggle with my new identity and thus had to write https://edtw.in/high-agency-engineering/ for myself, but also came to the realisation that the industry is shifting too especially for junior engineers.
Curious about how the Specialist vs Generalist theme plays out, who is going to feel it more *first* when AI gets better over time?
> junior developer employment drops by about 9-10% within six quarters, while senior employment barely budges. Big tech hired 50% fewer fresh graduates over the past three years.
This study showing 9-10% drop is odd[1] and I'm not sure about their identification critria.
> We identify GenAI adoption by detecting job postings that explicitly seek workers to implement or integrate GenAI technologies into firm workflows.
Based on that MIT study it seems like 90+% of these projects fail. So we could easily be seeing an effect where firms posting these GenAI roles are burning money on the projects in a way that displaces investment in headcount.
The point about "BigTech" hiring 50% fewer grads is almost orthogonal. All of these companies are shifting hiring towards things where new grads are unlikely to add value, building data centers and frontier work.
Moreover the TCJA of 2017 caused software developers to not count for R&D tax write offs (I'm oversimplifying) starting in 2022. This surely has more of an effect than whatever "GenAI integrator roles" postings correlates to.
>> The skillset is shifting from implementing algorithms to knowing how to ask the AI the right questions and verify its output.
The question is, how much faster is verification only vs writing the code by hand? You gain a lot of understanding when you write the code yourself, and understanding is a prerequisite for verification. The idea seems to be a quick review is all that should be needed "LGTM". That's fine as long as you understand the tradeoffs you are making.
With today's AI you either trade speed for correctness or you have to accept a more modest (and highly project specific) productivity boost.
In my experience (programmer since 1983), it's massively faster to leverage an LLM and obtain quality code when working with technology that I'm proficient in.
But when I don't have expertise, it's the same speed or even slower. The better I am at something, the faster the LLM coding goes.
I'm still trying to get better at Rust, and I'm past break-even now. So I could use LLMs for a speed boost. But I still hand-write all my code because I'm still gaining expertise. (Here I lean into LLMs in a student capacity, which is different.)
Related to this, I often ask LLMs for code reviews. The number of suggestions it makes that I think are good is inversely proportional to the experience I have with the particular tech used. The ability to discard bad suggestions is valuable.
This is why I think bring an excellent dev with the fundamentals is still important—critical, even—when coding with LLMs. If I were still in a hiring role, I'd hire people with good dev skills over people with poor dev skills every time, regardless of how adept they were at prompting.
1) The AI code maintainence question - who would maintain the AI generated code
2) The true cost of AI. Once the VC/PE money runs out and companies charge the full cost, what would happen to vibe coding at that point ?
AI assists the maintenance. A lot of posts seem to think like once the code is committed the AI’s what, just go away? If you can write a test for a bug, likely it can be either fully or partially fixed by an ai even today.
Funny that he mentions people not pivoting away from COBOL. My neighbors work for a bank, programming in COBOL every day. When I moved in and met them 14 years ago, I wondered how much longer they would be able to keep that up.
Sometimes I wonder if I made the wrong choice with software development. Even after getting to a senior role, according to this article, you're still expected to get more education and work on side projects outside of work. Am I supposed to want to code all the time? When can I pursue hobbies, a social life, etc.
Given how quickly models, tools and frameworks rise and fall, betting your career on a single technology stack is risky.
This was something I dealt with a lot when JS frameworks became the newest shiny thing and suddenly the entire industry shifted in a few years from being a front-end developer to being a full stack developer.
This happened to a lot of my friends who went all in on Angular. Then everybody switched to React.
The issue then became, "What should I learn?" because at my company (a large fortune 200 company) they were all in on Angular, and weren't looking for React developers, but I knew companies were moving away from Angular. So do I work to get better and more indispensable with Angular, and risk not knowing React? Or do I learn the new shiny framework betting at some point my company will adopt it or I will be laid off and need to know it?
It feels like half my life as a dev was spent being a degenerate gambler, always trying to hedge my bets in one way or another, constantly thinking about where everything was going. It was the same thing with dozens of other tools as well. It just became so exhausting trying to figure out where to put your effort into to make sure you always knew enough to get that next job.
No. As junior you feel the pressure to make senior. You can't be junior for too long.
As senior, if you choose, you can coast. By coast I mean you do justice to your job and the salary you are paid. Its a perfectly acceptable choice for someone to be senior for as long as they want.
The biggest bottleneck is going to be what other seniors and higher think of you.
One thing that fucks with juniors is the expecration of paying for subscriptions for AI models. If you need to know how the AI tools work, you need to learn them with your own money.
Not everyone can afford it, and then we are at the point of changing the field that was so proud about just needing a computer and access to internet to teach oneself into a subscription service.
My question: are those people who were building crappy, brittle software, which was full of bugs and and orher suboptimal behavior, that were the main reasons of slowing down the evolution that software, will they now begin writing better software because of AI? Answering yes, implies that the main reason of those problems was that those developers didn't have enough time to spend on analyzing those problems or to build protection harnesses. I would stronly argue that was not the case, as the main reason is of intelectual and personal nature - inability to build abstractions, to follow up the route causes (thus not aquiring necessary knowledge), or to avoid being distracted by some new toy. In 2-5 years I expect the industry going into panic mode, as there will be a shortage of people who could maintain the drivel that is now being created en masse. The future is bright for those with the brains, just need to wait this out
Something very odd about the tone of this article. Is it mostly AI written? There is a lot of references and info. But I am feeling far more disconnected with it.
For the record, I was genuinely trying to read it properly. But it is becoming unbearable by mid article.
I mean it's pretty simple:
management will take bad quality (because they don't understand the field) over having and paying more employees any day.
Software engineer positions will shrink and be unrecognizable: one person expected to be doing the work of multiple departments to stay employed.
People may leave the field or won't bother learning it.
When the critical mass is reached, AI will be paywalled and rug pulled.
Then the field evens itself out again over a long, expensive period of time for every company that fell for it, lowering the expectations back to reality.
That's another one for concluding that there's nothing new under the sun. This is the exact dynamic that happened during the offshoring hype.
Now, it's expecting senior engineers to "orchestrate" 10 coding agents, then it was expecting them to orchestrate 10 cheap developers on the other side of the world. Then, the reckoning came when those offshore developers realised that if they produced code as good as that of a "1st world" engineer, they can ask a similar salary, too, and those offshoring clients who didn't want to pay up were left with those contractors who weren't good enough to do that. This time, it will be agent pricing approaching the true costs. Both times, the breaking point is when managers realise that writing code was never the bottleneck in the first place.
The most useful thing juniors can do now is use AI to rapidly get up to the speed with the new skill floor. Learn like crazy. Self learning is empowered by AI.
Is there a Jeapordy for guessing prompts? Give an executive summary of GenAI trends where GenAI is the destiny and everything reacts to it. Touch on all “problems”. Don’t be divisive by making hard proclamations. Summarize in a safe way by appealing to the trope of the enthusiastic programmer who dutifully adapts to the world around them in order to stay “up to date”; the passive drone that accepts whatever environment they are placed in and never tries to change it. But add insult to injury by paradoxically concluding that the only safe future is the one you (individual) “actively engineer”.
I’m not saying that this was prompted. I’m just summarizing it in my own way.
This article suggests it is specialists who are "at risk", but as much more of a generalist I was thinking the opposite and starting to regret not specialising more.
My value so far in my career has been my very broad knowledge of basically the entire of computer science, IT, engineering, science, mathematics, and even beyond. Basically, I read a lot, at least 10x more than most people it seems. I was starting to wonder how relevant that now is, given that LLMs have read everything.
But maybe I'm wrong about what my skill actually is. Everyone has had LLMs for years now and yet I still seem better at finding info, contextualising it and assimilating it than a lot of people. I'm now using LLMs too but so far I haven't seen anyone use an LLM to become like me.
So I remain slightly confused about what exactly it is about me and people like me that makes us valuable.
The most important question is who will get paid the most? I don't think the future of software engineering will be attractive if all you do is more work for same or even less pay. A second danger is too much reliance on AI tools will centralise knowledge and THAT is the scariest thing. Software systems will need to perform for a long time, having juniors on board and people who understand software architecture will be massively important. Or will all software crash when this generation retires?
69 comments
[ 2.6 ms ] story [ 74.6 ms ] threadIf I were starting out today, this is basically the only advice I would listen to. There will indeed be a vacuum in the next few years because of the drastic drop in junior hiring today.
Then also nothing has really changed. This was, verbatim, the advice everybody was giving when I was a grad student almost 20 years ago.
Back then, the conclusion was to learn the frameworks du jour, even if it was unfulfilling plumbing and the knowledge had a half-life of a few weeks. You needed it to get hired, but you made your career because of all the solid theory you learned and the adaptability that knowing it gave you.
Now, the conclusion is to learn how to tickle the models du jour in the right way, even though it's intellectually braindead, unaspiring work and knowledge with a half-life of a few days. It's still the theoretical foundation that will actually make the junior become a valuable engineer.
The more I read between the lines of AI evangelists' posts like this, the more I'm convinced that expectations will return to grounded reality soon. They are new tools to help the engineer. They enable new workflows and maybe can even allow a two-digit percentage increase in speed while upholding quality. But they're in no way a revolution that will make possible "10× engineers" or considerably replace engineering positions beyond the "it doesn't really matter" area of PoCs, prototypes, one-offs, cookie-cutter solutions, etc.
A humble way for devs to look at this, is that in the new LLM era we are all juniors now.
A new entrant with a good attitude, curiosity and interest in learning the traditional "meta" of coding (version control, specs, testing etc) and a cutting-edge, first-rate grasp of using LLMs to assist their craft (as recommended in the article) will likely be more useful in a couple of years than a "senior" dragging their heels or dismissing LLMs as hype.
We aren't in coding Kansas anymore, junior and senior will not be so easily mapped to legacy development roles.
In part, I think what people are responding to is the trajectory of the tools. I would agree that they seem to be on an asymptote toward being able to do a lot more things on their own, with a lot less direction. But I also feel like the improvements in that direction are incremental at this point, and it's hard to predict when or if there will be a step change.
But yeah, I'm really not sure I buy this whole thing about orchestrating a symphony of agents or whatever. That isn't what my usage of AI is like, and I'm struggling to see how it would become like that.
But what I am starting to see, is "non-programmers" beginning to realize that they can use these tools to do things for their own work and interests, which they would have previously hired a programmer to do for them, or more likely, just decided it wasn't worth the effort. I think for those people, it does feel like a novel automation tool. It's just that we all already knew how to do this, by writing code. But most people didn't know how to do that. And now they can do a lot more.
And I think this is a genuine step change that will have a big effect on our industry. Personally, I think this is ultimately a very good thing! This is how computers should work, that anybody can use them to automate stuff they want to do. It is not a given that "automating tasks" is something that must be its own distinct (and high paying) career. But like any disruption, it is very reasonable to feel concerned and uncertain about the future when you're right in the thick of it.
Many times, bad code is sufficient. Actually too many times: IMHO that is the reason why the software industry produces lower quality software every year. Bad products are often more profitable than good products. But it's not always for making bad products: sometimes it's totally fine to vibe code a proof or concept or prototype, I would say.
Other times, we really need stable and maintainable code. I don't think we can or want to vibe code that.
LLMs make low-quality coding more accessible, but I don't think they remove the need for high-quality coding. Before LLMs, the fraction of low-quality code was growing already, just because it was already profitable.
An analogy could be buildings: everybody can build a bench that "does the job". Maybe that bench will be broken in 2 months, but right now it works; people can sit on it. But not everybody can build a dam. And if you risk going to jail if your dam collapses, that's a good incentive for not vibe coding it.
Ah, there it is.
Curious about how the Specialist vs Generalist theme plays out, who is going to feel it more *first* when AI gets better over time?
This study showing 9-10% drop is odd[1] and I'm not sure about their identification critria.
> We identify GenAI adoption by detecting job postings that explicitly seek workers to implement or integrate GenAI technologies into firm workflows.
Based on that MIT study it seems like 90+% of these projects fail. So we could easily be seeing an effect where firms posting these GenAI roles are burning money on the projects in a way that displaces investment in headcount.
The point about "BigTech" hiring 50% fewer grads is almost orthogonal. All of these companies are shifting hiring towards things where new grads are unlikely to add value, building data centers and frontier work.
Moreover the TCJA of 2017 caused software developers to not count for R&D tax write offs (I'm oversimplifying) starting in 2022. This surely has more of an effect than whatever "GenAI integrator roles" postings correlates to.
[1] https://download.ssrn.com/2025/11/6/5425555.pdf
Where is all the new and improved software output we’d expect to see?
The question is, how much faster is verification only vs writing the code by hand? You gain a lot of understanding when you write the code yourself, and understanding is a prerequisite for verification. The idea seems to be a quick review is all that should be needed "LGTM". That's fine as long as you understand the tradeoffs you are making.
With today's AI you either trade speed for correctness or you have to accept a more modest (and highly project specific) productivity boost.
But when I don't have expertise, it's the same speed or even slower. The better I am at something, the faster the LLM coding goes.
I'm still trying to get better at Rust, and I'm past break-even now. So I could use LLMs for a speed boost. But I still hand-write all my code because I'm still gaining expertise. (Here I lean into LLMs in a student capacity, which is different.)
Related to this, I often ask LLMs for code reviews. The number of suggestions it makes that I think are good is inversely proportional to the experience I have with the particular tech used. The ability to discard bad suggestions is valuable.
This is why I think bring an excellent dev with the fundamentals is still important—critical, even—when coding with LLMs. If I were still in a hiring role, I'd hire people with good dev skills over people with poor dev skills every time, regardless of how adept they were at prompting.
1) The AI code maintainence question - who would maintain the AI generated code 2) The true cost of AI. Once the VC/PE money runs out and companies charge the full cost, what would happen to vibe coding at that point ?
They're still doing it.
Given how quickly models, tools and frameworks rise and fall, betting your career on a single technology stack is risky.
This was something I dealt with a lot when JS frameworks became the newest shiny thing and suddenly the entire industry shifted in a few years from being a front-end developer to being a full stack developer.
This happened to a lot of my friends who went all in on Angular. Then everybody switched to React.
The issue then became, "What should I learn?" because at my company (a large fortune 200 company) they were all in on Angular, and weren't looking for React developers, but I knew companies were moving away from Angular. So do I work to get better and more indispensable with Angular, and risk not knowing React? Or do I learn the new shiny framework betting at some point my company will adopt it or I will be laid off and need to know it?
It feels like half my life as a dev was spent being a degenerate gambler, always trying to hedge my bets in one way or another, constantly thinking about where everything was going. It was the same thing with dozens of other tools as well. It just became so exhausting trying to figure out where to put your effort into to make sure you always knew enough to get that next job.
As senior, if you choose, you can coast. By coast I mean you do justice to your job and the salary you are paid. Its a perfectly acceptable choice for someone to be senior for as long as they want.
The biggest bottleneck is going to be what other seniors and higher think of you.
Not everyone can afford it, and then we are at the point of changing the field that was so proud about just needing a computer and access to internet to teach oneself into a subscription service.
For the record, I was genuinely trying to read it properly. But it is becoming unbearable by mid article.
Now, it's expecting senior engineers to "orchestrate" 10 coding agents, then it was expecting them to orchestrate 10 cheap developers on the other side of the world. Then, the reckoning came when those offshore developers realised that if they produced code as good as that of a "1st world" engineer, they can ask a similar salary, too, and those offshoring clients who didn't want to pay up were left with those contractors who weren't good enough to do that. This time, it will be agent pricing approaching the true costs. Both times, the breaking point is when managers realise that writing code was never the bottleneck in the first place.
Engineers > developers > coders.
I’m not saying that this was prompted. I’m just summarizing it in my own way.
My value so far in my career has been my very broad knowledge of basically the entire of computer science, IT, engineering, science, mathematics, and even beyond. Basically, I read a lot, at least 10x more than most people it seems. I was starting to wonder how relevant that now is, given that LLMs have read everything.
But maybe I'm wrong about what my skill actually is. Everyone has had LLMs for years now and yet I still seem better at finding info, contextualising it and assimilating it than a lot of people. I'm now using LLMs too but so far I haven't seen anyone use an LLM to become like me.
So I remain slightly confused about what exactly it is about me and people like me that makes us valuable.