LLM-generated code must not be committed without prior written approval by core

> You might be surprised to learn that I actually think LLMs have the potential to be not only fun but genuinely useful. “Show me some bullshit that would be typical in this context” can be a genuinely helpful question to have answered, in code and in natural language — for brainstorming, for seeing common conventions in an unfamiliar context, for having something crappy to react to.

> Alas, that does not remotely resemble how people are pitching this technology.

Edit: before someone accuses me of doing what trovalds is saying, I understand that code now. I was able to probe the model to explain it to me to the same degree as my understanding of my own code. It was the same feeling as when my team innovated over my previous work and I just asked them how they did it.

If your job is to make an accurate parser for it, probably you want to hand code it. If your job is to make sense of the data the customer has provided you with, this is merely an impediment to your actual job, and ChatGPT has you covered. Yes, there'll be mistakes. But ChatGPT can do in a few seconds what'd take you hours.

In both cases, even after back and forth with the AI for half an hour, the result is absolute garbage. And never works. I don't understand at all how people get even barely usable stuff out of AI...

(1) Using LLMs as a learning aid (or docs augmentation)

(2) Writing one-off _whatevers_

(3) Finding the appropriate docs/info in the first place

(4) As a meta-tool to sniff out whether other people have gone down this path before

(5) Cloning any sort of boilerplate "pattern" which requires more than simple text substitution (nvim macros, custom CLI tools applied to a visual selection, ... can get you a long ways, but they're not good for everything)

For a few select examples:

(1a) You can copy in a snippet of code and ask what _this_ character does _here_, finding appropriate search terms to actually learn about the topic.

(1b) Generated examples are fine, even if they're wrong, if you use them as a mental scaffolding to learn more about a library. Analyze them and prove them right or find why they're wrong, and that process of analysis teaches you in a different way than just reading the docs by themselves.

(1c) Sometimes the docs are just unwieldy. Ask the LLM for the snippet immediately after the "-B" flag, and then you can search for that more-unique snippet instead of, e.g., 1000 occurrences of other fields referencing "-B" and not defining it.

(2a) Say you want to know how your webserver responds when the client sends each byte in a separate syscall, waits a second between each one, and then immediately starts a new pipelined request doing the same shenanigans without waiting for a response to the first one. The LLM can generate exactly what you need, or when it fails it was still faster than typing it yourself. It's a task that's much more succinct to describe in English than code, yet simple enough that the LLM has a high success rate, and a brief scan of the code can confirm it's actually hitting localhost instead of downloading not-a-virus.exe.txt. The stakes are low if it's wrong because you can visually tell if it's doing the right thing.

(3a) I recalled reading once about the design of the voting/scoring algorithm used internally in Google's TGIF question ranker and knew there was a brief public blog post going over the more important details in a consumable format. Current search engines mostly can't point me to an old, unmonetized, niche blog post, especially when I don't remember any of the important keywords. LLMs can often point me to the exact blog, and barring that can usually give me the keywords I need to find it myself (similarly with finding things like the AWS SDK C API, which exists but isn't advertised and is hard to search for because the other keywords dominate). In this case, I wanted to read about Wilson's Scoring by Evan Miller [0].

(4a) Ask the same question a few different ways and a lot of times. If you only get garbage hallucinated blog posts, research articles, and keywords not related to your current task, it's suggestive of the specific task you're doing not being popular. If at a high level you know your end goal has been implemented many times, that's suggestive of you going down an incorrect path.

(5a) I was writing a program heavily leveraging lazy type instantiation to generate a zero-cost (de-virtualized, inlined where appropriate) iterator library. Anyone can write map and reduce, but it's a little more annoying to have a meta-layer doing that sort of thing in the type system, especially with some other constraints I had in the project. However, showing the LLM a few examples of this type-level way of defining the things I'm doing and then asking for implementations of `peek` or `skip` or whatever worked swimmingly. They're well suited to that task because the boilerplate isn't just simple textual substitution, because the tasks are simple enough that the LLM has a high chance of getting them right, and because the nature of the library is that a couple very simple hand-written tests will catch all the subtle mistakes, and a human reading the code will catch all the non-subtle errors.

And so on. I don't use LLMs for everything. If I want to do anything involving infrequently used Python dunders I'll probably go straight to the data model docs [1] and search within that page. I write most code by hand (give or take many custom tools I've integrated into my nvim workflow). Sometimes an LLM makes my life easier though.

[0] https://www.evanmiller.org/how-not-to-sort-by-average-rating...

[1] https://docs.python.org/3/reference/datamodel.html

This high-level approach usually breaks down for more complex scenarios, but for those, you can often explain with some detail how you want the code to look like, and it will give you the code and auto-correct any glaring mistakes you made.

But note this prohibition is of "code that was not written by yourself" rather that written by yourself twice.

let new_code = f previous_work

where f could be identity. But it could be other transformations such as: rename_all_the_things, move_items_around, object_oriented_to_functional, and what not. Probably a combination. But here's the kicker: all permutations of these functions are all derivatives.

And we don't have to be naive here, thinking that I'm talking about using refactoring tools on an actual code base because I want to hide the fact that I want to steel some piece of code.

I'm talking about the fact that I've seen so much code and this has in fact taught me basically everything I know. I have trained myself on a stream of works. Just like an AI. The difference is in scale, not in nature.

Surely if an AI writes “foo” it’s because it’s learnt that everyone else writes that. It’s different from asking “suggest me an implementation of FFT”, and then pasting that in wholesale.

It’s similar to how research literature works. Eventually concepts like “computer” and “DNA” become so common that we don’t have to reference 1800s literature unless very pertinent to the question.

If it introduced a subtle mistake (e.g. wrong variable) there's a chance the programmer could miss it, but would not have made the same mistake themselves.

There's also a chance the machine-generated code might lack a bug that the programmer would have introduced if writing it themselves. Overall though, I get the impression these tools are generally harmful to code quality.

edit As ekianjo points out, they specifically mention Copilot as unacceptable.