So really the same two skills that a senior engineer needs to delegate tasks to juniors & review the results..
Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.
Disagree. Some learn, not all and decreasing numbers career to learn
Also most juniors have no idea how to write tests, plan for data scale, know which IPC-RPC combo is best for prototyping vs production
Etc…
90% of software is architecture and juniors don’t architect
Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.
Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?" For me, not much! Others may differ. In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
> In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
And mostly their output is not really about incorrect code, but more likely incorrect approaches. By reviewing their code, you find gaps in their knowledge which you can then correct. They're here to learn, not to produce huge amount of code. The tasks are more for practice and evaluation than things you critically need.
I don't want to work with a junior, but I'm more than happy to guide them to be someone I can work with.
Agreed on that point, and my question for a lot of the AI bros has been "what would you actually do with unlimited interns who never improve much?" For me, not much! Others may differ. In my own experience interns are a net drag. New college hires flip positive after 3-6 months.. if they are really good. Many takes upwards of a year.
I do agree that "unlimited interns who don't improve much" is less practically useful than it might seem at first, but OTOH "never improve much" seems unrealistic, given the insane progress of the field in the last 3ish years (or think back 5 years and tell me who was realistically predicting tools like Claude Code to even exist by 2025). Also, there's a decently large subset of small startups where there's 1 technic…
> Also, there's a decently large subset of small startups where there's 1 technical founder and a team of contract labor, trying to build that first MVP or cranking out early features in a huge rush to stay alive, where yeah, cheap unlimited interns might actually be meaningfully useful or economically more attractive than whatever they're doing now
That's when experienced developers are a huge plus. They know how to cut corners in a way that will not hurt that much in the long term. It's more often intern level that are proposing stuff like next.js, kubernetes, cloud-native,... that will grind you to a halt once the first bugs appear.
A very small team of good engineers will get you much further than any army of intern level coders.
This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…
This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…
What the heck, the code generation _is_ absolutely still a bottle-neck. I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have so…
> Yesterday almost my whole day was wasted because I chose to attack a problem primarily by using Claude 4 Sonnet
I have been extremely cynical about LLMs up until Claude 4. For the specific project I've been using it on, it's done spectacularly well at specific asks - namely, performance and memory optimization in C code used as a Python library.
This echoes my experience with Claude Code. The bottleneck isn't the code generation itself—it's two critical judgment tasks: 1. Problem decomposition: Taking a vague idea and breaking it down into well-defined, context-bounded issues that I can effectively communicate to the AI 2. Code review: Carefully evaluating the generated code to ensure it meets quality standards and integrates properly Both of these require d…
That's a narrow view of the issue described in the blog post. You're coming at this from the perspective of a software engineer, which is understandable given the website we're posting on, but the post is really focusing on something higher level - the ability to decide whether the problems you're decomposing and the code you're reviewing is for something "good" or "worthwhile" in the first place. Claude could "decompose problems" and "review code" 10x better than it currently does, but if the thing it's making is useless, awkward, or otherwise bad (because of prompts given by people without the qualities in the blog post), it won't matter.
Have people noticed the ai-assisted code "creep"? Cursor now by default applies its changes before you've even hit accept, and the tab autocomplete is getting out of control. Sometimes I'll have my cursor resting on some block of code, then suddenly Cursor suggests I delete the whole thing.
Nope, dealing with juniors is way less frustrating because they learn. So overtime, you can increase the complexity of their tasks until they're no longer junior.
Disagree. Some learn, not all and decreasing numbers career to learn Also most juniors have no idea how to write tests, plan for data scale, know which IPC-RPC combo is best for prototyping vs production Etc… 90% of software is architecture and juniors don’t architect
> Disagree. Some learn, not all and decreasing numbers career to learn
This is an organizational issue then—someone who is operating at a junior level who demonstrates that they don’t care to learn should be let go.
In software, we promote good engineers to management, effectively accelerating the Peter Principle. It doesn't have to be that way. Management skills are not an outgrowth of the skills of the managed, but orthogonal to them. This is similar to the lesson many PhD candidates I've known learn: expertise in their field is not pedagogical expertise. Companies who promoted from within used to provide training for new mana…
> In software, we promote good engineers to management i've not seen this. Infact its the opposite.
You've seen good managers promoted to engineers? ;)
I have seen this happening, usually the engineers with the best technical AND people skills are first made lead developer, and eventually "team lead". After team lead they can climb the corporate ladder with titles like "junior vice president" or "senior director".
What the heck, the code generation _is_ absolutely still a bottle-neck. I dare anyone who making these arguments that LLMs have removed the need for actual programming skill, for example, to share in a virtual pair programming session with me, and I will demonstrate their basic inability to do _any_ moderately complex coding in short order. Yes, I think that's the only way to resolve this controversy. If they have so…
Indeed. All this “productivity” has not resulted in one meaningful open source PR or one interesting indie app launch, and I can’t square my own experience with the hype machine. If it’s not all hat and no cattle, someone should be able to show me some cows.
I find this hard to believe- how would you even know if someone used AI in producing a PR or indie product? Are you omniscient?
Further, there are articles here on HN all the time about people using AI for actual serious work. Heres a pretty significant example :