IMO, by the time todays juniors would have 5-10 years of expected experience, the entire field will be something different altogether. Language choice distribution will collapse (if not change altogether), whole new modalities of monitoring and progressive delivery guardrails will come into play, essentially creating a 24/7 incremental rollout of pure agentic code, correctness will be determined by a mix of language features and self-monitoring by models in production and automated testing against production snapshots in pre-production, and deep debugging will the be province of a select group of engineers and there will be a pathway to those roles for juniors, but those roles will be coveted and difficult to break into (and probably will require education and maybe even informal accreditation).

someone probably made this same argument against certain frameworks over the years and juniors still figured it out. we need to stop trying to babysit learning for hypothetical situations.

the bar to "start" is lower and the bar to actually competency is higher now, juniors who want to actually learn instead of just pressing enter over and over again will do so regardless of whatever you do to "help" them.

Exactly this. We need to be more precise than blanket statements like "agentic coding is a trap" and start figuring out what a "tasteful" application of agentic coding looks like. ChatGPT is destroying liberal arts curriculums because students can choose to not do anything of the thinking themselves and produce mediocre work that passes the bar. I think the same problem is showing itself with agentic coding, just with more directly measurable consequences (because the pile of software ends up failing in a more spectacular way than the pile of bad writing).

Self-taught, "junior" here.

Due to English-language limitation my most adult life, I struggled to code. Used visual coding etc. But of course, I can't make a living on drag-and-drop harness.

Comes in GPT-3.5, accelerated my learning. Now I'm running my incorporated company, just launched one software-hardware hybrid product. Second one is a micro-SaaS in closed beta.

The point is: when people use "juniors" as a fixed shaped blobs of matter, they focus on the juniors that were in any case going to make mistakes: AI or not. Misses the key point of agentic usage.

If a junior builds something with agents that turns into a mess they can’t debug, that will teach them something. If they care about getting better, they will learn to understand why that happened and how to avoid it next time.

It’s not all that different than writing code directly and having it turn into a mess they can’t debug—something we all did when we were learning to program.

It is in many ways far easier to write robust, modular, and secure software with agents than by hand, because it’s now so easy to refactor and write extensive tests. There is nothing magical about coding by hand that makes it the only way to learn the principles of software design. You can learn through working with agents too.

> the juniors who start today don't have that, they overrely on agentic coding and do not know what they don't know

Y'all need to stop worrying about the kids.

They're smarter than us and will run circles around us.

They're going to look at us like dinosaurs and they're going to solve problems of scale and scope 10x or more than what we ever did.

Hate to "old man yells at cloud" this, but so many people are falling into the trap because of personal biases.

While the fear that "smartphones might make kids less computer literate" is true, that's because PCs are not as necessary as they once were. The kids that turn into engineers are fine and are every bit as capable.

[flagged]

I wonder if it's not so much the coding that people don't want to write, but it's more about the weight of all the orchestration, data engineering and research that has to be done (or, understood in the first place) to get anything off the ground these days. It feels off the charts complicated, and of course is now shifting rapidly.

Knowing it better than the leads isn’t that hard - they spend most their life in meetings and teaching people how to think. Knowing the code base in detail is important - but I’m certain unless you wrote it all, there are parts you don’t know. I’m sure what you do is build enough scaffold understanding and depth in the core parts you can visit any part and understand it. But I’m also certain there are parts that based on pure recall you care unaware of the details. Someone else wrote it, you haven’t had to read it yet, and thus it’s a black box. Either that or your code base is quite small relative to the team size, or the team is very unproductive. The supposition one person is fully aware of any growing code base built by a team or organization - or a monorepo being built by 10,000 developers over 15 years - is prideful. A lot of it works because it works and you accept that unless you need to inspect a part because it’s not working. Whether a machine wrote it or an intern 10 years ago did, it’s a black box until it has to not be.