> Our hypothesis is simple: session logs are now the most important artifact in software development, and should be stored alongside the code itself in the repository.
Pi.dev has a feature where you can export the session as a html file and look at it later. I foresee that potentially you could store this in the same Git repository and get the benefit of reviewing how a particular code change came about during a session with an agent.
I guess the next step would be having the coding agent save that session context automatically in a folder in the git repository rather than requiring a human to export it.
This startup also seems to be operating in a similar space to tangled.org - moving code repos into a decentralised hosting environment.
I will make another update by the end of this week that contains what I call "brain checkpoints" that will make it easier for developers to debug and understand AI reasoning.
The idea is after a task has been finished, you would commit lessons, notes, and "brain checkpoints" that are designed to live with the code.
I suspect we'll move away from pull requests, because in the LLM world they're the worst way of accepting a contribution.
Verbose slop is painful to review, and it's dangerous to accept unreviewed code from a stranger.
For a maintainer it's way easier to tell their own agent to reimplement the same idea. It's still slop, but done their way, under their supervision.
For popular projects agent-made pull requests become a DoS attack. I wouldn't be surprised if projects start refusing to accept unsolicited PRs and switch to "don't call us, we'll call you". You could have an agent scanning forks of your projects to find what bugs users are fixing and what features they're adding, and use it as a roadmap, without the pressure of accepting any particular commit as-is.
I'd also like to move away from a binary merged-not-merged divide. Projects may have a stable manually-reviewed core that should be protected from agents messing it up, while allowing the sloppy parts to churn however LLMs like it.
> Our hypothesis is simple: session logs are now the most important artifact in software development, and should be stored alongside the code itself in the repository.
Pi.dev has a feature where you can export the session as a html file and look at it later. I foresee that potentially you could store this in the same Git repository and get the benefit of reviewing how a particular code change came about during a session with an agent.
I guess the next step would be having the coding agent save that session context automatically in a folder in the git repository rather than requiring a human to export it.
This startup also seems to be operating in a similar space to tangled.org - moving code repos into a decentralised hosting environment.
> moving code repos into a decentralised hosting environment
It's unclear to me what Entire means by decentralized. Based on their most recent blog post (https://entire.io/blog/an-entirely-new-git-hosting-network) it seems like they just mean globally distributed, but all controlled by them.
In contrast, Tangled at least offers something where you can own your own data!
This is what I am doing with my pi-brains extension for pi
https://github.com/gitsense/pi-brains
I will make another update by the end of this week that contains what I call "brain checkpoints" that will make it easier for developers to debug and understand AI reasoning.
The idea is after a task has been finished, you would commit lessons, notes, and "brain checkpoints" that are designed to live with the code.
> Version Control Will Evolve for the Agent Boom
Isn't this the idea behind Yegg's "Beads"?
I suspect we'll move away from pull requests, because in the LLM world they're the worst way of accepting a contribution.
Verbose slop is painful to review, and it's dangerous to accept unreviewed code from a stranger.
For a maintainer it's way easier to tell their own agent to reimplement the same idea. It's still slop, but done their way, under their supervision.
For popular projects agent-made pull requests become a DoS attack. I wouldn't be surprised if projects start refusing to accept unsolicited PRs and switch to "don't call us, we'll call you". You could have an agent scanning forks of your projects to find what bugs users are fixing and what features they're adding, and use it as a roadmap, without the pressure of accepting any particular commit as-is.
I'd also like to move away from a binary merged-not-merged divide. Projects may have a stable manually-reviewed core that should be protected from agents messing it up, while allowing the sloppy parts to churn however LLMs like it.
> For a maintainer it's way easier to tell their own agent to reimplement the same idea.
This only makes sense if you assume the original PR was just vibe-coded with minimal human effort. Maybe one day but I don't think we are there yet.
Provocation: pull requests were always the worst way to do it.
The security implications of scanning and merging external prompts at scale are going to be interesting.
And it costs at least twice the amount of tokens, so a full win for LLM providers.