Hacker News: rohanucla

New comment by rohanucla in "Cleaning up after AI rockstar developers"

rohanucla — Tue, 09 Jun 2026 14:52:28 +0000

Nice Blog!

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Mon, 08 Jun 2026 13:50:04 +0000

I mean we are trying to be faster than LSPs, LSPs are a little slow for enterprise grade codebases

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 23:11:07 +0000

There is a skill.md for the agent to know about the cli, I can make update the same with more examples.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 15:34:15 +0000

Thanks a lot Alex! for this reply, it keeps us pumped.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 15:32:35 +0000

no setup just configures your git diff to use sem by defult, you will find the sem mcp directory on github repostiory, also there's skill.md file which will tell your agent on how to use sem.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 15:31:14 +0000

sorry if you consider that as hijack, it was just a user's request to use this as default plugin on their git. But I will add it to let the users know thanks for the feedback

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 08:23:47 +0000

It doesn't override git diff at all, sem is its own standalone CLI. git diff continues to work exactly as before. You do sem setup only when you want to change your default git diff behavior, other wise after installing sem you can use it straight away using sem commands.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 08:22:19 +0000

sem doesn't override git diff, it's a completely separate command (sem diff). Your regular git diff should work exactly as it always has after installing sem.

If you want to change your git diff default behavior then you can do sem setup.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 05:36:51 +0000

This is actually the exact scenario we just spent the last few weeks optimizing for. On a 71K-file TypeScript monorepo, sem was previously choking entirely (DNF), and now completes in 6.5s with the topology cache warm. On a 100K-file generated fixture, sem impact went from 90s cold down to about 1s warm. The key was building a SQLite-backed cache that stores the dependency graph structure so repeat runs skip re-parsing unchanged files entirely.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 04:21:02 +0000

Appreciate it!

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 04:06:00 +0000

That's a really compelling use case actually

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 03:58:49 +0000

Thanks! The data artifacts angle is really interesting. in some ways the problem is even harder there because data pipelines have less explicit structure than code, I guess.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 03:53:54 +0000

haha definitely!

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sun, 07 Jun 2026 01:23:39 +0000

git is actually great, and there are not much of the issues as the world says about it, and the best is to build complimentary layers that makes it even stronger is the best bet I guess.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sat, 06 Jun 2026 23:55:10 +0000

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.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sat, 06 Jun 2026 23:26:56 +0000

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.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sat, 06 Jun 2026 23:14:49 +0000

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.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sat, 06 Jun 2026 23:08:57 +0000

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.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sat, 06 Jun 2026 22:52:55 +0000

Thanks for pointing it out. I agree with you here, my testing process was quite specific to sem's output but also would love any suggestion from you of how you would design the whole testing process for this kind of tool?

I can also give my thought process, because I was more interested in figuring out the model's inherent search results and understanding without sem.

New comment by rohanucla in "Sem: New primitive for code understanding – not LSPs, but entities on top of Git"

rohanucla — Sat, 06 Jun 2026 22:50:19 +0000

Really glad you've been using it, and yeah that's exactly the direction I've been thinking about. The line diff as the default view in code forges has always felt like an accident of history it definitely was easy to compute, but not what's actually useful for understanding what changed.