rs545837

5 ms·

1.
by rs545837 4mo ago
Damn this was really fun to use.
2.
by rs545837 5mo ago
I agree 100% with this thinking approach, I've been working in this domain for quite a few months now. The right granularity for agents isn't files or lines, it's entities: functions, classes, methods. That's how both hu
3.
by rs545837 5mo ago
yeah definitely plastic scm has always been my inspiration, just trying to revive it.
4.
by rs545837 5mo ago
Oh this is cool. The Yjs as storage backend trick is clever, you basically get CRDT sync for free without having to build your own replication layer. And the pluggable storage means you can develop against in-memory and then flip to YGraph
5.
by rs545837 5mo ago
Think two agents working on the same codebase at the same time. Agent A is refactoring the auth module, Agent B is adding a new API endpoint that imports from auth. Separate worktrees, separate branches, but they're touching overlappin
6.
by rs545837 5mo ago
You could agree that the PR is the meaningful unit for shipping, but push back gently that for agents working in parallel, the commit/changeset level matters more than it used to because agents don't coordinate the way humans do.
7.
by rs545837 5mo ago
jj is genuinely great and I think it deserves way more adoption than it has right now. The mental model is so much cleaner than git, undo actually works the way you'd expect it to, and working with stacked changes feels natural instead
8.
by rs545837 5mo ago
This is awesome honestly, Stacked PRs are one of those features that feels obvious in hindsight. Breaking a n-line PR into 3 focused layers where each one is independently reviewable is a huge win for both the author and reviewer. The nativ
9.
Structural and semantic component for improving code reviews with local models
2 points by rs545837 5mo ago|0 comments
10.
by rs545837 6mo ago
One cheap optimization for the compile overhead case: skip commits that only touch files unrelated to the failing test. If you know the test's dependency chain, any commit that doesn't touch that chain gets prior weight zero. Equi
11.
by rs545837 6mo ago
This is a real pain point. One thing that helps: when an LLM agent makes changes across multiple commits, look at what it actually touched structurally. Often the agent adds a feature in commit 5 but subtly breaks something in commit 3 by c
12.
by rs545837 6mo ago
You're right, at 300 tests bayesect converges to ~97-100% across the board. I reran with calibration.py and confirmed. Went a step further and tested graph-weighted priors (per-commit weight proportional to transitive dependents, Paret
13.
by rs545837 6mo ago
Yes, bayesect accuracy increases with more iterations. The comparison was at a fixed budget(300 test runs) when I was running. Sorry should have clarified more on that.
14.
by rs545837 6mo ago
Really fun work, and the writeup on the math is great. The Beta-Bernoulli conjugacy trick making the marginal likelihood closed-form is elegant. We ran benchmarks comparing bisect vs bayesect across flakiness levels. At 90/10, bisect d
15.
by rs545837 6mo ago
usually the whole discussion has been around line-level vs commit-level history, but there's a layer nobody's talking about, and I have been exploring it here these days with https://github.com/Ataraxy-Labs/se
16.
by rs545837 6mo ago
You can, but it's slow, expensive, and hallucinates. An LLM looking at a raw diff might miss a renamed function or invent a dependency that doesn't exist. sem does it structurally: parses both sides with tree-sitter, computes stru
17.
by rs545837 6mo ago
Right, sem gives you both. sem diff --verbose shows the full before/after body of each changed entity. The entity-level view tells you what changed and what's affected. The line-level detail is still there when you need it.
18.
by rs545837 6mo ago
We've been building an open source tool called sem ( https://github.com/ataraxy-labs/sem ) that takes this one level further: entity-level diffs instead of AST-level. Instead of showing you which syntax nodes change
19.
What if CRDTs for version control worked at entity granularity instead of lines?
1 points by rs545837 6mo ago|0 comments
20.
Inspect – Semantic code review. Entity graphs + LLMs(inspect.ataraxy-labs.com)
1 points by rs545837 6mo ago|0 comments
21.
by rs545837 6mo ago
That's a really sharp parallel. "Did behavior change" is exactly the question in both cases, and the surface-level representation lies to you in both. We normalize ASTs before hashing so reformatting or renaming a local varia
22.
by rs545837 6mo ago
Great, did you opensource it?
23.
by rs545837 6mo ago
Pretty much, yeah. sem graph builds a cross-file entity dependency graph and sem impact does transitive traversal on it. So you can ask "if I change this function, what breaks?" and get a deterministic answer without sending anyth
24.
by rs545837 6mo ago
difftastic is solid. The difference is roughly: syntax-aware (difftastic) knows what changed in the tree, sem knows which entity changed and whether it actually matters. difftastic will show you that a node in the AST moved. sem will tell y
25.
by rs545837 6mo ago
Ah right, array ordering not key ordering. That's a different beast. You're making a deliberate semantic choice because you know your consumers are order-invariant. We can't really do that at our level since function ordering
26.
by rs545837 6mo ago
Thanks for the request, Yeah I can work on this.
27.
by rs545837 6mo ago
Exactly. The only reason line-level diffs survived this long is that text is the lowest common denominator. Once you have fast enough parsers (tree-sitter parses most files in under 1ms), there's no reason to stay at the line level.
28.
by rs545837 6mo ago
sem 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 ful
29.
by rs545837 6mo ago
You'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 "validateToke
30.
by rs545837 6mo ago
Different project, same author. sem has been sem since the first commit. Beagle looks interesting, storing ASTs directly in a KV store is a different approach. sem stays on top of git so there's zero migration cost, you keep your exist

More ›