News for hackers. Stuff that matters.
Re:I will not be using LLMs in my coding by raincole on Sunday November 08, 2026 @08:25AM (#50413114)
I insist on reviewing every line of code. But in the last few weeks I realized that LLMs are simply better than me at reviewing code too and I'm just finding excuses to not do the real work, which is to write more prompts.
Re:I will not be using LLMs in my coding by 0c3ca83 on Sunday November 08, 2026 @08:34AM (#50413219)
Have you considered asking them to write the prompts?
Re:I will not be using LLMs in my coding by raincole on Sunday November 08, 2026 @09:04AM (#50413479)
I have been asking LLMs to review/edit prompts since GPT4o era, so I really don't know what the point of this snarky comment is.
Re:I will not be using LLMs in my coding by cudgy on Sunday November 08, 2026 @09:44AM (#50413778)
Don’t think it was snarky. My guess is op is just suggesting that you could automate further, but you are ratcheting toward it one step at a time while op is suggesting to allow the ai more autonomy.
Re:I will not be using LLMs in my coding by apothegm on Sunday November 08, 2026 @09:56PM (#50420459)
I find LLMs are better than humans at finding bugs in code review. But humans are bad at finding bugs in code review in general. That’s not what a good human code review accomplishes.

A good human code review takes into account the broader business context and the structure of the codebase. It finds instances of poor design or readability. It suggests patterns or existing utilities that the author didn’t make use of, and points out antipatterns.

LLM reviews are a great first line of defense against certain classes of bugs. But I consistently find major issues in code review that the review bots miss — and some that they couldn’t have caught under any circumstances.

Just last week: 800 lines of unnecessary (and clearly LLM-written) code with high cyclomatic complexity that could be easily replaced by 50 lines of mostly declarative code by using existing patterns and utilities; several missed opportunities for converting incoming data to native types up front upon receipt and enforce stricter typing, rather than passing around things like dates or UUIDs (or even basic numeric types) as strings and trying to parse them over and over; and a case where the author had misunderstood which of two possible sources certain data should be derived from, resulting in subtly incorrect data being saved to the system of record.