Programmers nearly universally agree that reading code is harder than writing it.
So when you have chat GPT writing your code, you have to read and understand it to ensure it’s actually doing what you need it to without awkward bugs or problems.
Given that it’s harder to read than write code, it seems to stand to reason that the “time savings” must be nil.
Have you tried it much?
It's saved me a ton of time over the past 8 months. I don't know what else to say - I'm not the kind of person to deceive myself into thinking something is saving me time when it isn't.
The time saved is mainly in the micro-research you no longer have to do - the bits where you have to go and look up how to write a for loop in Bash, or how to call super() in a Python class, or which exceptions you need to catch for a call to httpx.get().
GPT-4 writes the code right 90% of the time. The 10% of the time it doesn't you catch in the same testing you would have done against code you had written yourself the long way.
Once I have a good sense for how things work, I'd much rather go to the documentation. Most of the time I can do this straight from my editor by typing the method I want and querying the LSP for documentation. In those cases it's more or less instant, there's no improvement to be made there.
Maybe in some of the other cases it would be faster via an LLM integrated with my editor, but I don't think it would justify the cognitive load of considering whether or not it's correct. I'd like to worry about whether the application is correct. And I don't really think I'm wasting time waiting for the Python documentation to load, I'm continuing to chew on the problem.
Additionally, when I go to the documentation, I'm looking for callouts about the safety of an API, and I take the lack of such callouts as authoritative. Eg, recently I was reading that in node-postgres you have to return connections to the pool, which was a good refresher for me, because previously I'd been using Rust where resources are generally cleaned up automatically. I just don't trust a lack of a callout from GPT-4 as being a confirmation of a lack of a safety issue.
It's not just about the code it can generate out of a vacuum, it can also understand code for you.
I use it to generate doc-comments, check for differences between the comment and the code, or to explain code I'm not familiar with and don't understand myself.
E.g.: I don't use Python and I had to figure out what a spaghetti-code Python script actually did. I fed it to GPT 4 and started asking questions. That's way faster than learning Python first and then deciphering the script.
Back when GitHub Copilot was first released I though very much like you and was somewhat underwhelmed by my experience with it, however since then the state of the art has improved dramatically.
One of the reasons is that you can iterate to refine and expand your answer. Here's a transcript of a recent chat, where I was too lazy to write a script:
Me> I have a CSV file with a header row, whose first column is a date formatted like this: "March 16, 2022 1:51:19 PM". Could you write a script to convert the dates in this CSV to ISO date format? I am using a mac would would prefer to not install any software, but other than that you can choose any language you'd like
ChatGPT>Sure! Since macOS comes with Python pre-installed, you can use a Python script to read the CSV file and convert the dates to the ISO date format.
<provides script and details of running it, but doesn't handle the header row />
Me> the first row is a header row, could you please modify the script to handle that?
ChatGPT> Certainly! We'll modify the script to handle the header row separately, ensuring that it is copied to the output file without modification.
<script and details, now correct />
Me> can you make it so the input file is a commandline argument?
ChatGPT> Certainly! We can modify the script to accept the input file path as a command-line argument. Here's the updated code
You get the idea.
I don't think there's universal agreement on that at all. Programmers universally agree that we spend more time reading code than writing it, but that doesn't somehow translate into it being harder.
Various studies have shown that programmers, on average, can only add at about 10 correct lines of code per day. We of course add more lines of code, but they tend to contain many bugs, so in the end only 10 lines of those are correct.
Maybe we only get 10 correct lines of code in because we're not reading the surrounding code correctly, and thus reading code is harder, or maybe 10 correct lines of code is just harder to write. I'm not aware of any hard data on this question.
The way I use AI is to think at a high level how I want to implement something and then instead of writing the code tell the AI to write it by giving it specific instructions. Then proof-read it and fix the 1-2 things that it inevitably gets wrong.
I'm not reading some random code that I don't know what it's supposed to be doing. I'm reading the output of an instruction I gave that include some technical detail on how to implement it. Reading it and doing minor fixes is really fast.