docs: recommend LLM spell/type-checking before substantive review - #352
Open
cfm wants to merge 1 commit into
Open
docs: recommend LLM spell/type-checking before substantive review#352cfm wants to merge 1 commit into
cfm wants to merge 1 commit into
Conversation
cfm
marked this pull request as ready for review
September 3, 2026 00:38
cfm
force-pushed
the
suggest-llm-review
branch
from
September 3, 2026 00:39
4ee49d5 to
27874b6
Compare
Member
Author
|
Rebased from |
rocodes
force-pushed
the
suggest-llm-review
branch
from
September 3, 2026 10:48
27874b6 to
12d1c50
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I've found LLMs (both locally and in GitHub's Copilot code review) to be very helpful in both "spell-checking" (Is that what I meant?) and "type-checking" (Have I contradicted something else here?) the protocol specification, especially across different idioms and styles of notation.
I'm suggesting this recommendation here because I think of this much like static analysis and other linting for code: It's better to do before changes get merged; it's better to do so before spending time reviewing the substance of changes; and (in contrast to substantive review) it's pretty painful to do manually in GitHub. But this may not be the approach we want to take or recommend, for any of a host of reasons.