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!

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!