Very cool. I think a focus on AI code review and continuous knowledge graph synthesis are both right directions, and any system that provides the infrastructure to automatically handle these tasks eventually must do the job of a Git Forge, even if it runs locally.
I am tackling the problem from a different direction, but I think there's a lot here to be inspired by.
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.
Hey, Haimantika here from the Entire team. Thank you for the feedback on blog, we will work on it for our future announcements.
For Trails: There’s agent sessions, gates, agents(evals basically) and checks - so it gives you all the information you need to review better (compared to the diffs for example).
Throwing out some thoughts after reading the docs page(s):
1. The "What are trails" section does not actually tell me what trails are; it tells me it brings agents and devs together, and that branches are involved somehow through "changes", but it doesn't actually tell me what they are
2. I am never going to willingly watch a Youtube video embeded in docs. I'm barely going to watch a video in a docs page at all. I'm here to learn how to use something, not see a sponsored ad for NordVPN.
3. The marketing blurb, the top half of the docs, and the bottom half ("Enable Trails" onwards) all feel like their describing different things. The marketing blurb describes a total reinvention/view of the PR layout where instead of seeing diffs you see different bars that you can balance by telling the bots to keep reviewing/changing. The top half of the docs sounds like some sort of spec description system and absolutely reeks of LLM speak.
4. The rest of the docs make more sense: Under the web UI tab for "Create a Trail" I finally see what a Trail looks like (a simplified Jira ticket or GH issue) and I start actually understanding that this is an elaborate "built for AI" version of stacked PRs, CI checks, and project management.
5. The Agents and Gates subdocs are where content starts getting interesting and the documentation quality is a lot better. I am actually getting interested in this product.
I still don't fully understand what and why I would want Trails, but I suspect I'm not the target audience. There's bits of it that certainly look interesting but having to swap all my infra over to Entire is a hard sell.
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 :(
I am happy to YOLO stuff into my -dev branch unread but even for private tooling nobody else will ever use I then let things mature a little bit before extracting an explainably and clearly-scoped change to add to main. It's going to be really interesting to see how different team cultures deal with this stuff.
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.
This feels insincere coming from a venture-backed software startup. Do you have a unique ownership structure, or a particular emphasis on open-source or self-hosting?
Concretely, our CLI is OS (MIT), and we're working toward open-sourcing the storage backend EntireDB so you can self-host it on your own infra or run a variant of it. That your sessions, prompts, and review history live in your repo, not locked in our platform, means you can always walk.
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?
Not GP, but pre-LLM, who's gonna go watch that footage? Unless you're Jia Tan and there's a forensic reason to scrutinize every last little thing, who's gonna watch that video?
If there was value to be had there, you would. It's an indictment of the cited value, if you wouldn't. So are you asking me to argue my own point again? I don't think your position is adversarial to mine?
If you are arguing effort versus value, let me escalate: I don't think even the call leader of an Amazon sev one would be interested in seeing such screen recordings, when all of Amazon.com is down, and when workable solutions would be worth putting Herculean effort behind.
I want to know where the value comes from, then, just because it got easier to query such data doesn't in itself make it valuable. You would be better served by having Opus look over your code after Sonnet made mistakes, rather than having Opus first digest whatever (potentially poisonous slop) Sonnet cooked up before looking at the code.
Karthik's comments have been getting blocked. I don't agree with the screen recording because an agent session isn't just a reply of keystrokes. A session contains not just what happened, but why: the intent and reasoning from the prompts, the dead-ends, what was attempted but not shipped, and "why did we do it this way." That shouldn't disappear when a session ends.
Similarly, human review doesn't matter because humans type the code, it matters because someone still ahs to decide if something is right and if not, own the consequences.
And starting fresh with agents is pricey. Continuous memory is helpful so you can see why the last change was made, burning fewer tokens and not repeating mistakes so you don't need to relearn the codebase from scratch each time
You don’t have to give it to us. The CLI writes the session into your repo, as refs versioned alongside your commits. If you want to push that to GitHub or anywhere else, nothing stops you. The capture format is the open part on purpose.
"We founded Entire on a single belief, human developers no longer write most of the code."
This isn't a belief. What do you actually believe about the future of software?
Let me put it this way. The premise of agents is that some combination of programming languages and programming tools suck so incredibly much that humans don't want to use them.
You're effectively betting that this problem can never be fixed. AI is a layer of kludges on top of the problem of bad programming tools. Haven't you ultimately made a rather cynical bet?
Agents are such an amazing building tool, similar to how compilers and high-level languages were. It superchargers builders and that's why so much code is now being written (not always by humans.) The bottleneck was never typing, but to me, it's deciding what to build, verifying it's right, and keeping it all coherent, which is what we're rebuilding the forge around.
Most code was never the interesting part, and we’ve been handing it off for 60 years. compilers took asm, gc took memory, ides took the grep. agents are the next hand-off, not a kludge over the last one.
I dont think it’s a bet that tools cant get better either. better languages and tools make agents better too, they’re not competing. if rust-level types and a great lsp make the agent 3x more reliable, great, we still need somewhere to put the result.
The problem that never got fixed isnt the language, its that the reasoning gets thrown away between the person and the artifact. commit messages were always bad, docs always rotted, “why is this here” was always answered by whoever remembered.
Agents just made that acute, because now theres no one who remembers. thats the bit we’re trying to fix. if a better language fixes it too, honestly id take that.
Very cool. I think a focus on AI code review and continuous knowledge graph synthesis are both right directions, and any system that provides the infrastructure to automatically handle these tasks eventually must do the job of a Git Forge, even if it runs locally.
I am tackling the problem from a different direction, but I think there's a lot here to be inspired by.
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.
Hey, Haimantika here from the Entire team. Thank you for the feedback on blog, we will work on it for our future announcements.
For Trails: There’s agent sessions, gates, agents(evals basically) and checks - so it gives you all the information you need to review better (compared to the diffs for example).
Here’s our docs link too: https://docs.entire.com/guides/trails/overview
Here if you have additional questions!
Throwing out some thoughts after reading the docs page(s):
1. The "What are trails" section does not actually tell me what trails are; it tells me it brings agents and devs together, and that branches are involved somehow through "changes", but it doesn't actually tell me what they are
2. I am never going to willingly watch a Youtube video embeded in docs. I'm barely going to watch a video in a docs page at all. I'm here to learn how to use something, not see a sponsored ad for NordVPN.
3. The marketing blurb, the top half of the docs, and the bottom half ("Enable Trails" onwards) all feel like their describing different things. The marketing blurb describes a total reinvention/view of the PR layout where instead of seeing diffs you see different bars that you can balance by telling the bots to keep reviewing/changing. The top half of the docs sounds like some sort of spec description system and absolutely reeks of LLM speak.
4. The rest of the docs make more sense: Under the web UI tab for "Create a Trail" I finally see what a Trail looks like (a simplified Jira ticket or GH issue) and I start actually understanding that this is an elaborate "built for AI" version of stacked PRs, CI checks, and project management.
5. The Agents and Gates subdocs are where content starts getting interesting and the documentation quality is a lot better. I am actually getting interested in this product.
I still don't fully understand what and why I would want Trails, but I suspect I'm not the target audience. There's bits of it that certainly look interesting but having to swap all my infra over to Entire is a hard sell.
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 :(
I am happy to YOLO stuff into my -dev branch unread but even for private tooling nobody else will ever use I then let things mature a little bit before extracting an explainably and clearly-scoped change to add to main. It's going to be really interesting to see how different team cultures deal with this stuff.
Just out of curiosity: How do you review PRs/MRs? Manually? And is your company actively using AI-assisted coding?
I see nothing about pricing
I would happily try this out if it were going to be free for the next 1-2 years, or if I knew that the upcoming bill would be reasonable
Hey, you can find billing info here: https://docs.entire.com/billing
TLDR: You only get charged for Agents. We also give you a $100 signup credit.
Thanks! I wasn't able to find that in the navbar. I'll give this a real try. It looks interesting.
Amazing! Let me know if you have any questions or feedback. I go by Haimantika everywhere :)
I've been using Entire for a while now (specifically checkpoints, but also testing Trails more recently) and there's no going back! It's amazing!
I've been using entire for the last month and can't recommend it enough-- very impressed with the team behind it and hope others will give it a try.
What makes it so good compared to the other processes you've used?
thank you, Alex!
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.
> Join the rebellion
This feels insincere coming from a venture-backed software startup. Do you have a unique ownership structure, or a particular emphasis on open-source or self-hosting?
The Rebel Alliance was bankrolled by the Royal House of Alderaan. Just saying.
Concretely, our CLI is OS (MIT), and we're working toward open-sourcing the storage backend EntireDB so you can self-host it on your own infra or run a variant of it. That your sessions, prompts, and review history live in your repo, not locked in our platform, means you can always walk.
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?
Not GP, but pre-LLM, who's gonna go watch that footage? Unless you're Jia Tan and there's a forensic reason to scrutinize every last little thing, who's gonna watch that video?
If there was value to be had there, you would. It's an indictment of the cited value, if you wouldn't. So are you asking me to argue my own point again? I don't think your position is adversarial to mine?
If you are arguing effort versus value, let me escalate: I don't think even the call leader of an Amazon sev one would be interested in seeing such screen recordings, when all of Amazon.com is down, and when workable solutions would be worth putting Herculean effort behind.
I want to know where the value comes from, then, just because it got easier to query such data doesn't in itself make it valuable. You would be better served by having Opus look over your code after Sonnet made mistakes, rather than having Opus first digest whatever (potentially poisonous slop) Sonnet cooked up before looking at the code.
Karthik's comments have been getting blocked. I don't agree with the screen recording because an agent session isn't just a reply of keystrokes. A session contains not just what happened, but why: the intent and reasoning from the prompts, the dead-ends, what was attempted but not shipped, and "why did we do it this way." That shouldn't disappear when a session ends.
Similarly, human review doesn't matter because humans type the code, it matters because someone still ahs to decide if something is right and if not, own the consequences.
And starting fresh with agents is pricey. Continuous memory is helpful so you can see why the last change was made, burning fewer tokens and not repeating mistakes so you don't need to relearn the codebase from scratch each time
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?
You don’t. Everything stays with you right beside your code!
You can read more about session storage on our docs here: https://docs.entire.com/guides/checkpoints/checkpoint-storag...
You don’t have to give it to us. The CLI writes the session into your repo, as refs versioned alongside your commits. If you want to push that to GitHub or anywhere else, nothing stops you. The capture format is the open part on purpose.
[flagged]
"We founded Entire on a single belief, human developers no longer write most of the code."
This isn't a belief. What do you actually believe about the future of software?
Let me put it this way. The premise of agents is that some combination of programming languages and programming tools suck so incredibly much that humans don't want to use them.
You're effectively betting that this problem can never be fixed. AI is a layer of kludges on top of the problem of bad programming tools. Haven't you ultimately made a rather cynical bet?
Agents are such an amazing building tool, similar to how compilers and high-level languages were. It superchargers builders and that's why so much code is now being written (not always by humans.) The bottleneck was never typing, but to me, it's deciding what to build, verifying it's right, and keeping it all coherent, which is what we're rebuilding the forge around.
Most code was never the interesting part, and we’ve been handing it off for 60 years. compilers took asm, gc took memory, ides took the grep. agents are the next hand-off, not a kludge over the last one.
I dont think it’s a bet that tools cant get better either. better languages and tools make agents better too, they’re not competing. if rust-level types and a great lsp make the agent 3x more reliable, great, we still need somewhere to put the result.
The problem that never got fixed isnt the language, its that the reasoning gets thrown away between the person and the artifact. commit messages were always bad, docs always rotted, “why is this here” was always answered by whoever remembered.
Agents just made that acute, because now theres no one who remembers. thats the bit we’re trying to fix. if a better language fixes it too, honestly id take that.
[flagged]