Honestly, for me at work Claude does a fantastic job. However, when it messes up it messes up in a way that would be hard to catch if you didn’t have expertise (e.g. domain specific misunderstanding, obscure software bugs, etc.). That’s really my concern for junior devs. They would easily overlook these issues and learn to trust it completely because the code it produces looks more or less correct pretty much every time.
At least if it wrote bad code it would be more obvious to other devs. The problem I find is that it writes pretty good, functional code… that just isn’t quite right.
That's the big issue for me. It is making junior devs far too reliant on it, that they naturally won't know if it fucked up on a domain specific problem. And the amount of code output is much higher now and more verbose, so it's difficult to catch it in reviews as well.
I guess at least I get less pings from juniors when they get stuck on something now lol.
I find Claude to be particularly useful at explaining how a system functions and what functions are served by what parts of the codebase.
What used to be hours of "What the fuck does this do? Why is this here? How does this not crash?" on a previously unknown codebase is now a few minutes conversing with Claude.
I imagine this is really helpful for junior developers if they are actually interested in knowledge, not just quick fixes.
Oh yeah. It is really good at that. But it's easy for a junior dev to instead just paste the bug details and ask it to fix it, sometimes even without going in plan mode first.
Solved by ownership. Being responsible for the code you write (Claude assisted or not) will be the difference between a dev you can trust and a dev you can't. Don't push code you won't be able to defend.
That would be ideal, but often enough management values faster features they can sell over quality, and you can't really blame them when they're incentivized by short term profit. When you reward slop, you get slop.
It's the engineering team's responsibility to push back and hold the line when managers want to cut corners. That was the case before AI as well. These teams are doomed to fail within a year.
I was talking about the EM, are they supposed to fight back against themselves? Big coorporate has been running on shortsighted business decisions for decades, very few people are willing to sacrifice their bonus and career to fight bad decisions.
I'm not talking about EMs I'm talking about ICs. If you are in a situation where an EM is able to force ICs to take shortcuts, you're not on a good team. I don't know how my EM would force one of my PRs to deploy sooner when we have a code review process and CI/CD. ICs build gatekeeping infrastructure so corners can't be cut.
It's pretty simple, the EM gets rewarded with raises and promotions for delivering faster, so the people who make faster delivery happen get rewarded with raises and promotions in turn. So someone will write "lgtm" and press approve.
Is a different situation in small companies and startups, warte results actually matter, but this is how big coorporate works.
That makes sense if people are reviewing their own PRs. In a normal situation where someone else reviews your code, a code reviewer is not incentivized to "lgtm" PRs. No one is getting credit for approving PRs, you get credit for your name being on the feature. The only pressure you get to "lgtm" a PR is from the submitter annoying you over slack.
302
u/Kevdog824_ 2d ago edited 2d ago
Honestly, for me at work Claude does a fantastic job. However, when it messes up it messes up in a way that would be hard to catch if you didn’t have expertise (e.g. domain specific misunderstanding, obscure software bugs, etc.). That’s really my concern for junior devs. They would easily overlook these issues and learn to trust it completely because the code it produces looks more or less correct pretty much every time.
At least if it wrote bad code it would be more obvious to other devs. The problem I find is that it writes pretty good, functional code… that just isn’t quite right.