Namanyay, I’m sorry to say, sounds like a relative newbie when it comes to software development. The refrain “junior software developers can’t actually code” has been around as long as software development.
I remember when Stack Exchange first popped up, senior developers complained “junior developers don’t actually LEARN anything anymore; they just copy code off of Stack Exchange without understanding what it does!”
And before SE? We were doing the exact same thing in the comp.* newsgroups. And before that? When you started developing something, a senior dev dropped a bunch of books on your desk and said “when you’ve finished reading those, let’s talk.”
The truth is, ever since libraries have been a thing, the majority of developers have just used the libraries without really understanding what goes on inside them. And that’s not necessarily a bad thing — the entire point of abstraction is so that developers can focus on the stuff they need to get done while ignoring the already solved problems.
The issues arise when you place code monkeys in software architecture or senior development positions, and they’ve never had the curiosity to read through the header files for those libraries they use, but instead just let Claude code complete their way to functionality. Because then most style guides with teeth go out the window, as there’s no intention behind the choices made.
And this results in something that really irks (and always has) senior software developers: instead of writing really clean, performant and novel code, those senior devs have to spend all their time doing code reviews and editing and refactoring codebases that nobody else understands.
Same as it ever was.