Thoughts from a younger generation.. [LWN.net]

Thoughts from a younger generation..

Posted May 18, 2026 17:05 UTC (Mon) by mb (subscriber, #50428)
In reply to: Thoughts from a younger generation.. by bertschingert
Parent article: RIP Peter G. Neumann

Yes, LLMs make mistakes.

But things like that are typically a result of not doing a proper development cycle.
Code generation (code writing) is not a full cycle.

Proper development, both human and AI, require things like:
- Requirements review
- Design review
- Code review
- Failure mode analysis
- Development of coding guidelines
- Coding
- etc...

If you just use an LLM to do the coding step and then say you are done, you leave out the most important steps.

Things like /* Follow RFC xxxx Section yyyy */ and the code doing something different are actually not that hard to find with AI tooling.

If a proper development cycle is used, then AI generated code can be quite good. Much better than hand-coded code from most developers.

to post comments

Thoughts from a younger generation..

Posted May 18, 2026 23:14 UTC (Mon) by Baylink (guest, #755) [Link] (6 responses)

" if a programmer can simulate a construct faster than the compiler can compile it, then the compiler writer has blown it badly."

That quote is from one of the top 10 authors in the field, Aho, Sethi, Ullman, Kernighan, Pike, Plaugher... one of them. I feel like it was Rob but I can't remember for sure. But the concept applies here too: if you have to back check the LLM, it doesn't qualify.

Thoughts from a younger generation..

Posted May 19, 2026 1:37 UTC (Tue) by rsidd (subscriber, #2582) [Link] (4 responses)

Question is, is it still faster than a human. That is,
* human writes the code
* 2 layers of peer review

vs
* LLM writes the code
* AI peer reviews it
* Human does second peer review

In many cases the second is already a win, in both speed and reliability. The gap will increase. But LLMs can implement well-known algorithms quickly; I don't think they can reliably construct new algorithms. Yet. That's where theoretical computer scientists still have a role.

Thoughts from a younger generation..

Posted May 19, 2026 11:00 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

I don't know. Peer review of human code is difficult, but good peer review of AI-written code is in my experience nearly impossible because, by construction, it always looks plausible, while often being wrong nonetheless. The result is demonically difficult to review properly, because none of the usual tells that code is wrong exist (a major tell for me that something needs closer inspection is code that somehow "feels uncertain", like it was rewritten multiple times while trying to get the bugs out of it: none of that with AI at all). It turns out most of those tells are testing for properties of *humans* writing code, not properties of the code itself.

It's like that thing with chess grandmasters -- if you hit them with normal boards they can manipulate them mentally with amazing speed, but if you hit them with random boards they're no better than merely good chess players, and make as many mistakes as well. So much of experience is grouping knowledge and memory into ever-larger chunks that can be handled by non-conscious mental processing; with AI-written code, much of that chunking is valueless because these are not human beings and (even when mimicking humans) they do things that humans do not do, throwing off the chunking and leaving you either scrambling in the dark or misled and missing errors in the flood of outwardly-plausible-looking code.

I find reviewing AI-written code so unpleasant and draining that honestly simply throwing it away and rewriting it by hand gets more tempting every time I do it. (Then having AI models review that, because they are very good at finding mistakes -- mistakes a human would also find if they had superhuman concentration, but of course nobody does.)

Thoughts from a younger generation..

Posted May 19, 2026 11:02 UTC (Tue) by nix (subscriber, #2304) [Link]

Oh, and the "have the AI write code, have another AI review it, then review it yourself" works less than you might hope -- in most cases I've tried, the AIs overlook errors that humans are not likely to have made, such as... all the inhuman hard-to-spot errors made by the AIs writing the code in the first place.

Sometimes you're lucky, but you have to wade through so much horrible stuff to get there...

Thoughts from a younger generation..

Posted May 19, 2026 11:32 UTC (Tue) by pizza (subscriber, #46) [Link]

> I find reviewing AI-written code so unpleasant and draining that honestly simply throwing it away and rewriting it by hand gets more tempting every time I do it. (Then having AI models review that, because they are very good at finding mistakes -- mistakes a human would also find if they had superhuman concentration, but of course nobody does.)

In my professional [1] and f/oss [2] niches, it's not just "unpleasant and draining" but usually *slower* to review versus rewriting from scratch. As an added benefit, said rewrite is instrumental in building/sustaining the mental models / understanding necessary to perform meaningful debugging and medium-to-long-term maintenance.

I'll add that this applies 3rd party code in general, but LLM-produced stuff is particularly bad IME. Sure, it *looks* amazing and is "explained" confidently, but you have to go over it line by line, checking literally every detail for accuracy.

[1] building models of various SoCs and peripherals for virtualization
[2] device drivers and other baremetal stuff

Thoughts from a younger generation..

Posted May 20, 2026 9:10 UTC (Wed) by neggles (subscriber, #153254) [Link]

Write tests first. Helps a lot. Even just having the bot write tests alongside the code often catches things, and it's often significantly easier to spot a bad test than a bad impl.

Origin of the quote.

Posted May 19, 2026 2:16 UTC (Tue) by devnull13 (subscriber, #18626) [Link]

This quote was coined by computer scientist Guy L. Steele Jr.. It was popularized after being featured as a "bumper sticker" in Jon Bentley's famous 1985 programming column and book, Programming Pearls.