sem

Git diffs are great for humans scanning line noise. But agents need to understand changes: "added function X", "renamed symbol Y", "moved block Z". sem computes semantic diffs on top of your Git repo—no repo rewrite needed. Repo: https://github.com/Ataraxy-Labs/sem Key ideas: Parses code to AST, computes tree‑edit ops (add/remove/move/change). Outputs human‑/agent‑readable patches: "diff_sem" shows intent, not whitespace churn. Applies deterministically via git apply --sem—survives formatting shifts or unrelated edits. Use cases popping up: Agent codemods: output semantic patches instead of brittle hunks. Review tools: "explain this PR as semantic changes". Stacked diffs / Graphite: semantic base for stacks. Bulk refactors: apply "rename all X to Y" across noisy repos.

We ran 24 API calls through Claude Sonnet 4.6 - same questions about code changes, same model, same temperature. One gets git diff output. The other gets structured JSON from sem diff. Results: 95.9% accuracy vs 41.5%. The failure modes are systematic, not random: 1. git diff has no concept of "entity." Ask an agent to count added functions and it counts + lines instead. On one commit it reported 238 adds - that was the number of + lines. Actual: 32 entities. 2. No way to distinguish add vs modify. A modified function shows +/- hunks, same as a new function in a changed file. The model listed 9 "added" functions - 4 were actually modified. Precision: 55.6%. 3. No entity type vocabulary. Asked for entity type counts, the model returned {"file": 11}. It counted files because line diffs have no AST. Truth: 15 functions, 12 interfaces, 3 vari