> I'm surprised by how much it can do, but even so I wouldn't call it "good code"
You can tell it the code is bad and how, a lot of the times it will correct it. For some bs code that you have to write it is a great time saver.
You can tell it the code is bad and how, a lot of the times it will correct it. For some bs code that you have to write it is a great time saver.
Yes, I've even done that to see how well it works (my experience is that half the time it fixes the code, the other half it claims to but doesn't) — but I can do that because I can recognise that it's bad code.
I don't expect a junior to notice bad code, and therefore I don't expect them to ask for a fix. (I've also spent 6 months in a recent job just fixing code written by work experience students).
That is true. I actually seen instances of juniors struggling with code that doesn't work and frankly doesn't make sense, but they claim they wrote it :)
For the code questions that I ask, it is sometimes quite non-trivial to check whether the code is correct or not.
It never happened in my tests that it could correct incorret code that it generated. Typically, the bot then generated code that is wrong for sometimes a different and sometimes even a similar reason.
> For some bs code that you have to write it is a great time saver.
Again I disagree: the common case where you have to write BS code is when the abstraction is wrong. Implementing a proper abstraction that strongly reduces the BS code to write is the way to go.