It's all code generation, though. That's what makes this whole conversation so frustrating. For whatever reason, there is a large swath of devs who either are unwilling to admit these tools are useful (and thus have to make ridiculous assumptions like code getting pushed to prod by a bot) or don't have enough experience to understand how to use them.
I just asked Claude (the actual app in the browser) to write a function that returns all types that implement a specific interface AND have a method with a specific attribute. Then, I look at the code (and because I already have over 10+ years of experience) I can determine pretty quickly whether it'll work or not and then I bring it in and test it. I could have googled the C# reflection syntax for finding all interfaces, then matching with an attribute on a method, and so forth. But that'll take at least 2-3x as long. Why don't I remember the syntax? Because the syntax itself isn't important. It's the problem I'm solving that is. But now, I can ask specific, tailored questions with context and get specific results. Nowhere in my process does code get produced by itself without human oversight. It's not even a thing I have to worry about. It's such a simple that process it drives me nuts to have to explain it to people.
unrelated to original point, but to me, the most worrisome point about LLMs:
> because I already have over 10+ years of experience
How are future developers going to gather a similar experience when LLMs are available. You are comparing what an LLM produces to what you would have produced without. This is absolutely the right approach. What about the next generations though, what will they compare the LLM output with?
> What about the next generations though, what will they compare the LLM output with?
I have no clue. I haven't really talked to younger devs about how this helps (or hinders) them. But I think you're onto something, it's paradoxically more useful the more you know.
I just asked Claude (the actual app in the browser) to write a function that returns all types that implement a specific interface AND have a method with a specific attribute. Then, I look at the code (and because I already have over 10+ years of experience) I can determine pretty quickly whether it'll work or not and then I bring it in and test it. I could have googled the C# reflection syntax for finding all interfaces, then matching with an attribute on a method, and so forth. But that'll take at least 2-3x as long. Why don't I remember the syntax? Because the syntax itself isn't important. It's the problem I'm solving that is. But now, I can ask specific, tailored questions with context and get specific results. Nowhere in my process does code get produced by itself without human oversight. It's not even a thing I have to worry about. It's such a simple that process it drives me nuts to have to explain it to people.