There has long been debate that software development is not even an engineering discipline at all, because it lacks certain characteristics from "real world engineering". I have worked with software mostly in aerospace, and I believe that what is typically done in that industry counts as "engineering". Reams of requirements, boatloads of tests (including simulated testing, testing in hardware labs, and testing on the plane), and sign-offs from multiple people who attest to software quality.
I would further think that the same practices could be applied to any software, whether if it was safety-critical or not. If software development isn't engineering, it's not because it can't be, but because not every project is critical enough to warrant the extra time and expense.
I think a similar train of thought applies here. As the article points out, skipping reading the code is probably not a good idea for safety-critical software, but for less critical things, it may be fine.
If someone told me that they applied avionics-level rigor to an iOS puzzle game, I would think that (a) it's probably very solid software, but also (b) they were probably wasting their time. But on the flip side, if someone wanted to spend their time making their puzzle game rock-solid, I don't think that's necessarily a bad thing to do. It's not harmful to have especially robust puzzle games.
Is it worth it to review LLM-generated code? For some projects, maybe not. Even for many projects, maybe not. But I'm not sure that it should be frowned upon either. It might turn up something interesting. Put in whatever level of rigor matches your project needs, personal interest, and schedule!
You claim you don’t read the code. People believe you. Later you reveal that actually you do read the code, as well as metrics about the code. You just don’t read line by line and scrutinize them individually. Then you want to say their opinions weren’t grounded, but all that happened is you misrepresented your own argument
by ‘I don’t read code,’ I mean: I don’t do line-by-line review as my primary verification method for most product code. I do read specs, tests, diffs selectively, and production signals - and I would advocate escalating to code-reading for specific classes of risk.
Is not at all what people consider “not reading the code” to be
Last week I wrote a post that was ostensibly about the direction of IDEs and AI-assisted coding... and one specific sentence (reasonably) generated a lot of discussion.
The line that got the discussion going was, “I don’t read the code anymore.”
I thought a lot about these arguments, and I still don’t read the code. Here, I defend that. Have at it!
There has long been debate that software development is not even an engineering discipline at all, because it lacks certain characteristics from "real world engineering". I have worked with software mostly in aerospace, and I believe that what is typically done in that industry counts as "engineering". Reams of requirements, boatloads of tests (including simulated testing, testing in hardware labs, and testing on the plane), and sign-offs from multiple people who attest to software quality.
I would further think that the same practices could be applied to any software, whether if it was safety-critical or not. If software development isn't engineering, it's not because it can't be, but because not every project is critical enough to warrant the extra time and expense.
I think a similar train of thought applies here. As the article points out, skipping reading the code is probably not a good idea for safety-critical software, but for less critical things, it may be fine.
If someone told me that they applied avionics-level rigor to an iOS puzzle game, I would think that (a) it's probably very solid software, but also (b) they were probably wasting their time. But on the flip side, if someone wanted to spend their time making their puzzle game rock-solid, I don't think that's necessarily a bad thing to do. It's not harmful to have especially robust puzzle games.
Is it worth it to review LLM-generated code? For some projects, maybe not. Even for many projects, maybe not. But I'm not sure that it should be frowned upon either. It might turn up something interesting. Put in whatever level of rigor matches your project needs, personal interest, and schedule!
> Put in whatever level of rigor matches your project needs, personal interest, and schedule!
This is the most refreshing, grounded response I've gotten in awhile <3
Well, when you clickbait/lie about your own premise you can’t really expect a decent conversation lol
?? What
You claim you don’t read the code. People believe you. Later you reveal that actually you do read the code, as well as metrics about the code. You just don’t read line by line and scrutinize them individually. Then you want to say their opinions weren’t grounded, but all that happened is you misrepresented your own argument
In certain, extenuating circumstances, I will read the code. It is not in my common / critical path. It's not how I'd describe my workflow.
All I’m saying is that
by ‘I don’t read code,’ I mean: I don’t do line-by-line review as my primary verification method for most product code. I do read specs, tests, diffs selectively, and production signals - and I would advocate escalating to code-reading for specific classes of risk.
Is not at all what people consider “not reading the code” to be
Last week I wrote a post that was ostensibly about the direction of IDEs and AI-assisted coding... and one specific sentence (reasonably) generated a lot of discussion.
The line that got the discussion going was, “I don’t read the code anymore.”
I thought a lot about these arguments, and I still don’t read the code. Here, I defend that. Have at it!
Here's the previous post that generated the hubbub: https://news.ycombinator.com/item?id=46891131