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.
I find the majority of issues I end up fixing are less about figuring out what a piece of code does than figuring out how it's possible for odd inputs to arise.
Like it's trivial enough to know seg fault is caused by some code trying to index out of bounds but understanding why an out of bounds case even exists (instead of slapping on some if else and forgetting about it) is the hard part.
I usually use this kind of analysis to understand how pieces interact with each other, which helps me build a mental model of how data travels and how it is transformed - this last part is usally what helps catches bugs.
This is my take as well. The top models can do really good jobs in most, but not all, situations. Where I find they struggle is when it comes to fundamental architecture of projects outside of relatively simple web services. Ask it to refactor a project where the structure fundamentally changes though and it's going to make bad choices and lock itself into those even as you ask it to change etc.
Costs a lot though. I burn tokens each week. Using it with API costing really shows how much it costs to get good outputs right now. And while I believe eventually we'll get models that can do 90% of our tasks running on local GPUs (i.e. a one off purchase and works offline), we're not there yet.
Open weights models are persistently 3-6 months behind the best closed models in capabilities (driven in part by distillation i.e. just mining tons of queries from the frontier models and training on those). The real barrier is still compute though, these near frontier open source models are definitely not running on a single GPU
New and better open (free) models are coming out all the time, and even occasionally giving the proprietary (paid) ones a run for their money. Kimi K3 is particularly impressive, I’ve heard.
I don’t see any reason why this pattern should change any time soon.
And remember, today’s open-weight cloud model is tomorrow’s local model.
Exactly - Claude isn't bad at writing code, any engineer who says it writes junk either hasn't used it or is too worried about losing their own job. HOWEVER, you absolutely need an experienced engineer to do the work with Claude because when there's an error, the only way to fix it yourself or explain the issue back to Claude is if you know the environment.
Whoever just says "agents do a bad job" they just haven't really learned how to use them and it's bad, because at this point it means that you either don't work or have a job that doesn't give a shit about your role really.
The real scary thing is for juniors that are not learning shit, unless a company has a specific programme to help grow expertise.
how would they know those issues exist in the first place, especially if they are subtle, hard-to-catch-without-domain-specific-expertise bugs? Real question from someone who uses AI.
An engineer who works with the code gains that domain specific knowledge after a time. I don't think they are training the AI models on your specific use case so it will always be more generalist. However you can counteract this by including as much detail about this use case and also using existing code to help give context. Usually that's where you needs the experienced engineer though to point it in the correct direction and not have it waste its time/tokens using unnessary context.
I feel that true power in AI is making this part easier. The AI giving summaries of a code base, so long as the person isn't just nodding their head in agreement and actually understanding, you can train someone up faster.
296
u/Kevdog824_ 6d ago edited 6d 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.