I mentored junior SWE and CS students for years, and now using Claude as a coding assistant feels very similar. Yesterday, it suggested implementing a JSON parser from scratch in C to avoid a dependency -- and, unsurprisingly, the code didn’t work. Two main differences stand out: 1) the LLM doesn’t learn from corrections (at least not directly), and 2) the feedback loop is seconds instead of days. This speed is so convenient that it makes hiring junior SWEs seem almost pointless, though I sometimes wonder where we’ll find mid-level and senior developers tomorrow if we stop hiring juniors today.
Does speed matter when it's not getting better and learning from corrections? I think I'd rather give someone a problem and have them come back with something that works in a couple days (answering a question here or there), rather than spend my time doing it myself because I'm getting fast, but wrong, results that aren't improving from the AI.
> though I sometimes wonder where we’ll find mid-level and senior developers tomorrow if we stop hiring juniors today.
This is also a key point. While there is a lot of short term thinking these days, since people don't stick with companies like they used to. As a person who has been with my company for close to 20 years, making sure things can still run once you leave is important from a business perspective.
Training isn't about today, it's about tomorrow. I've trained a lot of people, and doing it myself would always be faster in the moment. But it's about making the team better and making sure more people have more skill, to reduce single points of failure and ensure business continuity over the long-term. Not all of it pays off, but when it does, it pays off big.
Years of experience doesn't correlate to a good developer either. I've seen senior devs using AI to solve impossible problems, for example asking it how to store an API key client side without leaking it...
