>Of course, the junior + AI pairing was tempting. It looked cheaper and played into the fear that “AI will take our jobs.”
Those are two different narratives. One implies that everyone will be able to code and build: "English as a programming language", etc. The other is one of those headless-chicken, apocalyptic scenarios where AI has already made (or will very shortly make) human programmers obsolete.
"AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
At the end of the day, companies will take any vaguely reasonable excuse to cull juniors and save money. It's just business. LLMs are simply the latest excuse, though yes, they do improve productivity, to varying degrees depending on what exactly you work on.
For the same reason that an amateur with a powertool ends up in the emergency room and a seasoned pro knows which way to point the business end. AI is in many ways a powertool, if you don't know what you are doing it will help you to do that much more efficiently. If you do know what you are doing it will do the same.
Supposedly in the US there are 25,000 emergency room visits per year for chainsaw injuries. Or that is what AI wants us to think, so it can take all the good chainsaw jobs.
Because it's too unpredictable so far. AI saves me time, but only because I could do everything it attempts to do myself.
It's wrong maybe 40-50% of the time, so I can't even imagine the disasters I'm averting by recognising when it's giving me completely bonkers suggestions.
I read, ages ago, this apocryphal quote by William Gibson: “The most important skill of the 21st century is to figure out which proper keywords to type in the Google search bar, to display the proper answers.”
To me, that has never been more true.
Most junior dev ask GeminiPiTi to write the JavaScript code for them, whereas I ask it for explanation on the underlying model of async/await and the execution model of a JavaScript engine.
There is a similar issue when you learn piano. Your immediate wish is to play Chopin, whereas the true path is to identify,name and study all the tricks there are in his pieces of art.
I agree, you need to know the "language" and the keywords of the topics that you want to work with. If you are a complete newcomer to a field then AI wont help you much. You have to tell the AI "assume I have A, B and C and now I want to do D" then it understands and tries to find a solution. It has a load of information stored but cannot make use of that information in a creative way.
Nailed it. Being productive with LLMs is very similar to the skill of being able to write good Google searches. And many many people still don't really know how to conduct a proper Google search...
The true path in Piano isn’t learning tricks. You start with the most basic pieces and work step by step up to harder ones. That’s how everyone I know has done in it my 26 years of playing. Tricks cheapens the actual music.
Chopin has beginners pieces too, many in our piano studio were first year pianists doing rain drop prelude, e minor prelude, or other beginner works like Bach.
Well, there is a big difference between wanting to just play Chopin and wanting to learn piano well enough to play anything on the current level including Chopin. There are people, who can play whole piano pieces mechanically, because they just learned where to position hands and what keys to press at a given time.
does it really? it lets seniors work more, but idk if its necessarily stronger.
i just soent some time cleaning up au code where it lied about the architecture so it wrote the wrong thing. the architecture is wonky, sure, but finding the wonks earlier would have been better
The challenge with AI, it will give you “good enough” output, without feedback loops you never move to 2,3,4 and assume you are doing ok. Hence it stunts learning. So juniors or inexperienced stay inexperienced, without knowing what they don’t know.
You have to Use it as an expert thinking partner. Tell it to ask you questions & not give you the answer.
Certainly not just coding. Senior designers and copywriters get much better results as well. It is not surprising, if context is one of the most important aspects of a prompt, then someone with domain experience is going to be able to construct better context.
Similarly, it takes experience to spot when the LLM is going in the wrong direction it making mistakes.
I think for supercharging a junior, it should be used more like a pair programmer, not for code generation. It can help you quickly gain knowledge and troubleshoot. But relying on a juniors prompts and guidance to get good code gen is going to be suboptimal.
In my experience AI is wikipedia/stackoverflow on steroids when I need to know something about a field I dont know much about. It has nice explanations and you can ask for examples or scenarios and it will tell you what you didnt understand.
Only when you know about the basic notions in the field you want to work with AI can be productive. This is not only valid for coding but also for other fields in science and humanities.
Some of the juniors I work with frequently point to AI output as a source without any verification. One crazy example was using it to do simple arithmetic, which they then took as correct (and it was wrong).
This is all a pretty well-trodden debate at this point though. AI works as a Copilot which you monitor and verify and task with specific things, it does not work as a pilot. It's not about junior or senior, it's about whether you want to use this thing to do your homework/write your essay/write your code for you or whether you use it as an assistant/tutor, and whether you are able to verify its output or not.
If you search back HN history to the beginnings of AI coding in 2021 you will find people observing that AI is bad for juniors because they can't distinguish between good and bad completions. There is no surprise, it's always been this way.
Also AI cannot draw conclusions like "from A and B follows C". You really have to point its nose into the result that you want and then it finally understands. This is especially hard for juniors because they are just learning to see the big picture. For senior who already knows more or less what they want and needs only to work out the nitty gritty details this is much easier. I dont know where the claims come from that AI is PHD level. When it comes to reasoning it is more like a 5 year old.
Pretty much, but it already starts at the prompting and context level.
Senior engineers either already know exactly where the changes need to be made and can suggest what to do.
They probably know the pitfalls, have established patterns, architectures and designs in their head.
Juniors on the other hand don't have that, so they go with whatever.
Nowadays a lot of them also "ask ChatGPT about its opinion on architecture" when told to refactor (a real quote from real junior/mid engineers), leading to either them using whatever sloppypasta they get provided.
Senior devs earned their experience of what is good/bad through writing code, understanding how hard and annoying it is to make a change, then reworking those parts or making them better the next time.
The feedback loop was impactful beacause it was based on that code and them working with that code, so they knew exactly what the annoying parts are.
Vibe-coding juniors do not know that, their conversation context knows that.
Once things get buggy and changes are hard, they will fill up their context with tries/retries until it works, leading to their feedback loop being trained on prompts and coding tools, not code itself.
Even if they read the outputted code, they have no experience using it so they are not aware of the issues - i.e. something would be better being a typed state, but they don't really use it so they will not care, as they do not have to handle the edge cases, they will not understand the DX from an IDE, they will not build a full mental model of how it works, just a shallow one.
This leads to insane inefficiencies - wasting 50 prompt cycles instead of 10, not understanding cross-codebase patterns, lack of learning transfer from codebase to codebase, etc.
With a minor understanding of state modeling and architecture, an vibe-coding junior can be made 100x more efficient, but due to the vibe-coding itself, they will probably never learn state modeling and architecture, learn to refactor or properly manipulate abstractions, leading to an eternal cycle of LLM-driven sloppypasta code, trained on millions of terrible github repositories, old outdated API's and stack overflow answers.
Uh because an LLM is a transfer function. Specifically a transfer function where the input has to be carefully crafted. And specifically where the output has to be carefully reviewed. Inexperienced people are good at neither of those things.
No one thought juniors would be more benefited than seniors. St some people some said everything would be automatic and seniors would disappear altogether with programming itself.
But that was just said by crappy influencers whose opinion doesn’t matter as they are impressed by examples result of overfitting
AI produces code that often looks really good, at a pace quicker than you can read it.
It can be really, really hard to tell when what it's producing is a bag of ** and it's leading you down the garden path. I've been a dev for 20 years (which isn't to imply I'm any good at it yet) and it's not uncommon I'll find myself leaning on the AI a bit too hard and then you realise you've lost a day to a pattern that wasn't right, or an API it hallucinated, in the first place.
It basically feels like I'm being gaslit constantly, even though I've changed my tools to some that feel like they work better with AIs. I expect it's difficult for junior devs to cope with that and keep up with senior devs, who normally would have offloaded tasks to them instead of AI.
One thing about AI that I did not anticipate is how useful it is for refactoring though. Like if I have walked down (with the help of an AI or not) a bad path, I can refactor the entire codebase to use a better strategy in much less time than before because refactoring is uniquely suited to AI - if you provide the framework, the design, the abstractions, AI can rewrite a bunch of code to use that new design. I'm frankly not sure if its faster than doing a refactor by hand, but its certainly less boring.
If you have good tests and a good sense for design and you know how to constrain and direct the AI, you can avoid a lot of boring work. That is something.
This is the crux of why I think AI code is a waste of time
It is much more difficult and time consuming to build a mental model of AI generated code and verify it than to build the damn thing yourself and verify it while it is fresh in your memory
The "junior + AI" idea always felt like a manager's fantasy more than an engineering reality. If you don’t already know what “good” looks like, it's really hard to guide AI output into something safe, maintainable, and scalable
no, AI is supposed to reduce the labor costs for companies. that is how the AI companies are marketing their AI services to corporate C teams. any other benefits that their marketing departments are pushing to the public are smoke screens.
130 comments
[ 3.4 ms ] story [ 94.4 ms ] threadThose are two different narratives. One implies that everyone will be able to code and build: "English as a programming language", etc. The other is one of those headless-chicken, apocalyptic scenarios where AI has already made (or will very shortly make) human programmers obsolete.
"AI taking jobs" means everyone's job. I won't even comment on the absurdity of that idea; to me, it only comes from people who've never worked professionally.
At the end of the day, companies will take any vaguely reasonable excuse to cull juniors and save money. It's just business. LLMs are simply the latest excuse, though yes, they do improve productivity, to varying degrees depending on what exactly you work on.
It's wrong maybe 40-50% of the time, so I can't even imagine the disasters I'm averting by recognising when it's giving me completely bonkers suggestions.
To me, that has never been more true.
Most junior dev ask GeminiPiTi to write the JavaScript code for them, whereas I ask it for explanation on the underlying model of async/await and the execution model of a JavaScript engine.
There is a similar issue when you learn piano. Your immediate wish is to play Chopin, whereas the true path is to identify,name and study all the tricks there are in his pieces of art.
Chopin has beginners pieces too, many in our piano studio were first year pianists doing rain drop prelude, e minor prelude, or other beginner works like Bach.
I have never heard that before
i just soent some time cleaning up au code where it lied about the architecture so it wrote the wrong thing. the architecture is wonky, sure, but finding the wonks earlier would have been better
1. Unconsciously incompetent
2. Consciously incompetent
3. Consciously competent
4. Unconsciously competent
The challenge with AI, it will give you “good enough” output, without feedback loops you never move to 2,3,4 and assume you are doing ok. Hence it stunts learning. So juniors or inexperienced stay inexperienced, without knowing what they don’t know.
You have to Use it as an expert thinking partner. Tell it to ask you questions & not give you the answer.
Similarly, it takes experience to spot when the LLM is going in the wrong direction it making mistakes.
I think for supercharging a junior, it should be used more like a pair programmer, not for code generation. It can help you quickly gain knowledge and troubleshoot. But relying on a juniors prompts and guidance to get good code gen is going to be suboptimal.
-techs they understand but still not master. AI aids with implementation details only experts knowb about
- No time for long coding tasks. It aids with fast implementations and automatic tests.
- No time for learning techs that adress well understood problems. Ai helps with quick intros, fast demos and solver of learners' misunderstandings
In essence, in seniors it impacts productivity
In the case of juniors AI fills the gaps too. But these are different from seniors' and AI does not excell in them because gaps are wider and broader
- Understand the problems of the business domain. AI helps but not that much.
- Understand how the organization works. AI is not very helpful here.
- Learn the techs to be used. AI helps but it doesn't know how to guide a junior in a specific organisational context and specific business domain.
In essence it helps, but not that much because the gaps are wider and more difficult to fill
Only when you know about the basic notions in the field you want to work with AI can be productive. This is not only valid for coding but also for other fields in science and humanities.
This is all a pretty well-trodden debate at this point though. AI works as a Copilot which you monitor and verify and task with specific things, it does not work as a pilot. It's not about junior or senior, it's about whether you want to use this thing to do your homework/write your essay/write your code for you or whether you use it as an assistant/tutor, and whether you are able to verify its output or not.
Edit interesting thread: https://news.ycombinator.com/item?id=27678424
Edit: an example of the kind of comment I was talking about: https://news.ycombinator.com/item?id=27677690
Senior engineers either already know exactly where the changes need to be made and can suggest what to do. They probably know the pitfalls, have established patterns, architectures and designs in their head. Juniors on the other hand don't have that, so they go with whatever. Nowadays a lot of them also "ask ChatGPT about its opinion on architecture" when told to refactor (a real quote from real junior/mid engineers), leading to either them using whatever sloppypasta they get provided.
Senior devs earned their experience of what is good/bad through writing code, understanding how hard and annoying it is to make a change, then reworking those parts or making them better the next time. The feedback loop was impactful beacause it was based on that code and them working with that code, so they knew exactly what the annoying parts are.
Vibe-coding juniors do not know that, their conversation context knows that. Once things get buggy and changes are hard, they will fill up their context with tries/retries until it works, leading to their feedback loop being trained on prompts and coding tools, not code itself.
Even if they read the outputted code, they have no experience using it so they are not aware of the issues - i.e. something would be better being a typed state, but they don't really use it so they will not care, as they do not have to handle the edge cases, they will not understand the DX from an IDE, they will not build a full mental model of how it works, just a shallow one.
This leads to insane inefficiencies - wasting 50 prompt cycles instead of 10, not understanding cross-codebase patterns, lack of learning transfer from codebase to codebase, etc.
With a minor understanding of state modeling and architecture, an vibe-coding junior can be made 100x more efficient, but due to the vibe-coding itself, they will probably never learn state modeling and architecture, learn to refactor or properly manipulate abstractions, leading to an eternal cycle of LLM-driven sloppypasta code, trained on millions of terrible github repositories, old outdated API's and stack overflow answers.
But that was just said by crappy influencers whose opinion doesn’t matter as they are impressed by examples result of overfitting
It can be really, really hard to tell when what it's producing is a bag of ** and it's leading you down the garden path. I've been a dev for 20 years (which isn't to imply I'm any good at it yet) and it's not uncommon I'll find myself leaning on the AI a bit too hard and then you realise you've lost a day to a pattern that wasn't right, or an API it hallucinated, in the first place.
It basically feels like I'm being gaslit constantly, even though I've changed my tools to some that feel like they work better with AIs. I expect it's difficult for junior devs to cope with that and keep up with senior devs, who normally would have offloaded tasks to them instead of AI.
If you have good tests and a good sense for design and you know how to constrain and direct the AI, you can avoid a lot of boring work. That is something.
Like 19% weaker, according to the only study to date that measured their productivity.
That’s the whole issue in a nutshell.
Can the output of a generative system be verified as accurate by a human (or ultimately verified by a human)
Experts who can look at an output and verify if it is valid are the people who can use this.
For anyone else it’s simply an act of faith, not skill.
It is much more difficult and time consuming to build a mental model of AI generated code and verify it than to build the damn thing yourself and verify it while it is fresh in your memory