The graph generator looks interesting, but the rest of the blog post is filled with so much marketing it's a slog to get through to the good bits. I struggle to imagine a scenario where I willingly choose the "Trails" view even if, and god help us if it is, that's the direction PR review is going.
Yes, I will say it's a high-AI-trust approach. I can see this being adopted by people like Anthropic who already don't read the code. Personally I'm still trying to get my company to add AI review to MRs :(
Rather than write an essay about why we built this, I’d rather just answer whatever you’re skeptical about. Happy to get into the actual mechanics: how sessions get attached to commits (it’s git refs, not a side db), what the 89x push number does and doesn’t mean, where the context/token savings fall apart, who can read whose session transcripts, how you’d migrate off if you hated it, whatever.
The one thing I’ll say up front: The bet is that once agents write most of the code, the PR stops being the right unit of review, because the diff is cheap and the “why” vanishes when the session ends. Everything else follows from that.
Would there have been value, pre-LLMs, in attaching a screen recording of what a developer did in the three hours before posting their diff (be it Google, stack overflow, reading a book, or trying a sandbox experiment) to their PR? The PR is a synthesis of their efforts, and it would actually be more effort to review and understand their screen recordings, wouldn't it? In my experience striving for fewer artifacts is the right move, so long as they are sufficient to describe the outcome. What exactly is lost between sessions and code that would help you debug something?
Also, if your business has agents writing most of the code, why would your business care about human reviews at all? In for a penny, in for a pound, after all. Wouldn't you be better off looping your agents into your support tickets and autofixing bugs? In that scenario, isn't it more confusing for an agent to deal with sessions + code rather than start fresh with the code?
The graph generator looks interesting, but the rest of the blog post is filled with so much marketing it's a slog to get through to the good bits. I struggle to imagine a scenario where I willingly choose the "Trails" view even if, and god help us if it is, that's the direction PR review is going.
Yes, I will say it's a high-AI-trust approach. I can see this being adopted by people like Anthropic who already don't read the code. Personally I'm still trying to get my company to add AI review to MRs :(
The change we were all waiting for!
Field CTO at Entire, so obviously biased.
Rather than write an essay about why we built this, I’d rather just answer whatever you’re skeptical about. Happy to get into the actual mechanics: how sessions get attached to commits (it’s git refs, not a side db), what the 89x push number does and doesn’t mean, where the context/token savings fall apart, who can read whose session transcripts, how you’d migrate off if you hated it, whatever.
The one thing I’ll say up front: The bet is that once agents write most of the code, the PR stops being the right unit of review, because the diff is cheap and the “why” vanishes when the session ends. Everything else follows from that.
Ask away, I’ll be in the thread for a while.
Would there have been value, pre-LLMs, in attaching a screen recording of what a developer did in the three hours before posting their diff (be it Google, stack overflow, reading a book, or trying a sandbox experiment) to their PR? The PR is a synthesis of their efforts, and it would actually be more effort to review and understand their screen recordings, wouldn't it? In my experience striving for fewer artifacts is the right move, so long as they are sufficient to describe the outcome. What exactly is lost between sessions and code that would help you debug something?
Also, if your business has agents writing most of the code, why would your business care about human reviews at all? In for a penny, in for a pound, after all. Wouldn't you be better off looping your agents into your support tickets and autofixing bugs? In that scenario, isn't it more confusing for an agent to deal with sessions + code rather than start fresh with the code?
i guess the main thing is "why would give you my proprietary agent-facing information when i can store context literally anywhere?"
is the carrot JUST the time savings for large dev orgs?