[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIcRzndNUdh-9R18@lappy>
Date: Mon, 28 Jul 2025 01:59:42 -0400
From: Sasha Levin <sashal@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: corbet@....net, linux-doc@...r.kernel.org, workflows@...r.kernel.org,
josh@...htriplett.org, konstantin@...uxfoundation.org,
linux-kernel@...r.kernel.org, rostedt@...dmis.org
Subject: Re: [PATCH 2/4] agents: add core development references
On Sun, Jul 27, 2025 at 10:10:02PM -0700, Kees Cook wrote:
>On Mon, Jul 28, 2025 at 01:00:37AM -0400, Sasha Levin wrote:
>> > If an Agent needs the above list, then so does a human. Everything above
>> > should already be discoverable by the Agent. If it's not, then we need a
>> > better summary document _for humans_ that reads like the above.
>>
>> Why would an agent read those docs unless we tell it to?
>
>When I typed "/init" in claude, it found the references in the Makefile
>and other files to stuff in Documentation/ and read it. Hence my
>suggestion to add this in a place that is human (and agent)
>discoverable, like Makefile, which any sane agent is going to read to
>look for a "help" target, etc. Any agent that doesn't understand how to
>figure out what _kind_ of codebase it's working on isn't an agent that
>is going to deal well with the Linux tree.
>
>> Similarily, why would a human read those docs unless we tell it to? :)
>
>We do, though. But this is my point: if we _lack_ a good entry point for
>humans, then we need to solve _that_ problem.
Thing is, agents won't read the README on their own: they need to be
prompted to do it.
Claude will generate passable commits without a CLAUDE.md for simple
prompts.
I'm assuming we both agree that we need to give the agent some entry
point which they will automatically process without any user prompts,
even if it's just saying "Please read the README file!"?
>> Just like with humans, the better context and background you give them
>> the better of a result you'll get out of it.
>
>Both the top of Makefile and the bottom of "make help" refer to reading
>the README file. I think *that* is where all these kinds of changes
>should go, and it should be suitable for human consumption. Honestly,
>README is extremely vague right now:
>
>$ cat README
>Linux kernel
>============
>
>There are several guides for kernel developers and users. These guides can
>be rendered in a number of formats, like HTML and PDF. Please read
>Documentation/admin-guide/README.rst first.
>
>In order to build the documentation, use ``make htmldocs`` or
>``make pdfdocs``. The formatted documentation can also be read online at:
>
> https://www.kernel.org/doc/html/latest/
>
>There are various text files in the Documentation/ subdirectory,
>several of them using the reStructuredText markup notation.
>
>Please read the Documentation/process/changes.rst file, as it contains the
>requirements for building and running the kernel, and information about
>the problems which may result by upgrading your kernel.
>
>
>
>
>"There are several guides..." and "There are various text files in
>..." is hardly the right language for a human either. And why is doc
>building in the README? That's, frankly, esoteric for anyone who needs
>to read the README.
>
>Let's fix up the README into something nice for everyone, and any decent
>agent should already be reading it anyway.
I think it'll be hard to find a common path that works here. README is
pretty generic because there are different humans that might read it:
- A university researcher who should be pointed to researcher-guidelines.rst
- A security researcher who should be pointed to security-bugs.rst or embargoed-hardware-issues.rst
- A newbie trying to set up his mail client and needs to be pointed to email-clients.rst
- A coding agent that doesn't care about none of the above.
So we can clean up README and try to make it an entry point that will
fit most of it's potential readers, but I worry that at the end it will
end fitting none of them.
Without crafting something more specific for agents, I also worry that
we'll be stuffing the limited context they already have with information
that will only hurt their performance (just like humans: there's only so
much we can remember at a time).
--
Thanks,
Sasha
Powered by blists - more mailing lists