> LLMs can write boilerplate code at least an order of magnitude faster than I can.
This is my biggest fear with everyone adopting LLMs without considering the consequences.
In the past, I used "Do I have to write a lot of boilerplate here?" as a sort of litmus test for figuring out when to refactor. If I spend the entire day just writing boilerplate, I'm 99% sure I'm doing the wrong thing, at least most of the time.
But now, junior developers won't even get the intuition that if they're spending the entire day just typing boilerplate something is wrong, instead they'll just get the LLM to do it and there is no careful thoughts/reflections about the design and architecture.
Of course, reflection is still possible, but I'm afraid it won't be as natural and "in your face" which kind of forces you to learn it, instead it'll only be a thing for people who consider it in the first place.
The question to ask yourself is what value one gets from that refactor. Is the software faster? Has more functionality? Cheaper to operate? Reduce time to market. These would be benefits to the user, and I'd venture to say the refactor does not impact the user.
The refactor will impact the developer. Maybe the code is now more maintainable, or easier to integrate, or easier to test. But this is where I expect LLMs will make a lot of progress - - they will not need clean, well structured code. So the refactor, in the long run, is not useful to a developer with an LLM sidekick.
I agree with you but as a thought exercise: does it matter if there is a lot of boilerplate if ultimately the code works and is performant enough?
Fwiw, most of the time I like writing code and I don't enjoy wading through LLM-generated code to see if it got it right. So the idea of using LLMs as reviewers resonates. I don't like writing tests though so I would happily have it write all of those.
But I do wonder if eventually it won't make sense to ever write code and it will turn into a pastime.
> I agree with you but as a thought exercise: does it matter if there is a lot of boilerplate if ultimately the code works and is performant enough
Yeah it matters because it is almost guaranteed that eventually a human will have to interact with the code directly so it should still be good quality code
> But I do wonder if eventually it won't make sense to ever write code and it will turn into a pastime
Even the fictional super-AI of Star Trek wasn't so good that the engineers didn't have to deeply understand the underlying work that it produced.
Tons of Trek episodes deal with the question of "if the technology fails, how do the humans who rely on it adapt?"
In the fictional stories we see people who are absolute masters of their domain solve the problems and win the day
In reality we have glorified chatbots, nowhere near the abilities of the fictional super-AI, and we already have people asking "do people even need to master their domains anymore?"
I dunno about you but I find it pretty discouraging
This is my biggest fear with everyone adopting LLMs without considering the consequences.
In the past, I used "Do I have to write a lot of boilerplate here?" as a sort of litmus test for figuring out when to refactor. If I spend the entire day just writing boilerplate, I'm 99% sure I'm doing the wrong thing, at least most of the time.
But now, junior developers won't even get the intuition that if they're spending the entire day just typing boilerplate something is wrong, instead they'll just get the LLM to do it and there is no careful thoughts/reflections about the design and architecture.
Of course, reflection is still possible, but I'm afraid it won't be as natural and "in your face" which kind of forces you to learn it, instead it'll only be a thing for people who consider it in the first place.