doc: create ai-guidelines and include to CONTRIBUTING

[RafaelGSS]

As discussed in today's TSC meeting.

cc: @nodejs/tsc @BridgeAR

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[joyeecheung]

There may be some ideas we can borrow from https://llvm.org/docs/AIToolPolicy.html - for example "good first issue" should not be picked up by AI is a good one.

[RafaelGSS]

There may be some ideas we can borrow from https://llvm.org/docs/AIToolPolicy.html - for example "good first issue" should not be picked up by AI is a good one.

I took inspiration from https://github.com/zulip/zulip/blob/main/CONTRIBUTING.md#ai-use-policy-and-guidelines

[mcollina]

Do we have a template? I thought those are for issues, not PRs.

[legendecas]

Not strictly a template: https://github.com/nodejs/node/blob/main/.github/PULL_REQUEST_TEMPLATE.md?plain=1

[MikeMcC399]

It's not possible to fulfil the instructions "Complete pull request templates fully" based on the contents of https://github.com/nodejs/node/blob/main/.github/PULL_REQUEST_TEMPLATE.md?plain=1 so it looks like this sentence needs to be removed.

[gurgunday]

lgtm

[indutny]

I'd be against this contribution policy update. While many different opinions exist on the licensing terms of the code produced by LLMs, my opinion is that the generated code isn't explicitly licensed and attributed to the original authors so it cannot be considered open source regardless of the used prompt.

[mcollina]

Suggested change

	* **Verify accuracy** of any LLM-generated content before including it in a
	PR description or comment.
	* **Complete pull request templates fully** rather than replacing them with
	LLM-generated summaries.
	* **Verify accuracy** of any LLM-generated content before including it in a
	PR description or comment.

[joyeecheung]

In #61478 (comment) , regarding the usage of Claude Code, @mcollina suggested:

As it seems that you have a different position on this issue, I will bring this to the attention of the @nodejs/tsc for an official vote. On a side note, I would also officially summon the topic at the next OpenJS board meeting.

I added it to the TSC agenda tomorrow for awareness/context collection before moving to a proper vote. @indutny sorry about the short notice since this is just one day ahead of the meeting, but if you'd like to join the meeting to present your points please let us know.

[mcollina]

lgtm with a sentence removed

[indutny]

@joyeecheung thanks for considering me for this! I'd be happy to join if the time isn't in conflict with my work meetings tomorrow. Could you send me an invite, please?

[mcollina]

nodejs/TSC#1830 this is the issue. It might be reschedueld to the next meeting if there is low attedance given the timezone.

I think we can schedule the discussion for April 1st which will be in the morning PT so a lot of people can join, and I would table the vote for that session. I would try to get an answer from the Board by then.

addressed

[joyeecheung]

LGTM % a suggestion to spell out exactly how the "approval of automated tooling" works

[mcollina]

lgtm

[RafaelGSS]

PTAL @indutny @jasnell @mcollina

[jasnell]

Still generally disagree that this recommendation is at all necessary.

[jasnell]

Good enough for me. There are a few details I don't think are strictly necessary but given that they are recommendations and not hard requirements, I can live with it.

[mcollina]

@indutny @bengl ping

[mcollina]

Discussed at the last @nodejs/tsc.
After 2 weeks or more without a response, we consider the objection dismissed.

[RafaelGSS]

I have squashed the commits and solved the linting issue. Nothing has changed. PTAL.

[mcollina]

lgtm

Per Node.js guidelines, after 2 weeks or more without a response, we consider the objection dismissed.

[joyeecheung]

Some wording tightening and adding references..

Also I believe we should reference the large PR policy added by #62829 in this document, though not exactly sure where?

[joyeecheung]

Suggested change

	Contributors may use AI tools to assist with contributions, but such tools
	never replace human judgment.
	When using AI as a coding assistant:
	Tools should never replace human judgment, regardless of whether they are powered by AI.

[joyeecheung]

Suggested change

	* **Understand the codebase first.** Do not skip familiarizing yourself with
	the relevant subsystem. LLMs frequently produce inaccurate descriptions of
	Node.js internals — always verify against the actual source. When using an AI
	tool, ask it to cite the exact source it’s relying on, and then
	match the claim against that resource to verify if it holds up in the current
	code.
	* **Understand the codebase first.** Do not skip familiarizing yourself with
	the relevant subsystem. Always verify analysis generated by tools against
	the actual source code.

[joyeecheung]

Suggested change

	* **Own every line you submit.** You are responsible for all code in your
	pull request, regardless of how it was generated. This includes ensuring
	that AI-generated or AI-assisted contributions satisfy the project's
	[Developer's Certificate of Origin][] and licensing requirements. Be
	prepared to explain any change in detail during review.
	* **Own every line you submit.** You are responsible for all code in your
	pull request, regardless of how it was created. The submitted changes
	must satisfy the project's [Developer's Certificate of Origin][] and licensing
	requirements. Be prepared to explain any change in detail during review.

[joyeecheung]

Suggested change

	* **Keep logical commits.** Structure commits coherently even when an LLM
	generates multiple changes at once. Follow the existing
	[commit message guidelines][].
	* **Keep the commits logical.** The [commit message guidelines][]
	and [commit squashing guidelines](./pull-requests.md#commit-squashing)
	must be followed regardless of what tool is used in the pull request.

[joyeecheung]

Suggested change

	* **Test thoroughly.** AI-generated code must pass the full test suite and
	any manually written tests relevant to the change. Existing tests should not
	be removed or modified without human verification. Do not rely on the LLM
	to assess correctness. It is crucial to manually verify the correctness of
	tests against the expected behavior of the feature being tested,
	independently of the feature's implementation.
	* **Test thoroughly.** Existing tests should not be removed or modified
	without human verification. It is crucial to verify, with human judgement,
	the correctness of tests against the expected behavior of the feature being
	tested, independently of the feature's implementation.

[joyeecheung]

Suggested change

	* **Edit generated comments critically.** LLM-generated comments are often
	verbose or inaccurate. Remove comments that simply restate what the code
	does; add comments only where the logic is non-obvious.
	* **Keep the comments useful.** Verify with human judgement that the
	comments are necessary and accurate. Remove comments that simply
	restate what the code does. Add comments only where the logic is non-obvious.

[joyeecheung]

Suggested change

	## Using AI for code contributions
	## When AI is used in contributions

[joyeecheung]

Suggested change

	## Using AI for communication
	## When AI is used for communications

[joyeecheung]

Suggested change

	* **Do not post messages generated entirely by AI** in pull requests, issues, or the
	project's communication channels.
	* **Verify accuracy** of any LLM-generated content before including it in a
	PR description or comment.
	* **Link to primary sources** — code, documentation, specifications — rather
	than quoting LLM answers or linking to LLM chats.
	* **Do not post messages generated entirely by AI** in pull requests, issues, or the
	project's communication channels. Such communication may be removed in accordance
	to [the Node.js moderation policy](https://github.com/nodejs/admin/blob/main/Moderation-Policy.md).

I think we should hash out the "what can be in communications" in the moderation policy, not here..

[joyeecheung]

Suggested change

	If the disclosure involves trademarks or commercial brands, it's recommended to
	anonymize it in the commit message or only mention the brand/trademark in the
	PR description, but not in the commit message, unless the context would not
	have made sense without mentioning the specific brand/trademark. The goal
	is to prevent the commit messages, which are part of the codebase, from being
	abused for profit-driven marketing.
	Be aware that the mention of for-profit trademarks or commercial brands in commit
	messages, which are part of the code base, can be abused for profit-driven marketing.
	If the disclosure involves for-profit trademarks or commercial brands, it's
	recommended to either anonymize the branding (e.g. say `a frontier reasoning model`,
	`a closed-source coding agent` instead of `<brand>`), or only mention the
	for-profit brand/trademark in the PR description, but not in the commit message,
	unless the message would not have made sense without mentioning the specific
	brand/trademark. These recommendations only apply to for-profit tools/models, not
	any non-profit ones.

(I don't know how far we are from this, but it's seems totally possible that there can be public, non-profit model providers in the future. That and non-profit open source harness already exists, in those cases these recommendations wouldn't make as much sense).