The Sem team argues that LSP's file-and-position model fundamentally breaks when functions are renamed, moved, or refactored — the symbol identity resets. They propose entities with stable identity derived from Git history, AST structure, and content hashing, producing a queryable graph of code relationships over time rather than ephemeral hover tooltips.
By submitting Sem with the framing 'not LSPs, but entities on top of Git,' the submitter endorses the thesis that the LSP's symbol-at-a-position model is the wrong primitive for the AI-agent era. The implicit argument is that code understanding tools need stable identities that survive refactors.
Skeptical commenters in the thread push back by asking how Sem handles merge conflicts, rebases, and squashed history — situations where Git's own notion of identity is contested. Their position is that the LSP's snapshot model is honest about what it knows, while a Git-derived entity graph inherits all of Git's identity ambiguities without clearly solving them.
Enthusiastic commenters note that Cursor, Claude Code, Aider, Continue, and Cline have all been bolting entity-tracking layers on top of tree-sitter and git log for the past year. Their position is that Sem's contribution is consolidating this scattered effort into a shared primitive, which has real value even if the underlying ideas aren't novel.
The editorial argues that LSP elegantly solved the M×N editor-language problem in 2016, but its core design target — a human typing in a single working-tree snapshot — is mismatched with how AI agents actually consume code. Agents burn token budget re-resolving symbols across snapshots, which is exactly the workload an entity-based, history-aware primitive is shaped to serve.
A project called Sem, from Ataraxy Labs, hit the front page of Hacker News this week with an unusually ambitious framing: it pitches itself as a *new primitive for code understanding*, explicitly positioned against the Language Server Protocol. The landing page is blunt — Sem isn't an LSP, it's a layer of stable code entities built directly on top of Git.
The technical claim is narrow but consequential. Today, when you ask your editor 'where is this function defined?' or 'who calls this method?', the Language Server Protocol resolves the question against a single working-tree snapshot. The unit of analysis is a *symbol at a position in a file*. Move the function to another file, rename it, split it into two — the LSP's mental model resets. The symbol, as far as the protocol is concerned, is a new symbol.
Sem proposes a different unit: the entity. A function, class, module, or block gets a stable identity that persists across renames, file moves, and refactors. That identity is derived from Git history, AST structure, and content hashing rather than from a file path. The output isn't a hover tooltip — it's a queryable graph of entities and their relationships over time. The HN comment thread sits at 82 points with the usual mix: skeptics asking how it handles merge conflicts, enthusiasts noting this is what every AI coding agent has been trying to bolt on top of `tree-sitter` and `git log` for the past year.
The LSP, released by Microsoft in 2016, was designed for one job: decouple editor UI from language tooling so VS Code didn't have to ship a TypeScript compiler and Vim didn't have to ship a Rust analyzer. It solved the M×N problem for editors and languages, and it solved it well — but it solved it for humans typing in a buffer.
That assumption is now load-bearing in ways it wasn't designed for. AI coding agents — Cursor, Claude Code, Aider, Continue, Cline — spend an enormous amount of their token budget reconstructing context that LSPs throw away by design. *Where has this function lived over the last six months? Who touched it last? Is this the canonical implementation or one of three near-duplicates we never deleted?* These are Git questions wearing code-intelligence clothing, and the LSP has no opinion on them because it was never asked to.
Sem's bet is that the substrate matters. If your atomic unit is 'symbol at line 47 of foo.ts on this commit,' you cannot cheaply answer questions about evolution, ownership, or duplication. If your atomic unit is an entity with a stable ID that Git can track, those questions become indexable. Compare this to how `tree-sitter` quietly took over the syntax-highlighting world by treating parsing as a service rather than a feature — Sem is making the same bet one layer up, on semantic understanding.
The HN skepticism is fair, though. Stable entity IDs across renames are a hard problem. `git log --follow` famously misbehaves on aggressive refactors. Two independent reviewers in the thread point out that the demo handles the easy cases (rename a function, the entity persists) but doesn't show what happens when you split one class into three, or when a developer cherry-picks across branches. The team's response — that the entity graph is *probabilistic with confidence scores*, not deterministic — is honest, but it's also the kind of caveat that quietly grows into a footnote everyone learns to dread.
The other open question is performance. LSPs are slow enough that nobody loves them; a layer that has to consult Git history to answer 'go to definition' will need aggressive caching or it dies on the first 100k-LOC monorepo. The Sem docs gesture at an indexed snapshot store but don't publish benchmarks, which for a tool pitched at this level of ambition is conspicuous.
If you're building developer tooling — especially anything AI-adjacent — this is worth understanding even if Sem itself never ships v1. The category Sem is staking out is real, and somebody is going to own it: a Git-native, language-agnostic, entity-level index that AI agents and review tools can query without re-parsing the world on every prompt.
For agent builders, the practical takeaway is this: stop treating Git as a deploy mechanism and code as a flat text corpus. The agents that actually understand a codebase six months from now will be the ones that have indexed the *history* — who introduced this pattern, which entities cluster together in commits, what was reverted and why. You can prototype this today with `tree-sitter` + `libgit2` + a vector store, which is essentially what Sem is productizing.
For editor and IDE teams, the LSP isn't going anywhere — it's too entrenched, and the human-typing-in-a-buffer use case is still 90% of the work. But expect a companion protocol layer to emerge for entity-level queries. JetBrains has been quietly doing some of this internally for years; the open question is whether the protocol gets standardized (LSP-style) or stays proprietary per-vendor.
For everyone else: if your codebase is over ~50k LOC and you've ever lost an afternoon to 'where did this function go, I swear it existed last sprint,' you are exactly the user Sem is targeting. The Git-history-as-first-class-citizen approach is the kind of idea that sounds obvious in retrospect and will look inevitable in five years.
Whether Sem specifically wins is almost beside the point. The interesting signal is that the assumption underlying a decade of code tooling — *the file is the unit, the snapshot is the truth* — is finally getting questioned by people building for AI-agent consumers rather than human-keyboard consumers. The next round of dev tooling won't compete with LSPs; it'll sit at a different altitude entirely, treating the repo as a database and Git as the transaction log. Sem is one of the first projects to say that out loud.
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 brea
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.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
$ 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