$ 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

Okay that is pretty cool. I appreciate this information as a human also.

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!)

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.

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.

I have been using all of ataraxy labs tools for the past few months and that have been indispensable for models to make less mistakes for me. From better git diffs to impact analysis and code reviews.

This is really neat. I’m working on something similar but for data artifacts not just code. It’s very encouraging to see that this kind of tooling helps both humans and models, that was what made me starting to work on that.

Looks very useful, but incredibly obnoxious that it overrides default git diff. And the only way to get the regular git diff output is to uninstall it? There is no way I would ever want to do that.

This looks really neat, but I see its diff output as complimentary to git and wouldn’t want to replace git diff. Is there a way to just install the CLI and MCP server but not override git diff?

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 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.

Interesting idea. How does it, or how should it, perform in huge monorepos, where git performance suffers? I spend most of my time in a repo that contains hundreds of thousands of files, where just a simple `git status` can take >3.5 seconds even on very fast consumer hardware. (Thank God for sparse-checkout.)

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...

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

A step in the right direction, and interesting in that it layers over existing git rather than requiring a whole new (unfamiliar, untested) SCCS.

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.

Another potential use case: This may help jujutsu auto split a large revision into small orthogonal revs.

Sometimes agent makes a monolithic commit and it's a lot of work to manually split code you didn't write. After such an auto split I can manually squash related revs into feature/ticket level.

undefined

[flagged]

[flagged]