Large-diff chunking

Some PRs are monster refactors with thousands of changed lines. You cannot shove a 300KB diff into a single prompt and expect a coherent review. You need a strategy to either truncate or split the diff, and the right answer depends on how much budget you have.

review_engine.py
python
# Truncate huge diffs so we do not blow the context window. Students can
# swap this for a chunking strategy in a later challenge.
max_chars = 12000
diff_text = (
    pr.diff
    if len(pr.diff) <= max_chars
    else pr.diff[:max_chars] + "\n...[truncated]"
)

The shipped code uses a hard character cap as a safe default. It is crude but predictable. You always know you will fit inside the model context, and the truncation marker is visible in the prompt so the LLM knows it is working on a slice.

review_engine.py
python
from typing import Iterator


def chunk_by_file(diff: str) -> Iterator[str]:
    """Split a unified diff at each file boundary.

    Every chunk is a standalone mini-diff. The LLM can review one file at
    a time without losing hunk headers or line anchors.
    """
    current: list[str] = []
    for line in diff.splitlines(keepends=True):
        if line.startswith("diff --git ") and current:
            yield "".join(current)
            current = []
        current.append(line)
    if current:
        yield "".join(current)

Splitting on the git diff header gives you one chunk per file. Each chunk keeps its own hunk headers and line numbers, so review comments still anchor correctly. You can then review files in parallel or sequence, merging the results at the end.

Line-count splits break hunk headers. If a chunk starts in the middle of a hunk, the LLM loses the @@ markers that tell it which line numbers to reference. File boundaries are the only safe split point for a unified diff, because every file starts with a fresh header that re-anchors the context.

Quiz: Quiz

Loading practice…

Checkpoint: fetch_pr_diff checkpoint

Loading practice…