How Senix analyzes pull requests

Every review runs through the same pipeline: a webhook kicks it off, tree-sitter builds a structural diff, and the LLM turns that into a behavioral summary.

The pipeline

webhook → fetch PR diff → tree-sitter parse → structural diff → LLM analysis → comment posted

When a PR opens or receives a new push, GitHub delivers a pull_request webhook. Senix verifies the signature, fetches the diff, parses each supported file, compares symbols, sends the result to the LLM, and posts a single comment back on the PR.

What is a structural diff?

A plain text diff tells you which lines changed. That is noisy — a reformatted file or a renamed variable looks like a big change but does nothing behaviorally. Senix does something different: it parses the before and after of each file into symbols — functions, classes, methods, top-level constants — and compares those.

The model sees which symbols were added, removed, or modified, with their bodies. A pure rename or whitespace change produces no symbol-level difference, so it never reaches the model as a behavioral change.

Supported languages

Structural diffing depends on a tree-sitter grammar per language. PRs touching unsupported file types still get a review, just without symbol-level detail.

What we send to the LLM

To be precise about it — the model does not receive your raw files. It receives:

• Function and method signatures of changed symbols
• Structural changes — which symbols were added, removed, or modified
• The body text of changed symbols (truncated for very large functions)
• PR metadata: file count, additions, deletions

Unchanged symbols are skipped entirely. Files that did not change are never read.

Average latency

Most PRs complete in 20-40 seconds end-to-end. Large PRs can take up to 60 seconds; analysis is capped past that to keep cost and response time predictable.