3 ms·
I like this but would think "Semantic" is pushing it a bit as it relies on function names and changes therein having a direct mapping to meaning with standard t
by mellosouls 8mo ago
I like this but would think "Semantic" is pushing it a bit as it relies on function names and changes therein having a direct mapping to meaning with standard text processing.
In fact, I fully expected a use of LLM to derive those meaningful descriptions before I checked the repo.
Anyway I definitely see this as a useful thing to try out as a potential addition to the armoury, but as we go further along the route to AI-coding I expect the diffs to be abstracted even further (derived using AI), for use by both agentic and human contributors.
- RaftPeople 8mo ago> I like this but would think "Semantic" is pushing it a bit It would be nice to get to the feature level, meaning across files/classes/functions etc.
- rs545837 8mo agosem already does this. sem graph builds a cross-file entity dependency graph and sem impact tells you "if this function changes, these other entities across these many files are affected." It's transitive too, follows the full call chain.
- rs545837 8mo agoYou're right that "semantic" is doing some heavy lifting in the name. We use it to mean "understands code structure" rather than "understands code meaning." sem knows that something like "validateToken" is a function and tracks it as an entity across versions, but it doesn't know what validation means. For the merge use case (weave - https://ataraxy-labs.github.io/weave/ https://ataraxy-labs.github.io/weave/), that level of understanding is enough to resolve 100% of false conflicts on our benchmarks. LLM-powered semantic understanding is the next layer, and that's what our review tool (inspect) does, it uses sem's entity extraction to triage what an LLM should look at.