I'm puzzled how anyone trusts ChatGPT for code
I asked ChatGPT to convert a simple 12-line Python program to Lisp.
The result is broken by mismatched brackets. Yes. In Lisp.
I ask for correction and receive the errant bracket moved, still mismatched.
I ask again and the bracket gets removed. Fine??
No. A loop break has been mistranslated to a return from function, so execution is nonsense.
I wonder how much user faith in ChatGPT is based on examples in which the errors are not apparent ... to a certain kind of user.
198 comments
[ 5.2 ms ] story [ 253 ms ] threadWhat if you could write something like:
And the decorator reads the function name and optional docstring, runs it through an LLM and replaces the function with one implementing the desired behavior (hopefully correctly). I remember there was something like this for StackOverflow.https://github.com/Matsemann/Declaraoids
Maybe I should make a LLM version of this.
[0] https://docs.spring.io/spring-data/jpa/reference/jpa/query-m...
https://github.com/PrefectHQ/marvin?tab=readme-ov-file#-buil...
Of course AI data pipelines are a totally different conversation than code solutions.
Also, getting template of 100s of LOC saves time in writing it from scratch even if I know exactly what I'd need to write.
I suspect the typical ChatGPT user is using it for code that's beyond his ability to write. That being the whole point of his using it.
It follows that such code is likely beyond his ability to understand. But worse, beyond his ability to understand he doesn't understand it.
I haven't used any llm for code yet but most code I ever touched was mostly written by others, and I wouldn't have been able to write it from scratch, but was able to modify it, take only chunks out of the whole to use for something else, take only the structure and not the verbatim code and use in some other language, refactor to satisfy my own priorities vs the original, get useful results in languages I don't even know, etc etc.
It doesn't seem like using some pattern-matched uber-autocorrect code would be much different, especially once you understand that understandingless nature of what your getting.
I rarely know exactly what I need to write and writing it usually isn't the problem. Sans LLM, there have always been tools and techniques you can lean on, like syntax highlighting, auto completion, your compiler feedback, or unit tests.
I find that writing code consumes only a small percentage of my time. And while writing code is obviously where bugs originate, it's not where the big problems come from.
Making software good is the easy part, making the right software is where the trouble lies. It's why I spend most time not coding, but talking to people. Figuring out what needs to be done, how, when and why.
Really? You can't understand why people do things based on trust? Do you trust no one?
Because almost every programmer these days has learned by a route that relies on incorporating code on trust. E.g. using someone else's compiler.
> I use code from LLMs on most work days ... not because I trust it, but because I understand it and tested it.
The snag there is that one can rarely verify test coverage is sufficient.
> the same as code from anyone, including from myself six months ago.
But it is not the same. ChatGPT delivers completely untested code. Not even syntax-checked in my case. Would you accept such code from any human?
> Trust doesn't enter into it. Clear and workable solutions do
Plenty of clear and workable solutions are discovered unsafe. I suspect that's much more likely when the code comes from a source such as ChatGPT that delivers code in a completely untested state.
There are way too countless many stories of people successfully accomplishing tasks by getting an llm to give them a starting point or outline or even a complete solution that only needed a few fixups, hardly any different from debugging your own first draft, to say it doesn't or can't work. That's already sailed.
The fact that it doesn't produce finished correct code, or even appropriate outline for every single case, doesn't seem especially remarkable or damning to me. It is what it is, it's not what it's not.
(I haven't used any myself, but I'm not primarily a coder who is obligated to take advantage of every available tool, and don't like how any of the llm companies are training on open source code without either consent or attribution and then selling that. And don't like how ai and even mere speech to text voice interface before that is being added to everything in general.)
I find this take surprising. Leaving AI aside entirely, debugging my first draft seems very different than debugging your first draft.
I grant, maybe that is still quite different.
There is something extra to grasp the theory behind someone else's code sometimes.
Is helpful to always be skeptical of code and try to get an understanding of it.
Another way I think of it is I find it easier to revise than to write (both in English and code). So when I write something I just try to get my ideas out there and then skeptically reread it and recompose. LLMs let me just speed up that process.
Aaawwww hellz no. I hate looking at my old code. I've had too many of those surreal experiences where something breaks, I start looking at how to fix it, and am suddenly stunned to realize "this could never have worked in the first place." There's one or two of those I'm still puzzling over, decades later. :-(
Good go is like brutalist architecture. Strip out all the cute, the smart the stupid coder tricks. Write ugly, blocky, verbose, spelled out, functional code. Test the ever loving shit out of it.
Go is fast enough that if your going back to fix a "performance problem" you either did something head smackingly stupid (we all have) or you have a real bottleneck and it's time to roll up your sleeves and write that elegant solution.
I tend to revisit code more often to add features or deal with edged case bugs than anything else. That clear and functional code without any magic is a win.
Edit: you can do the above with almost any language but those that choose packages over standard libs make it HARD.
I assume everyone else must be working on projects/languages that have far more representation in the training set, but for me, especially working in Rust, even trying to write interfaces into C libraries, I would constantly find myself dealing with hallucinated parameters or function calls, incorrectly implemented functions or just broken code.
At the very least if I do it myself, I'll have some intuition about how the code works.
I can't speak for anyone else, but I've used LLM's mainly for generating Java code. The generated code hasn't necessarily ever been perfect, but IME it's been "close enough" that even counting having to make some manual changes, it's still faster than writing it myself from scratch.
That said, I'm typically only using it for relatively short snippets of code, where I "know" how to do the operation in question, but want to avoid having to stop and look up fiddly details that might not be cached "top of mind" because I haven't written that code in a while.
I'm sure there are use-cases where LLM's don't save time, but I'm equally sure that there are at least some where they do.
accurate function header accurate glue code wacky invocation of some API that may or may not exist accurate glue code
It's rare for me to get anything really useful. I suppose the accurate glue code can be helpful.
I've had a lot of success with chat gpt where it told me what libraries to use, what classes/functions I need, etc, where it would have taken me ages to find out by reading documentation and even longer to go through tutorials that leave out the more interesting stuff.
Also, as a general rule you shouldn't trust its code output, but it's a good way to brainstorm or get started on coding something. It can give useful tips or replace stack overflow. I almost never ask it to generate code for me, but I ask it questions about existing code very often. That seems to work very well for me.
It's knowledge of sveltekit still seems weighted to pre 1.0, it hallucinates libraries for shadcn, or radix-ui.
You have to prefix your prompts with "Please use modern JS" otherwise it won't use .filter or .reduce sometimes.
I agree its a good replacement for Stackoverflow, but it is often pitched as a replacement for coding.
I've found using aider as the best compromise, let it build something small and revert if it doesn't work.
> If I ask some LLM/GPT a react question I get good responses. If I ask it about a framework released after the training data was obtained, it will either not know or hallucinate. Or if it's a lesser known framework the quality will be worse than for a known framework. Same with other things like hardware manuals not being trained on yet etc.
> As more and more devs rely on AI tools in their work flows, will emerging tech have a bigger hurdle than before to be adopted? Will we regress to the mean?
https://news.ycombinator.com/item?id=40263033
By far, the most common problem is that I will ask ChatGPT 4 to write a small problem that does X, and it will create a skeleton. Lots of functions that implement at most some paramater validation and then contain comments like // Implement the rest of this function.
With enough prodding, I can sometimes get it to actually fill in the function implementations one-by-one. But often times it will implement part of it and then put another one of those "implement the rest" comments in. Like for example, if I asked it to write a function to draw three circles, after prodding, it would write code to draw the first circle and then stop. Obviously, the answer here is for it to create a function that draws 1 circle and call it 3 times, but I can't fault it for taking my instructions very literally.
Even when I do get it to implement full functions, when I later ask it for the full code listing, it's back to printing out functions that have "implement this" comments in them.
Perhaps the fault is mine for asking it to do tasks that there aren't hundreds of implementations of on the internet.
OK, here's one. I was initially talking with it about how to best simulate restrictions from older consoles in an indie game. We chatted a bit how to most efficiently do paletted drawing on modern graphics architectures in various APIs (e.g. Vulkan, SDL). I got to asking it how exactly the SNES stored data in VRAM, and asked it to list all the PPU registers in the SNES and what they're used for. It gave me a correct answer (I double-checked). I then asked this:
> Can you write a header for a C++ file named PPU.hpp with methods to read and write these registers?
And it responded with this. Note that the response includes a couple "add more as needed" comments.
Here's a basic outline for PPU.hpp:
#ifndef PPU_HPP #define PPU_HPP
#include <cstdint>
class PPU { public: // Constructor and Destructor PPU(); ~PPU();
private: // Memory-mapped PPU registers // Assuming a representation of the PPU register space uint8_t ppuRegisters[/* size of the PPU register space */]; };#endif // PPU_HPP
> Let's write a compiler in C that tokenizes a single file in this language, parses it into a syntax tree, and emits an object file in LLVM IR. I'd like the compiler to be readable and understandable by a human, but execute as fast as possible.
The tokenizer it wrote was good, but when it got to the operators, it implemented + and -, and then contained this comment:
// Add other operators and delimiters
When I asked it to fill in the operators, it actually did a good job. However, this was the parser it gave me.
typedef struct ASTNode { TokenType type; char* value; struct ASTNode* left; struct ASTNode* right; } ASTNode;
ASTNode* parse(Token* tokens) { // Example parsing logic, build your AST based on the tokens return NULL; // Placeholder }
Obviously, it's leaving building the entire AST up to me. So I asked it:
> Now implement the complete parser.
The result was long, so I won't paste it here, but it contained all kinds of comments:
// Skipping parameter parsing for simplicity // parameters would go here // Simple implementation: only supports return statements for now // Simple expression parsing: only literals for now // Add more parsing functions as needed...
So I said:
> Seriously, I want you to implement the entire thing, not an outline or a framework.
And it gave be a code with fewer, but more complete parsing functions. The expression function still had this comment.
// Assume we're only parsing integers and binary +,- operations for simplicity
And then at the bottom:
// Assume the rest of the necessary parsing functions are implemented similarly
My prompting style is much more direct - things like this: https://chatgpt.com/share/61cd85f6-7002-4676-b204-0349a72323... - more here: https://simonwillison.net/series/using-llms/
I tried that with the two examples from before. Mixed results.
Still had one comment telling me to finish it myself in the SNES PPU example, but that's a lot fewer than before. Unfortunately, when I told it to do the work, it gave me a more complete, but not totally complete header without mentioning that it was incomplete. It also took a few tries and I had to regenerate a response that started generating garbage code and then error'd out.
I checked to make sure that ChatGPT had no memory of previous conversations related to the SNES PPU. So I suspect this has more to do with the task given than the prompting style.
https://chat.openai.com/share/8703a48a-af72-4a9f-976e-688a26...
The parser was more interesting. I didn't remove the details of our toy language discussion from ChatGPT's memory, but I also didn't specify much in the way of what I wanted. It created some funky parser code, and I didn't try to compile it to see if it was correct, but it didn't appear to display the lazy behavior I saw before. It also titled the conversation in Spanish, even though I've never chatted in Spanish with it and I'm not fluent.
I suspect I could have gotten more correct output by giving a more detailed description of what I wanted, but I was trying to keep it simple to match your prompting style.
https://chat.openai.com/share/ccc23d98-6d4f-4be5-b9b6-b4464f...
It was.
> version 4
Paywalled.
> is much better at code.
I'll post the question as comment to root, for you to try if you want.
Analogously, “convert this function from Python to lisp” seems like a higher-level job, better done by a programmer human (or at least, it’s too high for the current level of available code LLMs).
There is still a valuable level that code LLMs can operate at, in my experience - something like a cross between “a more advanced autocomplete” and “a templating/scaffolding/boilerplate engine”.
Mismatched brackets is not any /job/. And /matched/ brackets are part of the job this LMM claimed to do. Writing runnable code.
GPT 4 is much better than the others.
You should try something like Aider to get better output
LLM's will turn out to be nothing more than another glittering gadget. Except this one will obliterate any coding skills of future generations. Not to mention the gigatons of AI generated garbage text, images and music that it's filling the world with. What a waste.
LLMs have fairly well understood failure modes. They have incredible strengths, too. And they differ very much by what you use. If the ChatGPT you were forced to use was GPT3.5 (and the behavior sounds very much like it was), you literally have no idea what modern LLMs can actually do.
I mean... yeah. ChatGPT doesn't know what numbers or what logic is. It wasn't "confused". It just doesn't do that.
You're using it for something it's not intended to be used for and, unsurprisingly, it's bad at it. If I said I'm giving up on using hammers because they were terrible for screwing screws into the wall, you'd tell me I'm using the wrong tool. This is no different. ChatGPT has its uses, but it isn't magic. Just like any tool it has limitations.
ChatGPT: The larger number is 3.
User: If I have one apple, pick another apple and then get an apple from a friend, and Alice has two apples, who has more apples?
ChatGPT: You have more apples. You started with one apple, picked another, and got one more from a friend, so you have three apples. Alice has two apples.
[edit]:
User: what does good will hunting say to the know-it-all at the bar?
ChatGPT: After Will Hunting outsmarts the know-it-all student in the bar, he spots the student's female friend outside a shop later on. To tease the student further and show his wit, Will taps on the window to get her attention and, holding up his phone number, famously asks, "Do you like apples?" After she nods, Will triumphantly says, "Well, I got her number. How do you like them apples?" This line became quite iconic and is one of the memorable quotes from the movie.
Every time I've tried gpt-4 etc there are such problems. I don't use it for trivial things since then what's the point, and for anything non-trivial it screws up too much.
It is useful for translations and brainstorming, but not much else. Translating from natural language to code is a part of that, but not letting it code itself.
It is not replacing engineers, it isn't one where you give it a broad set of requirements and it just goes and builds, it is helping increase productivity, to get folks through areas where they need to bounce ideas off of someone.
We're coding mostly in Python, C++, and .NET Core where I do expect it'll have a much deeper set of training data than it will for Lisp (and even for those languages we're getting marginally better performance from specialized engines than we are general GPT 4).
The non-OpenAI other coding AIs so far are all performing worse for us than GPT4. We've done testing against LeetCode challenges and a bunch of other things.
Yes.
And succeeded! :)
> We're coding mostly in Python, C++, and .NET Core where I do expect it'll have a much deeper set of training data than it will for Lisp
I can't imagine how malformed bracketing is due to insufficient training set.
And nor it seems can ChatGPT: "I've encountered numerous examples of Lisp code during my training, covering different applications and techniques within the language. Whether it's simple examples or more complex implementations, I've seen quite a bit of Lisp code."
You didn't label it (which, btw, is a faux pas), but it's obvious from your replies that this wasn't an Ask HN, it was a Tell HN. You have absolutely no interest in what the rest of us have to say.
Nevertheless, I'll try once more for luck: Basing your opinions about LLMs on your experience with GPT-3.5 is a mistake. If you don't want to use LLMs at all because you have preconceptions, that's fine, but don't pretend that you've sampled LLMs and found them lacking for professional coding when you haven't tried the professional tools.
Er, V3.5 is "the very first iteration"?
> don't pretend that you've sampled LLMs and found them lacking for professional coding when you haven't tried the professional tools.
I think you misread my post. I didn't mention professional.
And my post was't about a "sample of LLMs". It was about this one in particular.
Yes. ChatGPT-3.5 was the very first LLM-based chat assistant that was announced on Nov 30, 2022 [0]. It hasn't gotten better since then, just more censored and faster.
It followed GPT-1 (which was only interesting to people who were already in the know), GPT-2 (which was neat but widely recognized as pretty useless and again, not something normal people noticed) and GPT-3 (which was cool, but didn't provide a chat interface, it could only complete texts, so it made a decent base for the early versions of Copilot).
[0] "ChatGPT is fine-tuned from a model in the GPT-3.5 series, which finished training in early 2022." https://openai.com/index/chatgpt/
For example, I once asked Claude 3 to port some simple XML parsing code from Go (because 10s to ask is faster than 60s to type by hand haha) and it produced this https://pastebin.com/3823LBiA while the correct answer is just this https://gist.github.com/neon-sunset/6ba67f23e58afdb80f6be868...
Functionally identical but such cruft accumulates per each single piece of functionality you ask it to implement. And this example is one where the output was at least coherent and doing its job, many more are worse.
Sometimes what it suggests won’t work at all. But other times it opens my thinking to an approach I had too much tunnel vision to see.
I end up writing the code ultimately. There was only once a tiny function I could paste in directly, unedited. But still helpful.
One great technique can be to ask it for options: “List five ways this code could be improved / more readable.” Usually about 1 in 5 suggestions will lead to something interesting.
If you need to revive a language you haven't coded in for a while (or regex or sql), ChatGPT can really help get you off the ground much faster, though you'll still need to understand the output it gives you and compose it together yourself.
If it hallucinates something, the code won't run - or it won't work correctly when you test it.
Much easier to "fact check" code than prose.
I've only used it for basic snippets where I know what the code I need is, but it's faster to describe it than write it out myself (for example, "Using Python and boto3, take all the files in the current directory that end in .csv or .pdf and upload them to a bucket named "reports". Prepend the S3 keys with "YYYY-MM-DD/" using today's date").
For simple things like that, it's been great.
I chose to. So I could give it another chance to succeed.
But do tell. What type of person does not have to ask it to fix its mismatched brackets?
Obscure languages and operating systems are also a weakness - for example I could not get llama3 to reply with FreeBSD commands even after repeatedly telling it not to - there just aren’t that many SO/Reddit/forum posts about BSD in comparison to Linux. And evidently that’s what they’ve trained it on. There isn’t even anything semantically odd about an rc.conf, it spits out correct statements, just for the wrong file in the wrong OS.
Everyone acknowledges things like multiplication and counting are hard for LLMs because they aren’t statistically encoded. But counting lisp brackets is also basically the same problem. And unlike YAML it’s not really self-healing or obviously correctable once it’s fucked up (as you noticed). I think the implication is there’s clearly some syntaxes that are much less generateable simply because they require intense amounts of context.
(also, as far as counting… I’m sure far smarter people have look at this, but maybe multiplication is something that could benefit from log-addition techniques, that might reduce the complexity quite a bit vs a naive “multiply column by column like a human fourth-grader” approach.)
ChatGPT: "I've encountered numerous examples of Lisp code during my training, covering different applications and techniques within the language. Whether it's simple examples or more complex implementations, I've seen quite a bit of Lisp code."
> the general complexity of the format
Good then that this example has a very simple format.
Here Not a rpoblem in this (even without AI you’ll see diff breaking on json files for much the same reason, unless you go out of your way to avoid it - brackets are semantic white noise
Glad I'm not doing that, then. I understand what it is generating as soon as I try to run it - and get a "missing bracket" error. I've understood that what it has generated is crap. And that only good luck made that easily detectable.
"This code doesn't do what you say it will" is not a review comment reserved exclusively for machine-generated code.
... and 100 hours a day to review and test their code? :)
And yes, reviewing code is part of my job. And the reason it's part of my job is that people who get hired as programmers are often very bad at not making obvious mistakes.
I would say that this points more to the narrowness of your industry experience than anything else.
Failing to compile is one of a million different ways that code doesn't produce the claimed or desired or correct behavior. It's not particularly special. All code needs to be reviewed, regardless of who/what wrote it and how.
Good point. I'll correct to:
It had not ocurred to me that anyone would /knowingly/ hire a programmer who submitted code that fails even to compile, as per ChatGPT.
Anyone who would knowingly could well be delighted to use ChatGPT instead.
They don't. Hiring happens before the first commit. This incredulity about programmers not all being consistently excellent is what makes it sound like your practical experience is very limited.
Point of fact, you're here complaining that a product (ChatGPT 3.5) known to be substantively shitty is substantively shitty, and when people say "you know v4 is very significantly better, right?" you say "but that one isn't free". That gives a strong vibe that you know you're doing something bad and just don't care. Is that the vibe of consistent excellence? I would say no.
> submitted code that fails even to compile
You seem stuck on this business of not compiling when that failure mode is in fact extremely less consequential than literally any other failure mode. Wake me up when humans stop writing code that compiles and runs and tests just fine while doing the wrong thing literally all the time.
Asking how anyone can blindly trust ChatGPT code is a fundamentally broken question. You can't blindly trust human code either. Trust has to be earned by past demonstrations of performance within the specific domain.
A reviewer earns trust by consistently catching other peoples' mistakes. A programmer earns trust by consistently not making obvious mistakes in the first place. When I see a reviewer who consistently fails to catch other peoples' mistakes, I do not trust that reviewer.
Giving a human more inherent trust than you give ChatGPT without experiencing sufficient past performance to have earned it would be your own failure. Humans are very stupid and fuck up constantly.
I wouldn't say programmers who compile are all excellent. And I didn't.
> when people say "you know v4 is very significantly better, right?" you say "but that one isn't free".
I think you must be mistaking another poster for me. I didn't say that either.
> I think you must be mistaking another poster for me. I didn't say that either.
Is this you? https://imgur.com/5wCeTZg
The intern is at the end of this toolchain, whatever that chain is. And when the intern is using that chain to produce code that they won't bother trying to understand before submitting it, then the problem is the intern.
It is a poor craftsman who blames their tools.
And what I mean by that is this: Suppose an apprentice is tasked with using a saw to cut some 2x4s to a specified length. It doesn't matter what kind of saw it is: It could be a handsaw, a chop saw, a handheld circular saw, a radial arm saw, a table saw, a FrameRipper 9000 Pushbutton CNC SawSaw saw, or any other manner of wood-cutting saw.
Maybe they're even using an LLM bot to create the G-code to run that FrameRipper 9000.
Whatever it is they're using, suppose they produce cuts that are consistently and uselessly wrong -- that are unfit for the purpose.
And maybe a lot of that is OK -- after all, they're there to learn, right? Certainly, a big part of learning means making mistakes. It's going to happen, and to varying extents it's absolutely expected to happen. It can be blameless -- especially early on.
But suppose the apprentice won't ever bother with even looking at the cut-up boards that they've produced to see if they're even in the same ballpark of what was requested, and just blindly submits their work (however right or wrong it may be) as a finished task.
This is no longer blameless.
Now, at this point: Do you blame the tool, or the person who is using that tool? (Choose exactly one.)
Imagine the horror to trying to read, understand and fix million lines of unsupervised code generated in a production environment …
But in the past year or so, I've finished some coding projects that are useful to me. Mostly, I've done this using a ton of help from the bot.
But I don't just blindly trust what the bot produces. I read the output until I understand what it does (and why it does it that way), and if I can't understand it or if the method is awful then I get clarifications and/or revisions until I do understand it or the method is sane. I test it to make sure that it does do what I think that it should do, even with weird parameters. And if it's got unreadable spaghetti in it, or it isn't following my specifications, I coach it back towards not fucking up that way and we start at the beginning again for that section of code (wherein, I don't just blindly trust it).
It is not a particularly quick process, and it does have its rocky moments, though I am getting faster and better at it...and the results are... eh? They're alright.
Now, sure: I do have all of my previous failings ("learning opportunities") to look back on as I work with the bot to produce the things I want -- I've got a ton of useful (if functionally incomplete) background relating to the production of code under my belt.
But this is a process that works for me. And I definitely am not cheating. I'm just using a fairly new and widely misunderstood tool to accomplish things that I (despite decades of frustrating effort) was previously broadly unable to accomplish on my own.
I don't have any regrets about using this process. I don't feel, say, that I'm somehow less of a man because I've found utility in the use of a tool -- I was fully a man before I started using that tool, and I remain fully a man today.
In fact, in using this tool I've learned more about code in the past year or so than I ever have before. And not just syntax and formatting, but also good structures for that code, and the importance of planning that code before a single line is ever written, and of revising that plan whenever it becomes necessary -- no matter what needs thrown away or grossly-refactored as a result of that revision.
This makes me feel that the idea of writing code (without a bot) may actually "click" for me someday soon, but it also makes me question the necessity of that: Does it ever have to "click" when I've got tools like this available for me to use?
At the end of the day, lazy interns were also lazy interns an eternity ago. Lazy interns produced shit code 60 years ago, and lazy interns will still produce shit code today (except now, they can produce shit code even faster -- wheeeee! -- but that's also not new). Supervising lazy interns has always been an arduous task, whether they were using written arithmetic, a slide rule, or a pocket calculator; or whether using relay logic or punch cards or one of those new-fangled glass teletypes. When the output of a lazy intern is wrong because they are just don't care about their answer, then that lazy intern is still wrong no matter how they got there or how quickly they're able to show that they're wrong...again.
Much the same as it always has been.
But what has changed fairly recently is that we've begun a journey that is now absolutely inevitable, and we're all in for a long ride -- whether we like it and want to be a part of it or not, we're already well on our way.
But this intern doesn't blame his tools. Unfortunately.
And one can hardly say it is a poor end-user that blames the intern's tools.
> Do you blame the tool, or the person who is using that tool? (Choose exactly one.)
I'll blame the person who created that tool.
Very different. An LLM lets him generate /far more/ bad untested code per unit of effort.
And SO encourages other humans to test it. Often an SO answer comes with evaluative comments and ratings that are all I need to reject it. If the LMM was "AI", it would at least provide the same, right?
> A better path is to ensure they are spending significantly more time reviewing, testing, and incrementally improving their code than they are typing/generating it
Then let's see the LLM-based workflow that achieves that...