Very well explained. Thank you for sharing. The insights that I share with my team and followers match with some of the ones highlighted. Others are additional for me, personally.
> Formal computer science education didn’t exist until 1962, when Purdue established the first department. The first undergraduate degree followed in 1967.
As a senior engineer with over 20 years of experience, I couldn't agree more with your concept of 'scar tissue.' AI can provide answers, but it cannot provide the gut feeling that comes from staying up at 3 AM to fix a production failure you caused. If we don't allow juniors to fail safely today, we are effectively de-skilling the workforce of 2035. Judgment is earned, not prompted.
Who are those senior engineers? Is it like the Senior Artist of the Cavemen? There is going to be no coding at all, its completely solved. Now Software development becomes like Chemistry. You add sufficient amount of words explaining your problem, and you get result of varying degrees. We may have different role akin to Senior Chemist - something like Senior Prompter who will not need any of the skills of a Senior Engineer.
One thing that stood out to me is the importance of ownership early on. Not just small tasks, but real responsibility ideally in an environment where failure is acceptable.
Paired with experienced seniors who provide frameworks, that seems like a powerful combination:
learning not only how to think through problems, but also to find your personal way of doing things.
Curious how you’ve seen this work (or fail ) in practice?
I think where it works best is where a junior owns something that somebody senior would otherwise. Then they work together to think through the solution and the trade-offs involved in training the judgement component. After that, they implement the solution together. The amount that the junior leads kind of depends on where they are in their ramping up process, so it depends on the person and the moment in time.
I think this approach fails when delegation is not done properly. A senior is not mentoring them effectively, instead just assigning tasks with no support, which means handing over responsibility without scaffolding or a feedback loop. Yes, some juniors will survive, but others will have a bad experience because it feels like sink or swim.
The connection between all of that is that you need senior engineers who are motivated to coach well, and their performance is judged on it, so they are incentivized to do it.
Thanks for the question! Since you asked you already know it's harder, but:
- Try to put together a portfolio of work (i.e. on GitHub or similar) that shows what you can do, with or without AI, but don't hide AI usage as your own. Instead show how much you can do with it and what your cool ideas are.
- See if you can write online about what you're building or learning (or both) so you can start a build a presence up for yourself.
- Target companies that are investing in juniors, i.e. those doing intern programs, or if there are companies you particularly like, reach out to them regardless to see if they have any opportunities.
The easiest way might be to invert the question: if you were hiring a junior, what would make them stand out? Then do that.
I like the idea of treating juniors as a strategic bet, but honestly I’m struggling to see which tasks I should give a junior today instead of just using AI plus one senior. For most classic junior work (small features, bugfixes, glue code), AI already feels faster and cheaper once you factor in mentoring time.
Do you have concrete examples of work you’d deliberately assign to a junior (and not AI), where the long‑term learning and organisational value clearly justifies the short‑term productivity hit?
I think measuring a junior’s output isn’t really the thing here though; of course AI will likely do a better job, so I think that angle has too much focus on the short term (i.e. getting stuff done ASAP).
Instead the focus should be on where the experience of doing the task is the point so that someone learns and gets better, which is a focus on the long term (i.e. that person developing).
The article talks about earning that scar tissue through practice, so there are still plenty of places for juniors to do that, even with AI assistance:
Owning features end to end, so not just writing the code (themselves or with AI) but QAing it, shipping it and monitoring it in production too.
Being on call (or paired on call) for incidents and investigating and fixing issues.
Work that requires debating or negotiating with other teams (i.e. a bug fix that will change behaviour in other parts of the software that their team doesn’t own).
Lots of pull request review (with or without AI assistance) to increase critical thinking skills.
okay - let me put on my Devil's Advocate hat and ask this question: What if I am an evil big boss and I just wanna get the most out from the employee ASAP, and I don't care about their long term growth as they will hop to another job within 2-3 years anyway? If that is the case, isn't AI always better as that would always stay within the company as an asset?
Hi Yash, I did try to speak to this: the opening notes it's a hard time to be graduating with a CS degree, and the final section has an "If you're early in your career" part with three concrete things to do.
That being said, you've put your finger on something the article doesn't explicitly tackle: how do you break in in the first place, when entry-level postings have dropped so sharply? That probably deserves its own article.
I’ve been reflecting on your piece regarding the senior engineers of 2035. The "scar tissue" analogy is a brilliant way to describe technical judgment, but I’d like to offer an observation from my perspective in the current tech landscape.
Sometimes we tend to overlook that, even before AI, much of our "craft" involved curating solutions from StackOverflow. The difference today is simply that the abstraction layer is more fluid. However, the most critical factor I see is the evolution of AI reasoning. In 2026, we are no longer dealing with simple text generators, but with models that audit logic and explain the "why" through complex reasoning processes.
My observation is that the judgment gap might not be closed through the traditional passage of years, but through augmented experience. If a junior can use reasoning agents to simulate incidents and deconstruct architectures in a matter of months, aren’t we witnessing a new form of "simulated scar tissue"? Perhaps seniority in 2035 won't be defined by having made the mistake manually, but by the ability to oversee and direct an AI that is already capable of reasoning through those same mistakes.
I’d love to hear your thoughts on whether seniority is truly a matter of accumulated time, or if the density of AI-assisted learning could redefine the timeline of a technical career.
You’re right that we often overlooked the programming before AI. It wasn’t 100% intuition-driven or built from first principles, and we often copied solutions that already existed. That's a very good point.
Expanding on that, we could say that before AI, there were two types of people:
1. Those who challenged themselves to work things out through their own reasoning, using reference materials as needed (i.e. "I'll try, but then I'll check StackOverflow.").
2. Those who blindly copied and pasted without really learning anything.
AI compresses that somewhat in a faster loop.
What you've suggested as a solution is really interesting. I wonder whether there’s a market for AI-driven tools that can provide synthetic education for new engineers, helping them learn faster than they would on the job. For example, simulated incidents, architecture design, and critique. It sounds like you might have just come up with a startup idea. Now go, quickly, before somebody else reads it!
Yeah, the options are wide... but focus on whatever you need to do in order to move towards a senior engineer then do more of that (and ask for opportunities to do that if you aren't getting them by default). If your company doesn't have career tracks then you can find examples of what is expected at senior levels on websites like progression.fyi.
These are things like:
- Shipping really impactful work again and again
- Working out how to use AI to do more of the above faster and more efficiently with time by automating more
- Coaching and mentoring juniors
- Being able to link your work to dollars, either through saving dollars by speeding up the system, or making your customers happier
- Stepping into areas you don't usually already by using AI, such as doing frontend work if you're usually a backend engineer, or vice versa
The floor is rising, but the ceiling is expanding.
Very well explained. Thank you for sharing. The insights that I share with my team and followers match with some of the ones highlighted. Others are additional for me, personally.
Thank you for the kind comment!
> Formal computer science education didn’t exist until 1962, when Purdue established the first department. The first undergraduate degree followed in 1967.
Cambridge had a masters level degree in 1953...
OK, fixed. Added the link to the Cambridge diploma, and tightened the sentence to mention the Purdue /department/. Thank you again for the callout!
Wow, I had no idea. Let me update the article.
As a senior engineer with over 20 years of experience, I couldn't agree more with your concept of 'scar tissue.' AI can provide answers, but it cannot provide the gut feeling that comes from staying up at 3 AM to fix a production failure you caused. If we don't allow juniors to fail safely today, we are effectively de-skilling the workforce of 2035. Judgment is earned, not prompted.
Who are those senior engineers? Is it like the Senior Artist of the Cavemen? There is going to be no coding at all, its completely solved. Now Software development becomes like Chemistry. You add sufficient amount of words explaining your problem, and you get result of varying degrees. We may have different role akin to Senior Chemist - something like Senior Prompter who will not need any of the skills of a Senior Engineer.
Hi James,
really enjoyed reading this!
One thing that stood out to me is the importance of ownership early on. Not just small tasks, but real responsibility ideally in an environment where failure is acceptable.
Paired with experienced seniors who provide frameworks, that seems like a powerful combination:
learning not only how to think through problems, but also to find your personal way of doing things.
Curious how you’ve seen this work (or fail ) in practice?
Hey, I'm pleased you enjoyed it.
I think where it works best is where a junior owns something that somebody senior would otherwise. Then they work together to think through the solution and the trade-offs involved in training the judgement component. After that, they implement the solution together. The amount that the junior leads kind of depends on where they are in their ramping up process, so it depends on the person and the moment in time.
I think this approach fails when delegation is not done properly. A senior is not mentoring them effectively, instead just assigning tasks with no support, which means handing over responsibility without scaffolding or a feedback loop. Yes, some juniors will survive, but others will have a bad experience because it feels like sink or swim.
The connection between all of that is that you need senior engineers who are motivated to coach well, and their performance is judged on it, so they are incentivized to do it.
How does a junior without a job currently make a case to be hired?
Thanks for the question! Since you asked you already know it's harder, but:
- Try to put together a portfolio of work (i.e. on GitHub or similar) that shows what you can do, with or without AI, but don't hide AI usage as your own. Instead show how much you can do with it and what your cool ideas are.
- See if you can write online about what you're building or learning (or both) so you can start a build a presence up for yourself.
- Target companies that are investing in juniors, i.e. those doing intern programs, or if there are companies you particularly like, reach out to them regardless to see if they have any opportunities.
The easiest way might be to invert the question: if you were hiring a junior, what would make them stand out? Then do that.
I like the idea of treating juniors as a strategic bet, but honestly I’m struggling to see which tasks I should give a junior today instead of just using AI plus one senior. For most classic junior work (small features, bugfixes, glue code), AI already feels faster and cheaper once you factor in mentoring time.
Do you have concrete examples of work you’d deliberately assign to a junior (and not AI), where the long‑term learning and organisational value clearly justifies the short‑term productivity hit?
A good question!
I think measuring a junior’s output isn’t really the thing here though; of course AI will likely do a better job, so I think that angle has too much focus on the short term (i.e. getting stuff done ASAP).
Instead the focus should be on where the experience of doing the task is the point so that someone learns and gets better, which is a focus on the long term (i.e. that person developing).
The article talks about earning that scar tissue through practice, so there are still plenty of places for juniors to do that, even with AI assistance:
Owning features end to end, so not just writing the code (themselves or with AI) but QAing it, shipping it and monitoring it in production too.
Being on call (or paired on call) for incidents and investigating and fixing issues.
Work that requires debating or negotiating with other teams (i.e. a bug fix that will change behaviour in other parts of the software that their team doesn’t own).
Lots of pull request review (with or without AI assistance) to increase critical thinking skills.
okay - let me put on my Devil's Advocate hat and ask this question: What if I am an evil big boss and I just wanna get the most out from the employee ASAP, and I don't care about their long term growth as they will hop to another job within 2-3 years anyway? If that is the case, isn't AI always better as that would always stay within the company as an asset?
What about the students or the fresh graduates?
Hi Yash, I did try to speak to this: the opening notes it's a hard time to be graduating with a CS degree, and the final section has an "If you're early in your career" part with three concrete things to do.
That being said, you've put your finger on something the article doesn't explicitly tackle: how do you break in in the first place, when entry-level postings have dropped so sharply? That probably deserves its own article.
Hi James,
I’ve been reflecting on your piece regarding the senior engineers of 2035. The "scar tissue" analogy is a brilliant way to describe technical judgment, but I’d like to offer an observation from my perspective in the current tech landscape.
Sometimes we tend to overlook that, even before AI, much of our "craft" involved curating solutions from StackOverflow. The difference today is simply that the abstraction layer is more fluid. However, the most critical factor I see is the evolution of AI reasoning. In 2026, we are no longer dealing with simple text generators, but with models that audit logic and explain the "why" through complex reasoning processes.
My observation is that the judgment gap might not be closed through the traditional passage of years, but through augmented experience. If a junior can use reasoning agents to simulate incidents and deconstruct architectures in a matter of months, aren’t we witnessing a new form of "simulated scar tissue"? Perhaps seniority in 2035 won't be defined by having made the mistake manually, but by the ability to oversee and direct an AI that is already capable of reasoning through those same mistakes.
I’d love to hear your thoughts on whether seniority is truly a matter of accumulated time, or if the density of AI-assisted learning could redefine the timeline of a technical career.
Hey, thank you for the thoughtful reply.
You’re right that we often overlooked the programming before AI. It wasn’t 100% intuition-driven or built from first principles, and we often copied solutions that already existed. That's a very good point.
Expanding on that, we could say that before AI, there were two types of people:
1. Those who challenged themselves to work things out through their own reasoning, using reference materials as needed (i.e. "I'll try, but then I'll check StackOverflow.").
2. Those who blindly copied and pasted without really learning anything.
AI compresses that somewhat in a faster loop.
What you've suggested as a solution is really interesting. I wonder whether there’s a market for AI-driven tools that can provide synthetic education for new engineers, helping them learn faster than they would on the job. For example, simulated incidents, architecture design, and critique. It sounds like you might have just come up with a startup idea. Now go, quickly, before somebody else reads it!
Yeah, the options are wide... but focus on whatever you need to do in order to move towards a senior engineer then do more of that (and ask for opportunities to do that if you aren't getting them by default). If your company doesn't have career tracks then you can find examples of what is expected at senior levels on websites like progression.fyi.
These are things like:
- Shipping really impactful work again and again
- Working out how to use AI to do more of the above faster and more efficiently with time by automating more
- Coaching and mentoring juniors
- Being able to link your work to dollars, either through saving dollars by speeding up the system, or making your customers happier
- Stepping into areas you don't usually already by using AI, such as doing frontend work if you're usually a backend engineer, or vice versa