Sem: New primitive for code understanding – not LSPs, but entities on top of Git

The "Try it. 10 seconds." section at the bottom of the page hijacks an existing tool (git diff) and installs a pre-commit hook.

But there are no instructions for how to reverse those actions if you don't like the tool. Feels a little user-hostile to me.

  $ sem impact authenticateUser

  ⊕ function authenticateUser (src/auth/login.ts:26)

    → depends on:    db.findUser, rateLimiter.check
    ← used by:       loginRoute, authMiddleware
    ! 42 entities transitively affected
    ᛋ 7 tests affected

I got about halfway through reinventing something like this last year (minus the git part). I was trying to make a graph of dependencies in the codebase. (I actually got pretty far with a regex!)

I doubt if this actually solves a real problem for humans or agents, especially in complex projects. It might help if the examples show scenarios where this tool and its commands could make a difference.

I am interested in subtle ways in which we can change how we write software to get better outcomes out of harnesses (model + tools + skills). I'm imagining that use of Sem will be more effective on code written in some shapes than others.

Can you describe what ways this might be beyond just breaking up code into smaller functions?

An example of this is that Models tend to create unit tests that are mostly just mock + reimplementations of imperative code in the functions they test. If you could force behavioral testing by only allowing test creation agents to accessing the function docstring, name/args/types, branch statements and log events, you could potentially avoid these classes of weak tests being created. But that would mean that your code has to optimize to providing signal via those elements.

This is just an example I'm not sure that would actually work.

The benchmarks aren't great, they're super specific to sem's output: why would I ask Claude how many "entities" were modified by a commit and do I need a tool specifically for this request ? Note that an "entity" is a sem-specific concept...

I really like this idea and have been experimenting with it over a week or so.

I think there’s an opportunity to use an AST diff system for code forges where you don’t present the user with line diffs in the UI — or at least not as the first diff the user sees.

I firmly believe code review should happen in your editor.

Okay, this looks great, but for the love of God... please cut this out:

> AI agents are 2.3x more accurate when given sem output vs raw line diffs. See the benchmark.

No... This is not convincing of anything. These are not real world tasks.

You're trying to pretend like your tool makes AI agents 2.3x better at coding or bug fixing.

It doesn't.

Your benchmark doesn't prove that.

Your tool is cool. Sell it for what it is. Not for what it's not.

Is this for checking what Claude Code just did to your repo?