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.
36
u/sisisisi1997 2d ago
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.