If you want to move extremely fast in development/programming, you are right that you are better off with a good senior with Max Plan. But running a company/startup is not just about writing code. So the question is not about junior vs senior but about what type of humans you want to hire to help grow the startup. Start there.
> A senior with Max plan beats three junior hires (very rough estimate).
If you have seniors doing the job of juniors, you will soon have no seniors either. If you have a senior doing the job of 3 juniors (which is different than doing 3x kind of tasks), then your senior will burn out and leave as well.
Also, as senior I enjoy working with juniors because I like to teach and share (with seniors that’s also possible but happens way less often).
Working in a team of full senior+ engineers is not fun (in regular companies I mean): too much ego, politics, bias… no open to change
It's not about junior vs senior. it's about hiring a competent developer. There are competent junior developers and there's plenty of useless seniors. Besides these, what you are building matters. If you are not dealing with hard tech, then a junior with a model could level up fast. If you are building complex hard tech then experience matters a lot for judgement, however some juniors could still keep up. The bar is at an all time high, but for everyone, seniors as well.
This is a story that cheap employers tell. Hire for “growth potential” in order to save $50k, and in return the rest of the team is taxed for many quarters, results are mid at best.
Of course it is true that some juniors outperform competent seniors. It’s also true some seniors are just checked out. But when you are willing to hire folks with meaningful years of experience, you get meaningfully better velocity and quality. It doesn’t matter how simple or complex the problem is.
Why would a senior with meaningful years of experience would like to do junior tasks? Most companies out there have a good mix of challenging and chore tasks. Seniors are best used in challenging tasks. Juniors help seniors in chores (and learn how challenging tasks are done as well)
Hi fellow founder here, just sharing some thoughts. Agree that with AI more eng work can now be handled by a senior dev but a good junior dev using AI is also more capable than ever. I think with a good process in place, you can ramp up a junior dev sooner rather than later. And as good as AI is, there's still a human bottleneck, so I'd assess the quantity of work you have vs. the technical complexity
I just meant that even a senior dev can only manage a finite number of tasks at a time, even if AI is doing the work. So if everyone's plates are full, then maybe some of the work can be offloaded to junior devs. However, if you feel like the work is not suitable for junior devs, then maybe you need more senior devs.That being said, I wouldn't look at it as simply as senior dev = 3x junior dev. Of course, it depends on the work you have, your hiring talent pool, etc.
It's a tough time to make those decisions. I really don't know what juniors will do. Continuity is a real cost, but a long term one. So, early on definitely doesn't make sense, especially when you are laying a foundation. But afterwards, you have to have some form of continuity to maintain the product and the cheapest and best way would be to bring on young talent.
Just because you are a founder, does not mean you "are" the company. To build culture as a company, you need people to "grow up" within said company. To be sustainable for a long term, it's more important to have a team that is familiar with your company, the way you do things and the issues you encounter along the way. Someone "growing up" in your company will be way more valuable long term. Sure, you might say a senior dev will be able to grow much the same way but
1. He will cost more upfront
2. He might have (justifiably) have higher standards of his own and leave you for a better offer
3. He will be less flexible in trying out new things
Those are generalizations but in my experience, once the 5-Year mark passes, a junior is pretty much always a better colleague than a senior.
This is not to say that you should not hire seniors but you need a good mix of trainers and trainees. Training employees can also make a senior much more effective at his own job.
What juniors are sticking around at 5 years? The market reality is they can likely 1.5x-2x their pay by switching jobs, unless they started at FAANG or some other ultra high paying co
It's much harder to switch jobs right now, especially for junior and midlevel devs. Maybe things will turnaround in another few years and we'll be back to 2 year job hoppers again.
"Training employees can also make a senior much more effective at his own job."
And a good junior will ask questions in a design/architecture session that an AI likely wouldn't. This is a good thing to get the group thinking. It also seems that people tend to have better business context than the AIs.
A senior engineer would always be able to out engineer a junior engineer, the point of hiring junior engineers was always that you could pay them less than a senior and hopefully keep them on board with your company and develop into leadership or a more proficient engineer. In addition, newer employees end up bringing fresh perspectives and keep the company from eating itself while also being more malleable and likely to go along with what you think are best practices. I am still wrestling with the way that software engineering will work in the long term with AI, but I feel like the value proposition of hiring juniors hasn't really changed.
Is the expectation here that anyone getting into software engineering has to become a senior on their own now? I don't really understand how this line of thinking is sustainable in the long run.
So the real challenge here is to define appropriate expectations for a junior. You could do what everyone else does and throw react at them and walk away disappointed that they can’t program. Or, you can set higher expectations than the industry norms knowing they will stumble hard for a while until they figure it out and produce superior results. It’s a balance between tolerance for risk versus shitty developers/ai
It sounds like you want to hire people to just be your fingers, and not build a team of people who care about what they’re trying to do, and who find and solve problems you aren't aware of. LLMs are not good at solving meta problems like this, teams are.
If you’re the type of person or company that would hire an outsourced team overseas without hesitation, then LLMs would probably be fine for you.
I'd wager a Junior engineer has the same capability to become versed in AI technology software delivery workflows is just as capable of learning and maybe more capable of thinking with the mindset of all the new LLM tooling than someone who, though capable, may not be amenable to learning yet another set of tools.
Hire them, you're gut is questioning your rational brain for good reason.
The future of OpenAI and Anthropic is contingent on a lot of factors which can (and maybe will) just vanish overnight. If China "invades" Taiwan, or if the data center buildouts completely stall, AI is going to be in a very precarious spot.
> So far, I'm really struggling to see the value add of a junior engineer given how good the models have become. A senior with Max plan beats three junior hires (very rough estimate).
A single staff-level engineer with 4 concurrent agents on a Max plan replaces 4 seniors and 12 junior hires.
It's okay to say that we want don't need to hire any human programmers anymore since they are the bottleneck. But the strong disadvantage is that these agents need humans to tell them what to do.
If you think otherwise, look no further than the Huggingface hack and what happens when they run completely autonomously. Not only that is a waste of tokens, it can cause you to be legally liable for damages if something terrible happens.
This question fully captures my two main problems with the current AI-fanaticism. I've said it a million times: writing code was never the hard part and in my world has always been the most enjoyable part of software.
First, to me, the two major differences between a junior and a senior developer are(or used to be, I'll get to that in a bit):
1. Intuition: software is all about compromise and knowing when you can, should and should not cut corners and at what cost really is, to a very high degree, intuition(and some auxilary technical knowledge).
2. Domain knowledge.
Both come from, you guessed it, experience.
The second part is junior developers in general - from what I see, they are commonly completely detached from reading and writing code. Currently Gen-Z are entering the workforce. For many of them(vast majority), cut off their connection to the internet and they struggle with a simple while loop. And they look horrified when I tell them that 15 years ago, we were writing code - SVMs on a sheet of paper as exams. Same goes for all the people who said "oh well, no need to write the code if the AI can do it for me". Seeing people with two decades of experience turn into idiocracy characters is painful. Like in a year I see the seniors revert back into what juniors are today - completely incapable of formulating and facing a problem without an LLM on their side. And worse still - they will never admit it but I see how much they stop being passionate and just roll with everything.
The other thing to consider is burnout: take a senior that understands your service or product completely: in a real world scenario you know that no system is ever going to be perfect. You can only push someone so far with mountains of small, medium and large tasks and tell them "what's the big deal, you have unlimited slop max pro"? The big deal is small and trivial tasks which, with or without AI, require context switching which is exhausting. It's not a question of "if" but "when" will your senior get burned out and toss everything at slop max pro++ and just collect a paycheck for as long as the company is around or something better pops up. And in that same context - if you come to me with 5 jira tickets and tell me they have to be done by the end of the day, do I really have the time and mental strength to pay close attention to all of them or just be like "hey slop, see this ticket? do it? when tests pass, deploy". At this point, my question is, am I a senior developer if I was practically never in the loop of what was done?
Not a founder but have 20+ years experience in code and 7 before that in design and build of data center blade tech back when that was still kind of new; been in engineering a while
And yeah... have seen all the jargons come and go. DOS, Novell, Windows NT, xml, soap, next, BSD had a moment, chef and yada yada...the vague hand wavy semantics to 2010s web saas will not be spared
The most common shared cross continent language for whats going on is math... stats of state of memory registers
The jargons conjured up on the fly to do office work 30+ years ago all fade away; how many startups went all in on COBOL during the RoR era?
So yeah; hard pressed to recommend tethering juniors to useless jargon as we have most of my career.
I'm junior engineer myself, 22, just graduated from a bachelor degree in AI, and I think that one junior can beat a senior with a Max plan.
I think it all comes down to what the they did during their studies and how they've spent their time. So I'd judge them based on the things they've built and their experience using AI tools. These days you literally have top US companies like Sierra asking their candidates to vibe coding a project as the coding interview.
I personally spent a lot of time and money building with Claude Code and Cursor. Probably more than you would at most companies, especially an intern: full days (weekends included) and about $5,000 in 2 years on tokens. During my sophomore year, I went so hard building agents with AI, I skipped all my classes and barely passed my subject, which got me Tier-1 VC inbounds. So the junior engineers in their early 20s can be more proficient than senior devs.
If you want to move extremely fast in development/programming, you are right that you are better off with a good senior with Max Plan. But running a company/startup is not just about writing code. So the question is not about junior vs senior but about what type of humans you want to hire to help grow the startup. Start there.
> A senior with Max plan beats three junior hires (very rough estimate).
If you have seniors doing the job of juniors, you will soon have no seniors either. If you have a senior doing the job of 3 juniors (which is different than doing 3x kind of tasks), then your senior will burn out and leave as well.
Also, as senior I enjoy working with juniors because I like to teach and share (with seniors that’s also possible but happens way less often). Working in a team of full senior+ engineers is not fun (in regular companies I mean): too much ego, politics, bias… no open to change
It's not about junior vs senior. it's about hiring a competent developer. There are competent junior developers and there's plenty of useless seniors. Besides these, what you are building matters. If you are not dealing with hard tech, then a junior with a model could level up fast. If you are building complex hard tech then experience matters a lot for judgement, however some juniors could still keep up. The bar is at an all time high, but for everyone, seniors as well.
This is a story that cheap employers tell. Hire for “growth potential” in order to save $50k, and in return the rest of the team is taxed for many quarters, results are mid at best.
Of course it is true that some juniors outperform competent seniors. It’s also true some seniors are just checked out. But when you are willing to hire folks with meaningful years of experience, you get meaningfully better velocity and quality. It doesn’t matter how simple or complex the problem is.
Why would a senior with meaningful years of experience would like to do junior tasks? Most companies out there have a good mix of challenging and chore tasks. Seniors are best used in challenging tasks. Juniors help seniors in chores (and learn how challenging tasks are done as well)
The chores are mostly done by AI now. Communicating with a jr is probably the lowest reward task of a senior nowadays.
At an early stage startup, like OP is asking about, you can expect engineers to do everything.
Hi fellow founder here, just sharing some thoughts. Agree that with AI more eng work can now be handled by a senior dev but a good junior dev using AI is also more capable than ever. I think with a good process in place, you can ramp up a junior dev sooner rather than later. And as good as AI is, there's still a human bottleneck, so I'd assess the quantity of work you have vs. the technical complexity
Thanks for sharing. Do you have a few examples of these human bottlenecks where a junior engineer is apt?
I just meant that even a senior dev can only manage a finite number of tasks at a time, even if AI is doing the work. So if everyone's plates are full, then maybe some of the work can be offloaded to junior devs. However, if you feel like the work is not suitable for junior devs, then maybe you need more senior devs.That being said, I wouldn't look at it as simply as senior dev = 3x junior dev. Of course, it depends on the work you have, your hiring talent pool, etc.
It's a tough time to make those decisions. I really don't know what juniors will do. Continuity is a real cost, but a long term one. So, early on definitely doesn't make sense, especially when you are laying a foundation. But afterwards, you have to have some form of continuity to maintain the product and the cheapest and best way would be to bring on young talent.
Just because you are a founder, does not mean you "are" the company. To build culture as a company, you need people to "grow up" within said company. To be sustainable for a long term, it's more important to have a team that is familiar with your company, the way you do things and the issues you encounter along the way. Someone "growing up" in your company will be way more valuable long term. Sure, you might say a senior dev will be able to grow much the same way but 1. He will cost more upfront 2. He might have (justifiably) have higher standards of his own and leave you for a better offer 3. He will be less flexible in trying out new things
Those are generalizations but in my experience, once the 5-Year mark passes, a junior is pretty much always a better colleague than a senior.
This is not to say that you should not hire seniors but you need a good mix of trainers and trainees. Training employees can also make a senior much more effective at his own job.
> once the 5-Year mark passes
What juniors are sticking around at 5 years? The market reality is they can likely 1.5x-2x their pay by switching jobs, unless they started at FAANG or some other ultra high paying co
It's much harder to switch jobs right now, especially for junior and midlevel devs. Maybe things will turnaround in another few years and we'll be back to 2 year job hoppers again.
"Training employees can also make a senior much more effective at his own job."
And a good junior will ask questions in a design/architecture session that an AI likely wouldn't. This is a good thing to get the group thinking. It also seems that people tend to have better business context than the AIs.
A senior engineer would always be able to out engineer a junior engineer, the point of hiring junior engineers was always that you could pay them less than a senior and hopefully keep them on board with your company and develop into leadership or a more proficient engineer. In addition, newer employees end up bringing fresh perspectives and keep the company from eating itself while also being more malleable and likely to go along with what you think are best practices. I am still wrestling with the way that software engineering will work in the long term with AI, but I feel like the value proposition of hiring juniors hasn't really changed.
Is the expectation here that anyone getting into software engineering has to become a senior on their own now? I don't really understand how this line of thinking is sustainable in the long run.
So the real challenge here is to define appropriate expectations for a junior. You could do what everyone else does and throw react at them and walk away disappointed that they can’t program. Or, you can set higher expectations than the industry norms knowing they will stumble hard for a while until they figure it out and produce superior results. It’s a balance between tolerance for risk versus shitty developers/ai
It sounds like you want to hire people to just be your fingers, and not build a team of people who care about what they’re trying to do, and who find and solve problems you aren't aware of. LLMs are not good at solving meta problems like this, teams are.
If you’re the type of person or company that would hire an outsourced team overseas without hesitation, then LLMs would probably be fine for you.
I'd wager a Junior engineer has the same capability to become versed in AI technology software delivery workflows is just as capable of learning and maybe more capable of thinking with the mindset of all the new LLM tooling than someone who, though capable, may not be amenable to learning yet another set of tools.
Hire them, you're gut is questioning your rational brain for good reason.
The future of OpenAI and Anthropic is contingent on a lot of factors which can (and maybe will) just vanish overnight. If China "invades" Taiwan, or if the data center buildouts completely stall, AI is going to be in a very precarious spot.
> So far, I'm really struggling to see the value add of a junior engineer given how good the models have become. A senior with Max plan beats three junior hires (very rough estimate).
A single staff-level engineer with 4 concurrent agents on a Max plan replaces 4 seniors and 12 junior hires.
It's okay to say that we want don't need to hire any human programmers anymore since they are the bottleneck. But the strong disadvantage is that these agents need humans to tell them what to do.
If you think otherwise, look no further than the Huggingface hack and what happens when they run completely autonomously. Not only that is a waste of tokens, it can cause you to be legally liable for damages if something terrible happens.
This question fully captures my two main problems with the current AI-fanaticism. I've said it a million times: writing code was never the hard part and in my world has always been the most enjoyable part of software.
First, to me, the two major differences between a junior and a senior developer are(or used to be, I'll get to that in a bit):
1. Intuition: software is all about compromise and knowing when you can, should and should not cut corners and at what cost really is, to a very high degree, intuition(and some auxilary technical knowledge). 2. Domain knowledge.
Both come from, you guessed it, experience.
The second part is junior developers in general - from what I see, they are commonly completely detached from reading and writing code. Currently Gen-Z are entering the workforce. For many of them(vast majority), cut off their connection to the internet and they struggle with a simple while loop. And they look horrified when I tell them that 15 years ago, we were writing code - SVMs on a sheet of paper as exams. Same goes for all the people who said "oh well, no need to write the code if the AI can do it for me". Seeing people with two decades of experience turn into idiocracy characters is painful. Like in a year I see the seniors revert back into what juniors are today - completely incapable of formulating and facing a problem without an LLM on their side. And worse still - they will never admit it but I see how much they stop being passionate and just roll with everything.
The other thing to consider is burnout: take a senior that understands your service or product completely: in a real world scenario you know that no system is ever going to be perfect. You can only push someone so far with mountains of small, medium and large tasks and tell them "what's the big deal, you have unlimited slop max pro"? The big deal is small and trivial tasks which, with or without AI, require context switching which is exhausting. It's not a question of "if" but "when" will your senior get burned out and toss everything at slop max pro++ and just collect a paycheck for as long as the company is around or something better pops up. And in that same context - if you come to me with 5 jira tickets and tell me they have to be done by the end of the day, do I really have the time and mental strength to pay close attention to all of them or just be like "hey slop, see this ticket? do it? when tests pass, deploy". At this point, my question is, am I a senior developer if I was practically never in the loop of what was done?
hire them. that's my thought.
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
Not a founder but have 20+ years experience in code and 7 before that in design and build of data center blade tech back when that was still kind of new; been in engineering a while
And yeah... have seen all the jargons come and go. DOS, Novell, Windows NT, xml, soap, next, BSD had a moment, chef and yada yada...the vague hand wavy semantics to 2010s web saas will not be spared
The most common shared cross continent language for whats going on is math... stats of state of memory registers
The jargons conjured up on the fly to do office work 30+ years ago all fade away; how many startups went all in on COBOL during the RoR era?
So yeah; hard pressed to recommend tethering juniors to useless jargon as we have most of my career.
I'm junior engineer myself, 22, just graduated from a bachelor degree in AI, and I think that one junior can beat a senior with a Max plan.
I think it all comes down to what the they did during their studies and how they've spent their time. So I'd judge them based on the things they've built and their experience using AI tools. These days you literally have top US companies like Sierra asking their candidates to vibe coding a project as the coding interview.
I personally spent a lot of time and money building with Claude Code and Cursor. Probably more than you would at most companies, especially an intern: full days (weekends included) and about $5,000 in 2 years on tokens. During my sophomore year, I went so hard building agents with AI, I skipped all my classes and barely passed my subject, which got me Tier-1 VC inbounds. So the junior engineers in their early 20s can be more proficient than senior devs.
First piece of advice, for free: it’s not about beating each other.
[dead]