Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 14 additions & 3 deletions contributors/guide/pull-requests.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,7 @@ It should serve as a reference for all contributors, and be useful especially to
- [Trivial Edits](#trivial-edits)
- [Large or Automatic Edits](#large-or-automatic-edits)
- [Fixing Linter Issues](#fixing-linter-issues)
- [AI Guidance](#ai-guidance)
- [The Testing and Merge Workflow](#the-testing-and-merge-workflow)
- [More About `Ok-To-Test`](#more-about-ok-to-test)

Expand Down Expand Up @@ -599,16 +600,16 @@ at once to that file.

## Large or Automatic Edits

Some tools make it very easy to create large Pull Requests, for example:
Some tools make it very easy to create large and/or automatic Pull Requests, for example:
- global search/replace
- linters which automatically correct issues (see also next section)
- large language models (LLMs) which generate code or documentation
- AI tools (large language models, assistants, etc) which generate code or documentation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we should also include "LLM" keyword somewhere still for searching?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer AI as LLM is the recent technology but I'm sure there will be new types of AI models that may not be LLMs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just wondering if we should toss "LLM" once in here somewhere so it greps in addition to what we have now.

Minor point regardless, not a blocking thread.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to resolve this thread as-is.


To make it easier for reviewers to handle such Pull Requests, please explain
how it was generated in the "Special notes for your reviewer" section of the
Pull Request description. Reviewers may then be able to reproduce those steps
(search/replace, linters) or can start the review with the right expectations
(LLMs). Also consider the section about [splitting up Pull
(AI tools). Also consider the section about [splitting up Pull
Requests](#dont-open-pull-requests-that-span-the-whole-repository) above.

Even with such tools it is still your responsibility as submitter of a Pull
Expand All @@ -622,6 +623,16 @@ reference to this documentation if they come to the conclusion that the
difficulty of properly reviewing the Pull Request outweighs the benefit that
the Pull Request provides.

## AI Guidance

Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change.
Copy link
Member

@BenTheElder BenTheElder Dec 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should more explicitly call out the expectation to not submit --yoloed changes.

You're not just responsible for understanding the change, but more explicitly for having reviewed the generated output so as not to put the first pass on maintainers to review.

Rough sugestion:

Suggested change
Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change.
Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change.
Do not leave the first review of AI generated changes to maintainers, verify the changes (code review, testing, etc.) before submitting your PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea. I just modified this to say reviewers.

We should encourage first review by author in place of anyone reviewing the code. Not just the maintainers.

Do not leave the first review of AI generated changes to the reviewers, verify the changes (code review, testing, etc.) before submitting your PR.
Reviewers may ask questions about your AI-assisted code, and if you cannot explain why a change was made, the PR will be closed.
When responding to review comments, please do so without relying on AI tools. Reviewers want to engage directly with you, not with generated responses.
If you used AI tools in preparing your PR, please disclose this in the "Special notes for your reviewer" section.
All contributions must follow the [contributions policies](/contributors/guide/contributing.md) and use commit messages that align with [the policy](#commit-message-guidelines).
[Large AI generated](#large-or-automatic-edits) PRs and AI generated commit messages are discouraged.

## Fixing Linter Issues

Kubernetes has a set of linter checks. Some of those must pass in the entire
Expand Down