|
|
|
|
|
by vidyesh
1082 days ago
|
|
> What I have a serious problem with is the proposal that this now needs to be part of a workflow when it actually doesn't improve anything. Yes, forcing it in the workflow might be bad for personal growth and overall culture. I think in any form using it alongside you workflow is helping, it saves a lot of time and also helps decreasing cognitive load as one can forget about the commonly used code snippets and boilerplate code and focus on important aspects of the code. |
|
No, it is not. It can confuse and mislead you which wastes a lot of time. I lost multiple hours on different occasions figuring out subtle mistakes that it had made. It's sometimes harder (and slower) to understand someone else's code than writing the code yourself completely from scratch.
Also, if you aren't working alone, be prepared to answer code review questions on code that you haven't written. GPT is not going to take any responsibility for what it outputs. It often begins its answers to review questions with "Apologies for the oversight" followed by a revised version of the previous output.
The people I work with are used to me providing PRs that don't contain stupid mistakes. So in order to guarantee for that, I usually have to do a full blown quality control on every GPT output that I use. It can still be a time saver, but not really a significant one usually. I am still learning how to distinguish the cases in which it is not even a good idea to involve it and when it can be somewhat trusted. Seems to be highly dependent on the amount of training data in the particular problem domain and programming language.