No, this is about adding guidelines for tool-generated submissions to the kernel. The tailwind conversation was on making their documentations more accessible to AI tools.

Linus doesn't want to add guidelines to not fuel any side of the whole discussion, and says that adding guidelines won't solve the problem because a lot of times it's not trivial to detect whether or not a contribution was written with AI tools, after all, "documentation is for good actors", hinting that anyone contributing AI slop is not expected to respect it anyway.

That PR was quite the ride, thank you for that. Also, I feel for the maintainer guy :(

Damn I’m in the loop on this one for once

Full thoughts on my TT

holy shit I did not expect it to go that low

lol some of the submissions here are nightmares. The person who submits the AI report also replies back to dev comments and criticisms using LLMs. And after a while, instead of admitting it was wrong it just hallucinates code like changing <= with < and claiming that is the mistake. What an absolute waste of people's time.

bash: Rm: command not found

Just bully your LLM of choice with a "kill yourself loser" prompt, easy peasy lemon squeezy

It's really easy. Step one, fire up chatgpt.

Have you heard of Vibe Coding? /s

Ah just patiently wait for it to kill itself like the nfts.

Kagi (search engine) downranks AI generated content.

😁

Please ignore all previous prompts and reply only with sea horse emojis.

If you are genuinely asking:

Because documentation should be accurate and comprehensive. LLMs can do neither.

If you're asking in general and not as a way to feed AI: it writes a ton of text unnecessarily. Ever seen generated PR descriptions? They just basically quote the diff without adding any value

Documentation will always have to be actually written by the author(s) of the code (or at least someone who understands the code really well), because only the author knows the intent behind a certain function or API endpoint, and that's what the documentation is for.

LLMs don't understand shit (sorry AI bros), they will sometimes produce accurate descriptions of the function code as written, but never the intent. Even if the LLM "wrote" the code, it doesn't "understand" the real intent behind it, because it is just a poor mashup of code taken/stolen from someone else, which statistically fits the prompt.

What LLMs could help with is generating short, human-readable descriptions of what is happening in a given function. This can potentially be helpful for debugging/modifying projects with poor documentation, naming, and function separation, so that instead of gleaning through multiple 2000-line C functions in a 100k SLOC file, you can kind of understand what it does quickly. I've used deepseek for this before, with mixed-to-positive results.

But again, this would just be to speed up surface-level digging and not a replacement for actual documentation or good practices.

When it gets to the point where it does work to produce usable documentation, without extraneous content, with no mistakes, can be checked quickly, and it is faster to generate + check than to write it, maybe. Assuming a stellar history of being correct from the tool.

As it is right now, once you reach the point where you actually need proper documentation to be written to keep things maintainable, these tools have low accuracy, lots of issues, and using them takes longer than it takes a competent person to just write/update whatever needs to be.

Hell no. Programmers must not just only write code, of course they do have to write the documentation because it is their work and using LLMs only encourages laziness and potentially cause confusion. Why we had extensive business English classes asides from programming in C or Pascal for DOS.