Again, no one suggested that I would prototype with the LLM and then completely trust what it tells me about the code and what it learned from writing it. That is stupid.
You get the LLM to write code quickly and then you review it and perform experiments manually.
You get the LLM to write code quickly and then you review it and perform experiments manually.
I think this is where the issue is, the word “review”.
Reviewing comes in two different types: non-trivial reviews and trivial reviews.
Non-trivial change example: Create a presentation where the user flow follows a flow chart.
Someone could go to an LLM, prompt it with “create a presentation that follows this flow chart” followed by the mermaid syntax of the flowchart.
The LLM will give you back an array of slides where certain functions/actions/triggers/etc… navigates to a different slide based on its index within the array.
But if you ask a person to do it, they might sit there for a while, try a few different attempts to understand the problem better, then come back to you with some typed generics and a map/dictionary/object/associative-array/etc… with slides in it, and functions/actions/triggers/etc… that navigate to a flow chart by a slide’s id.
Two different bits of code to review from two different sources.
You can choose to do one of the following:
“LGTM” the changes (in which case it wasn’t actually reviewed),
Read through the entire change to try and comprehend it until you find a part that you don’t understand
Sidenote: If you didn’t find a part that you didn’t understand, then the change isn’t actually non-trivial, so you can refer to the “trivial change example” below. This section is about non-trivial changes.
When asking the LLM a question about the part that you didn’t understand, it will either give you:
A completely different changeset, so now you have something completely different to review. And by the fact of the longest part of programming being digesting code you didn’t write, in effect you’ve taken a long-cut and could have written it yourself faster. (This is part of where the “LLMs make programmers take longer” observation comes from)
A post-hoc justification for it. Which would by it’s nature not have take place before the code was written, which makes it unable to have actually affected the code, and thus not actually be a valid reason for why the code is the way it is. So you don’t get a valid answer, you just get a convincing one.
When asking the person why they did it, they’ll tell you they tried a few attempts to get their head around it, and mid-attempt they accidentally commented-out one of the slides which created an unseen error when one of the functions/actions/triggers/etc… tried to go to a slide that didn’t exist. So to prevent that problem from occurring again, they wrote another attempt where they used types/generics such that every slide’s id and reference to every slide’s id was type checked. That way, if a reference was ever incorrect or initially correct but made incorrect by a later change somewhere else, the editor would alert you before you even tried to compile your code. With that response, you now have the reasoning behind the non-trivial thing you didn’t understand.
Trivial change example: Changing a color from “orange” to “red”.
Someone could go to an LLM’s chat window and type, “Change the color to red”.
But it’d be faster to just double click the word “orange” to select it, then type the word “red”.
So for trivial examples, it doesn’t really make much sense to use an LLM, it’s literally faster to do it yourself then review your own trivial changes in a diff.
Coming back to the problem of the word “review”:
You get the LLM to write code quickly and then you review it and perform experiments manually.
Non-trivial reviews require back and forth communication. Reviews can be convincing without being valid. The review’s validity depends upon the validity of reasoning within that communication.
Trivial reviews are trivial, so there’s no point to using an LLM in the first place
That means that reviews of LLM outputted code by their nature are either invalid and/or non-optimal.
My advice: cut out the crutch/middle-man and do the hard work of establishing that rock-solid understanding. You’ll be much better off in the long run.
And by the fact of the longest part of programming being digesting code you didn’t write, in effect you’ve taken a long-cut and could have written it yourself faster.
The conclusion doesn’t follow from the premise. Just because an LLM may need to tweak something doesn’t mean it necessarily would have been faster to do it manually. Humans need to tweak things all the time, it’s called revising, and it’s an important part of improving code.
But I wouldn’t claim that using LLMs is always faster than coding manually, nor the opposite. There are times when LLMs do slow me down. It’s important to recognize when that risk is high.
But I’m quite certain that for prototyping specifically, i.e. building a desired UX to get a feel for it and experiment with whether the ideas are sound, LLMs are faster.
So you don’t get a valid answer, you just get a convincing one.
That’s why you shouldn’t trust an LLM’s reasoning; it doesn’t actually have sound reasoning abilities. You shouldn’t rely on an LLM to reason about problems, you should use it to generate code quickly when the reasoning has either already been done by a human and/or it exists in its training set. LLMs are closer to a search engine than a problem solver.
When asking the person why they did it…
I see no reason why this process is mutually exclusive with using an LLM. You can use both human reasoning and LLM code generation.
No disagreement from me about trivial changes. I make them in my editor all the time, assuming I even have an editor in front of me. Sometimes I don’t, and it’s possible to use dictation to an LLM to make trivial changes without touching a keyboard.
That means that reviews of LLM outputted code by their nature are either invalid and/or non-optimal.
Again, no one suggested that I would prototype with the LLM and then completely trust what it tells me about the code and what it learned from writing it. That is stupid.
You get the LLM to write code quickly and then you review it and perform experiments manually.
I think this is where the issue is, the word “review”.
Reviewing comes in two different types: non-trivial reviews and trivial reviews.
Non-trivial change example: Create a presentation where the user flow follows a flow chart.
Someone could go to an LLM, prompt it with “create a presentation that follows this flow chart” followed by the mermaid syntax of the flowchart.
The LLM will give you back an array of slides where certain functions/actions/triggers/etc… navigates to a different slide based on its index within the array.
But if you ask a person to do it, they might sit there for a while, try a few different attempts to understand the problem better, then come back to you with some typed generics and a map/dictionary/object/associative-array/etc… with slides in it, and functions/actions/triggers/etc… that navigate to a flow chart by a slide’s id.
Two different bits of code to review from two different sources.
You can choose to do one of the following:
When asking the LLM a question about the part that you didn’t understand, it will either give you:
When asking the person why they did it, they’ll tell you they tried a few attempts to get their head around it, and mid-attempt they accidentally commented-out one of the slides which created an unseen error when one of the functions/actions/triggers/etc… tried to go to a slide that didn’t exist. So to prevent that problem from occurring again, they wrote another attempt where they used types/generics such that every slide’s id and reference to every slide’s id was type checked. That way, if a reference was ever incorrect or initially correct but made incorrect by a later change somewhere else, the editor would alert you before you even tried to compile your code. With that response, you now have the reasoning behind the non-trivial thing you didn’t understand.
Trivial change example: Changing a color from “orange” to “red”.
Someone could go to an LLM’s chat window and type, “Change the color to red”.
But it’d be faster to just double click the word “orange” to select it, then type the word “red”.
So for trivial examples, it doesn’t really make much sense to use an LLM, it’s literally faster to do it yourself then review your own trivial changes in a diff.
Coming back to the problem of the word “review”:
That means that reviews of LLM outputted code by their nature are either invalid and/or non-optimal.
My advice: cut out the crutch/middle-man and do the hard work of establishing that rock-solid understanding. You’ll be much better off in the long run.
The conclusion doesn’t follow from the premise. Just because an LLM may need to tweak something doesn’t mean it necessarily would have been faster to do it manually. Humans need to tweak things all the time, it’s called revising, and it’s an important part of improving code.
But I wouldn’t claim that using LLMs is always faster than coding manually, nor the opposite. There are times when LLMs do slow me down. It’s important to recognize when that risk is high.
But I’m quite certain that for prototyping specifically, i.e. building a desired UX to get a feel for it and experiment with whether the ideas are sound, LLMs are faster.
That’s why you shouldn’t trust an LLM’s reasoning; it doesn’t actually have sound reasoning abilities. You shouldn’t rely on an LLM to reason about problems, you should use it to generate code quickly when the reasoning has either already been done by a human and/or it exists in its training set. LLMs are closer to a search engine than a problem solver.
I see no reason why this process is mutually exclusive with using an LLM. You can use both human reasoning and LLM code generation.
No disagreement from me about trivial changes. I make them in my editor all the time, assuming I even have an editor in front of me. Sometimes I don’t, and it’s possible to use dictation to an LLM to make trivial changes without touching a keyboard.
Not convincing. I’ve given my reasons