5 ms·

Then it can be picked up in a code review.

• TeMPOraL 5y ago
  Spotting bugs in code review is already hard when the code you're reviewing has been written by a human. In this case, at least you can rely on your knowledge of the co-worker who wrote it - over time, you learn the kind of experience they have, the kind of mistakes they make. Spotting bugs in code that has been generated by a GPT-3 derivative, with all the subtle mistakes that implies, is going to be even harder.
  • stackbutterflow 5y ago
    In the end we need to tag each piece of code written by copilot. Doing a code review on a piece of code written by a human and on another one generated by copilot is going to be a very different experience. I would be way more wary of a PR containing copilot generated code. Turns out copilot will be a productivity killer.
  • aeorgnoieang 5y ago
    > Spotting bugs in code that has been generated by a GPT-3 derivative, with all the subtle mistakes that implies, is going to be even harder. I'm kind of skeptical! I think your claim is reasonable tho so maybe I'm more skeptical of your confidence? I'd love to read a follow-up from you after you tried using Copilot for an extended period; even (or maybe especially) if it's as bad, or worse, than you expect!
• pyrale 5y ago
  But good code reviews are much harder at scale than building good code in the first place. The reason we write code _and_ do code reviews is because doing both is better than doing either. But copilot isn't even equivalent to a code review: code review is not only checking for correctness. It's also asking questions and helping the author walk through their solution by having them reconsider it. Copilot doesn't ask questions, nor can it answer them or provide a rationale.