Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ataraxy-labs.github.io

Post reply on HN
Print view View original

11–20 of 67 posts

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

#11

Post by rohanucla »

hankbond wrote: post #6
hankbond wrote: post #4

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 +…

Also I keep seeing solutions in this space that are doing inheritance and call stack dependency linkage, but I haven't seen the same level of exploration into data lifetime dependency. Not lifetime in the way it exists in Rust (to my knowledge), but like including when you copy data and transform that copy. The motivation is "if I change this variable, enumerate all the areas that change would propagate to". The idea…

This is a really interesting direction, you're essentially talking about data flow or taint analysis, where you track how a value propagates through copies and transformations rather than just following call edges. Honestly pure static analysis gets you partway there but it hits real limits once you run into dynamic dispatch, runtime branching, or serialization boundaries where data gets written somewhere and read back in a completely different part of the codebase.

We're on the structural side right now with call graphs and dependency edges, but a hybrid approach that combines the static graph with runtime instrumentation to fill in the gaps is definitely something I'd love to explore. Thanks for the feedback.

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

#12

Post by andai » 

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

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

#13

Post by rohanucla »

andai wrote: post #12

$ 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 depe…

Ha, the regex approach is honestly how a lot of people start with this problem and you can get surprisingly far with it until you hit the edge cases around aliased imports, re-exports, and nested scopes where things start falling apart. That's basically why we went with tree-sitter under the hood it gives you the actual parse tree so you don't have to keep patching regex patterns for every new language construct.

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

#15

Post by rohanucla »

docheinestages wrote: post #14

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.

Lemme give you an example. when you're working in a 100K-file TypeScript monorepo and you change a utility function that parses API responses. git diff tells you that you changed n lines in that function. What it doesn't tell you is which services, components, and tests actually depend on that function across the repo. You're left grepping for the function name, hoping nobody aliased the import or re-exported it through a barrel file. sem impact gives you that full downstream dependency list in seconds, so you know exactly what to review and test before you ship.

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

#16

Post by onlyrealcuzzo »

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.

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

#17

Post by jawns »

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.

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

#18

Post by rohanucla »

jawns wrote: post #17

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 sorry, should have put up a warning there, but You can do sem unsetup, if you go to the github, you will understand more about the way to reverse it.

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

#19

Post by rohanucla »

onlyrealcuzzo wrote: post #16

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…

[dead]

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

#20

Post by throw1234567891 »

rohanucla wrote: post #3
Animats wrote: post #2

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

It can do that, but that's a small slice of what it does. sem parses your codebase into entities (functions, classes, methods) and builds a dependency graph across files. So instead of line level analysis the whole granularity of seeing changes and tracking thing shifts to entities. It helps in attention mapping of your agent and lets you track the changes faster. LSPs have been doing it for quite long but using tree…

The tool looks great! Thanks for sharing.
Post reply on HN