LLM으로 리뷰하기

LLM으로 코드 리뷰하기

작성 중인 언어에 린터나 포매터처럼 더 신뢰할 수 있는 도구가 이미 있다면, LLM 대신 또는 LLM과 함께 그 도구를 사용할 것을 강력히 권장합니다.
거짓 양성과 사소한 부분에 대한 과도한 집중은 흔하면서도 사람을 지치게 하는 실패 유형이므로, 이를 줄이도록 LLM 리뷰 도구를 설정하십시오.
가능하면 LLM에게 린터를 생성하거나 설정하도록 요청한 다음, 그 린터를 실행하도록 지시하십시오. 이렇게 하면 토큰 비용을 절약할 수 있을 뿐만 아니라, LLM을 사용하지 않는 사람도 분석을 실행할 수 있습니다. 예를 들어, 명령 실행을 감싸는 코드베이스 전용 래퍼가 있다면, LLM에게 래퍼를 사용해야 할 곳을 찾게 하는 대신 clippy가 Command::new를 금지하도록 설정하십시오.
LLM은 때때로 LLM이 생성한 출력, 특히 같은 모델이 생성한 출력을 선호합니다. LLM 리뷰는 참고용으로 취급하고, 변경 사항을 만든 모델을 유일한 리뷰어로 삼지 마십시오.

LLM이 만든 코드 리뷰하기

먼저 PR에 새로운 llm-assisted 레이블을 추가하십시오.

규칙

저희는 작성자뿐 아니라 모든 사람이 새 정책을 따를 것을 기대합니다. 즉, llm-assisted PR이 정책에서 허용하지 않는 영역을 건드리는지 확인하는 것은 여러분의 책임입니다. 작성자에게 LLM이 생성한 코드 없이 다시 작성하도록 요청할 수도 있으며, 그 경우 이 절은 적용되지 않습니다.

현재 다음 영역은 금지되어 있습니다:

건전성(soundness)에 영향을 주는 코드. 작성자가 해당 분야에 경험이 있는 조직 구성원이 아니라면, 반드시 PR을 닫아야 합니다.
진단 메시지. 사용자에게 보이는 모든 진단 메시지는 사람이 직접 작성해야 합니다.
문서. 모든 공개 문서 주석과 모든 // SAFETY 주석은 사람이 직접 작성해야 합니다.

“건전성에 영향을 주는 코드“는 들리는 것보다 더 넓기도 하고 더 좁기도 합니다. 컴파일러의 거의 모든 부분이 건전성과 관련되어 있다는 점에서 더 넓으며, rust-lang/rust에는 컴파일러가 아닌 부분(라이브러리, bootstrap, compiletest, rustdoc, CI 등)이 상당히 많다는 점에서 더 좁습니다.

확신이 서지 않는다면 다음 기준을 권장합니다: 잘못된 코드가 잘못되어 보이지 않는 컴파일러 부분에는 LLM이 생성한 코드를 허용하지 마십시오. 결국 이는 리뷰어인 여러분의 판단에 달려 있습니다.

여러분은 여전히 자신의 r+ 권한을 존중해야 합니다. 메인테이너가 LLM PR을 리뷰하기를 원하지 않더라도, 해당 코드 부분에 확신이 없다면 PR을 병합하지 마십시오.

사람들에게 #llm-mentoring을 적극적으로 안내하십시오. 품질이 낮은 PR은 닫고 작성자에게 정책을 따르도록 요청하는 방식으로 처리하십시오. 판단이 애매한 PR은 작업을 여러분에게 떠넘기지 말고 작성자가 직접 하도록 요청하는 방식으로 처리하십시오. 예를 들어 버그를 재현하거나, 변경 사항을 자신의 말로 설명하거나, 관련된 엣지 케이스를 찾아내거나, 테스트를 추가하거나 그 타당성을 설명하도록 요청하십시오.

여러 PR에서 같은 수정을 반복해서 제안하고 있다면, 그 내용을 dev-guide에 추가하는 것을 고려하십시오.

사용 사실 미공개

LLM 사용 사실을 밝히지 않았는데 “명백히” LLM으로 작성된 PR을 발견하면, 이를 일방적으로 닫을 수 있습니다. 다만 그렇게 해야 할 책임은 없습니다.

다음 문구를 사용할 것을 권장합니다:

This PR appears to be LLM-generated without disclosing use of an LLM, so I am going to close this PR.
You are welcome to open additional PRs as long as they follow our [policy][forge-page].
For more information, see [#llm-mentoring] on Zulip.

[#llm-mentoring]: https://rust-lang.zulipchat.com/join/rlfvpemsaacs3pfi6kwqnqjb/
[forge-page]: https://forge.rust-lang.org/policies/llm-usage.html

“명백한” LLM 사용 징후의 예는 다음과 같습니다:

완전히 틀렸거나 코드와 일치하지 않는 PR 설명.
실행한 테스트를 정확하게 명시하거나(예: ./x test --stage 1 tests/ui/<the-new-test-name>.rs) git diff --check와 같이 쓸모없는 테스트를 언급하는 PR 설명.
리뷰어의 질문에 대한 답변 중 위 범주 중 하나에 해당하는 것.

LLM으로 작성된 PR을 찾아낼 의무는 없습니다. 탐정 노릇을 할 필요는 없습니다.

PR 템플릿에는 “LLM을 사용했습니까?“라는 질문이 포함되므로 이런 일은 드물게 발생합니다. 작성자가 이 질문에 답하지 않고 삭제했다면, 아무것도 묻지 않고 PR을 닫아도 됩니다.

요청한 리뷰어 누락

PR이 LLM 사용 사실을 밝혔지만 실험 가이드라인에 따라 리뷰어를 지정하지 않았다면, 마찬가지로 닫을 수 있습니다:

You've opened an LLM-generated PR, but it's in the normal review queue, which breaks our [policy][experiment guidelines].
I am going to close this PR.
Please do not re-open it until you find a project member who has volunteered to review it.
For more information, see [#llm-mentoring] on Zulip.

[#llm-mentoring]: https://rust-lang.zulipchat.com/join/rlfvpemsaacs3pfi6kwqnqjb/
[forge-page]: https://forge.rust-lang.org/policies/llm-usage.html

테스트 누락, 낮은 품질 또는 자체 리뷰 미실시

PR이 명백히 리뷰할 준비가 되지 않았다면, 리뷰하지 않아도 됩니다. PR을 대충 훑어보고 작성자에게 “리뷰하기 전에 테스트를 추가해야 합니다“라고 말하기만 해도 괜찮습니다. 훑어보는 중에 PR의 접근 방식이 명백히 잘못되었다는 것을 알게 되면, PR을 닫고 작성자에게 새 PR을 열기 전에 #llm-mentoring 채널에서 여러분과 이야기하라고 말해도 괜찮습니다.

Rust 컴파일러 개발 가이드