LLM’s can’t program.

https://functional.computer/blog/llms-cant-program

Alternative title: “How Samir got himself fired".

@dysfun Makes sense! I can absolutely understand using them, and I can see some value (as you saw), but I shall not bother, myself. I’m glad it’s sort of working for you.

@dysfun @samir

Generative AI Large Language Models (LLMs) lie and cheat.

And/but, given that everything they do is a reflection of their training data, I have to wonder …

Is this evidence that most of our industry is lying and cheating, and has been doing so for decades?

😱 😱 😱

I don’t have a soundcloud. Go donate some money to someone in Gaza, if you can.

https://gaza-verified.org/

@samir yes, this is my finding too, basically.

@samir Thanks for sharing your experience with chatbots; it gives me some ideas on what I should be checking for during code V&V.

On that note, you finish with "code review is stupid"; could you unpack that a little (or have you in a previous post)? I work with engineering safety analysis software and code review has always been a valuable part of the process. Maybe it's the engineering culture of peer review for error checking and constructive criticism, but I find the process supports my team rather than works against it. I'm curious why you don't feel it's worthwhile.

@arclight My guess is that you are much more rigorous about code review than most software developers. Everywhere I have worked, it’s been more of a gut check: reading a diff, pointing out some typos, then saying “LGTM”.

I believe strongly that pair programming is more effective at preventing bugs than lax code review.

I linked to the SmartBear book. I think it explains in greater detail the difference between real code review and the performative nonsense (pushed by GitHub) going on in many places.

@samir Thanks - I think there's a big cultural difference between engineering & software development on the practice of reviews. If the rigor isn't there, it's kind of a performative waste of everyone's time and it can be pretty corrosive if people make or take reviews personally. For us, it's just an extension of brick-and-mortar work practice - everyone makes mistakes, it's not a personal challenge, and it's everyone's goal to catch problems as far upstream as possible. It's another layer of defense in the Swiss cheese model of risk. But if it's not working as intended, yeah, you run the risk of having a false sense of rigor, larding up ypur process, and causing unnecessary conflict.

@arclight Bingo. According to the research I’ve read, good code reviews need at least: a full understanding of the existing code, an understanding of the requirements for change, explanations of why decisions were made, and for the change to be small enough to be fully held in someone’s head at once.

My experience with pull-request-based code review, across many organisations, is that it’s rare for any of these boxes to be checked.

@samir a very thoughtful read, made an awful lot of sense to me. Thanks.