zlacker

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-...

>>nostra+(OP)
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.

>>nostra+(OP)
I'm sure no one reads LLM-produced code very carefully, especially if it "works". At best they skim.

>>nostra+(OP)
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.

>>pyb+qb
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.

>>pyb+qb
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.

>>nostra+(OP)
This is my biggest problem with LLM generated code.

But I'm sure the author will simply dismiss it as a skill issue too.

>>nostra+(OP)
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?

>>pyb+qb
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.

>>simonw+qE
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.

>>danShu+3g3
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!

>>simonw+4o3
I think it's great if reviewing code for you is faster than writing it.

I don't think reviewing code well is something most developers can do faster than they can write it. I think that's what Joel is getting at when he says that understanding code is harder than writing it. Harder in the sense of, it takes more effort and takes longer and you are more likely to make errors.

And that might not be true for you. But it is true for a huge number of professional developers.

And it is certainly not the case that understanding and reviewing code is both:

- more time consuming and more difficult than writing it and

- that it's faster to move your entire development strategy to one where you review existing code.

Those are incompatible claims. Pick one.

----

I wouldn't normally quibble about something like this, but it does kind of rub me the wrong way when I hear AI developers talk down about this (and I'm sure it's not your intention to talk down). In your post, you write:

> Figuring out how to patch fetch() like that is non-trivial—where I’m using the software engineer’s definition of “non-trivial” as meaning “I don’t know how to do that off the top of my head”. I’d have to do some thinking and research! I’m already tempted to drop this idea and work on something else.

If I responded to that by writing, "well, doing quick thinking and research is part of the job of being a professional developer and is a learned skill that you could get better at, so what's your problem" - I think you would very rightly say that's not a reasonable response.

So I think that "well, you're a professional, you should be faster at reviewing code" is similarly dismissive to a real conflict inherent in these tools that you are ignoring, and is the kind of dismissive response that I don't normally see from you. Especially phrasing it as, "they're both true".. I don't understand what that even means.

They're not both true, you're telling me right now that it's not both true - you are telling me that it is faster for you to digest code than it is for you to write it. So what is this "both are true" bullcrap?

>>danShu+cv3
I'm not Simon, but I think reviewing code is both faster than writing code and more difficult than writing code.

Lots of difficult things don't take very much time: shooting a bullseye, lifting something heavy, winning a round of geoguessr, playing the guitar solo from Peg. We don't call these things difficult because they take a lot of time in the moment, but because they take a lot of time to master.

I think reading code is like that too. When I think about the best code readers/reviewers I've worked with, they are (1) also among the best and fastest code writers I know, and (2) still much faster at reviewing code than they are at writing it.