Comment by nostrademons
6 days ago
Curious how he reconciles this:
> If you build something with an LLM that people will depend on, read the code. In fact, you’ll probably do more than that. You’ll spend 5-10 minutes knocking it back into your own style.
with Joel Spolsky's fundamental maxim:
> It’s harder to read code than to write it.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I'm sure no one reads LLM-produced code very carefully, especially if it "works". At best they skim.
The problem is that a lot of code works in general, but fails in edge cases. I would hate to be the guy who's job is only to find out why verbose AI generated code fails in one particular condition.
I read LLM generated code like I review a PR. I skim for anything that stands out as a common pitfall, and dig into the details of area I expect issues.
For most things I'm not willing to accept faster code at the expense of being an expert in the code.
So I am still trying to find the right amount of reading, editing, and reworking that gets the job done faster, where "the job" includes me being an expert in the produced code, not just the production of code.
There are periods of skimming but I'm doing a lot more than skimming.
This is my biggest problem with LLM generated code.
But I'm sure the author will simply dismiss it as a skill issue too.
The major difference is that in the type of reading Joel Splosky is talking about, you are coming in not knowing the code's intent. It was written by one or more other people at some point in the past, likely with many iterative changes over a period of time. Figuring out the intent in this case is 90%+ of the work. With LLM generated code, you know the intent. You just told the assistant exactly what your intent was. It's much, much easier to read code that you already know the intent of.
You can invest more time in the writing to make code easier to read. It’s just that it typically would take much more time. It would be conceivable for LLMs to eventually reach a state where they can produce such easily readable and comprehensible code.
I can reconcile that. Joel is right. So is Thomas. If you're a professional programmer you should be able to do the harder thing.
Thomas was a bit more spicy about that:
> but you have no idea what the code is - Are you a vibe coding Youtuber? Can you not read code? If so: astute point. Otherwise: what the fuck is wrong with you?
You've said this a couple of times, but I don't understand what you're trying to say.
Yes, I can do frustrating things, I know how to review and vet code. I also know how to write boilerplate code. I also know how to research new tasks in areas where I have no familiarity that are poorly documented. I know how to do a lot of complicated, difficult things - all of which are part of being a professional developer.
The question is whether I want to use a tool that makes most of my job the difficult part.
The only way this makes sense is if you are somehow reaching a point where "doing the harder thing" is not the harder thing for you anymore - where reviewing code is easier for you than writing it. And maybe your argument is that you can get to that point with practice, or that LLM code is generally easier to review than other types of code, or that the problems it's tackling are so difficult that in those cases writing the code is harder than reading it.
But it's not that they're both true. "You should be able to do the harder thing" is not really an answer to "why are you selling me a tool that replaces an easy thing with a hard thing?"
There are many difficult things that I can do as a professional software developer. I can mentor junior developers. I can do detailed product design work with stakeholders and translate technical limitations into language that they understand. I can negotiate software deadlines with product owners. I can write interfaces for undocumented software and deal with undocumented bugs in 3rd-party code. I can step through minified code in production settings to debug problems. These are all difficult things that, as a professional developer, I am capable and willing to do, and often need to do. And yes, of course, I can review pull requests. I am not, however, generally in the business of adopting tools that force me to do that stuff more often than is necessary to get good results. I don't adopt tools that make my life harder, and I honestly think that's a big part of being a professional.
To be very blunt about it: "Buck up, you should be able to handle this" is not a sales pitch. I can also write with my non-dominant hand, but I'm not going to start taking notes that way. There's no intrinsic prize for making your life harder, the only way what you're saying makes sense is if it's not harder for you to read code than to write it.
I've kind of lost track of where we disagree here, to be honest.
Maybe we need to drop "easier" and "harder" and talk about speed.
I can write software faster with LLMs, without sacrificing quality - in fact I can get higher quality software because doing things "better" doesn't mean they take longer.
I derive enjoyment from building good stuff. If I can do it faster I can build more of it, which increases my enjoyment.
I wrote about this a couple of years ago: "AI-enhanced development makes me more ambitious with my projects": https://simonwillison.net/2023/Mar/27/ai-enhanced-developmen...
That's still true today, only more so because the models are significantly more competent than they were in March 2023!
2 replies →