I think a Q&A-based approach is could also be a suitable way to capture the reasoning behind a project. Instead of writing documentation afterward, an AI could interview the developer throughout the process and preserve the questions and answers as project context.
I find the value of someone steering an AI session to be practically nil for nearly everything. Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists.
So I'm not sure why people going "chop, chop" and "nah make it more red and bigger" is a useful signal of much of anything.
No, the future is a complex "gate" that checks, weighs and measures everything before it gets committed --- a local (or remote) "CI" but... more granular and far more specific and turned to the needs of the project you work on.
> Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists.
I think the issue that many may not want to think about is, how do we promote/reward/fire developers in the AI assisted programming age. As part of code reviews, I think it will be second nature to ask "how did you arrive at the code".
Hi! I work at Entire. We actually have another feature that we announced called Trails which indicates Confidence, Risk, Drift of code changes to give the maintainer more confidence that the code is high quality.
Each of those signals -- confidence, risk, drift are determined by a workflow file that the maintainer can create.
And trails continuously evaluate every time a change is made.
So that's exactly what we're doing..a gate that checks and weighs and measure everything before it gets committed.
The point of us capturing the agent sessions is so we can do more things with it..like adding "gates" that verify quality!
Who would trust the classifiers, though? I would not.
A team of professionals will trust a gateway they built themselves -- by an AI, most likely, as that is boring work -- that works for their organisation and whatever weird quirks and house styles they have. In a year or two when things are a bit more stabilised that'll be dozens of subagents each testing a little thing each in isolation plus a bevvy of software that looks for antipatterns in addition to running tests and linters and what have you. It'll be tested against the ground truth specification and not the boring crap in the middle.
At no point will anybody's session matter. Results count; nothing more.
> 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.
entire cli maintainer here: the entire cli does exactly this, with support for agent native clis but also pi or opencode. We take the raw session logs, put it in the repo with a stable link to the commit, and then you can render it in the cli or see it in on entire.io.
This model has some significant downsides for humans, but less so for automatons. It eliminates some major problems of software development like merge conflicts, dependency hell, etc.
Has anyone tried teaching the agents to use jj or gitbutler-cli to do their ideas of lightweight branches? I keep feeling like that would be a huge win for the multi-branch development I'm doing much more of with agents, but I haven't yet run that experiment.
The basic idea is, you always ensure you inject the instructions for how to use jj or any other scm. LLMs are pattern matchers and they can fully map behaviour, but due to heavy training on git, they can forget.
With hooks, you can easy detect when 'git' is used and basically tell the agent "As stated earlier you must use jj". So it will try again using `jj` and you block the agent when ever it tries to use git.
It is a wasted turn but the reality is, it won't cost must since you can leverage caching and you only waste tokens on the invalid command and not the output generated from git.
That is more along the lines of put all the agent communication into a DB that has git’s immutable history. They still use git for the code, and beads (well, DoltDB for storage/versioning) for the tasks and a bit of non-associative memory.
On the topic, I don’t find too much of the prompting to be worth referring to later, but I do always vibe code a search the sessions local web server so I can find things later. The harnesses seem to be getting better at this, but I make a ton of directories for different branches so I can’t always remember if a session was in de512.main or de1024.main
I have had luck with telling an agent to search thru old sessions to write up how to docs or sketch out a python script to automate something having done it a few times.
> Anyone else finds the LLMs version control discipline lacking?
No? How do you define discipline? Claude code knows how to read and write commits. My team just granted it limited force push access a week ago. We’ve taught it to make more human-friendly commit messages.
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.
I think a Q&A-based approach is could also be a suitable way to capture the reasoning behind a project. Instead of writing documentation afterward, an AI could interview the developer throughout the process and preserve the questions and answers as project context.
Matt Pocock’s “grill-me” skill is a nice example of this idea: https://github.com/mattpocock/skills/tree/main/skills/produc...
I find the value of someone steering an AI session to be practically nil for nearly everything. Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists.
So I'm not sure why people going "chop, chop" and "nah make it more red and bigger" is a useful signal of much of anything.
No, the future is a complex "gate" that checks, weighs and measures everything before it gets committed --- a local (or remote) "CI" but... more granular and far more specific and turned to the needs of the project you work on.
> Nobody wonders out loud how a senior developer arrives at the result he does without an AI; they care that his deliverable is high quality and meets whatever standard/requirement exists.
I think the issue that many may not want to think about is, how do we promote/reward/fire developers in the AI assisted programming age. As part of code reviews, I think it will be second nature to ask "how did you arrive at the code".
Hi! I work at Entire. We actually have another feature that we announced called Trails which indicates Confidence, Risk, Drift of code changes to give the maintainer more confidence that the code is high quality.
Each of those signals -- confidence, risk, drift are determined by a workflow file that the maintainer can create.
And trails continuously evaluate every time a change is made.
So that's exactly what we're doing..a gate that checks and weighs and measure everything before it gets committed.
The point of us capturing the agent sessions is so we can do more things with it..like adding "gates" that verify quality!
Who would trust the classifiers, though? I would not.
A team of professionals will trust a gateway they built themselves -- by an AI, most likely, as that is boring work -- that works for their organisation and whatever weird quirks and house styles they have. In a year or two when things are a bit more stabilised that'll be dozens of subagents each testing a little thing each in isolation plus a bevvy of software that looks for antipatterns in addition to running tests and linters and what have you. It'll be tested against the ground truth specification and not the boring crap in the middle.
At no point will anybody's session matter. Results count; nothing more.
> 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.
entire cli maintainer here: the entire cli does exactly this, with support for agent native clis but also pi or opencode. We take the raw session logs, put it in the repo with a stable link to the commit, and then you can render it in the cli or see it in on entire.io.
There’s reason I wrote high info density documentation and comments rather than committed every StackOverflow page I viewed during development pre-AI.
I am anticipating a move away from git-style version control entirely.
One possible shape is something like unison-lang's CAS AST model:
https://www.unison-lang.org/docs/the-big-idea/
This model has some significant downsides for humans, but less so for automatons. It eliminates some major problems of software development like merge conflicts, dependency hell, etc.
Has anyone tried teaching the agents to use jj or gitbutler-cli to do their ideas of lightweight branches? I keep feeling like that would be a huge win for the multi-branch development I'm doing much more of with agents, but I haven't yet run that experiment.
> Has anyone tried teaching the agents to use jj or gitbutler-cli to do their ideas of lightweight branches?
This is very trivial if your coding agents supports hooks like Pi. I have demo repo that goes over how rules work at https://github.com/gitsense/gsc-rules-demos
The basic idea is, you always ensure you inject the instructions for how to use jj or any other scm. LLMs are pattern matchers and they can fully map behaviour, but due to heavy training on git, they can forget.
With hooks, you can easy detect when 'git' is used and basically tell the agent "As stated earlier you must use jj". So it will try again using `jj` and you block the agent when ever it tries to use git.
It is a wasted turn but the reality is, it won't cost must since you can leverage caching and you only waste tokens on the invalid command and not the output generated from git.
> Version Control Will Evolve for the Agent Boom
Isn't this the idea behind Yegg's "Beads"?
That is more along the lines of put all the agent communication into a DB that has git’s immutable history. They still use git for the code, and beads (well, DoltDB for storage/versioning) for the tasks and a bit of non-associative memory.
On the topic, I don’t find too much of the prompting to be worth referring to later, but I do always vibe code a search the sessions local web server so I can find things later. The harnesses seem to be getting better at this, but I make a ton of directories for different branches so I can’t always remember if a session was in de512.main or de1024.main
I have had luck with telling an agent to search thru old sessions to write up how to docs or sketch out a python script to automate something having done it a few times.
We need to store CHOICES with the commit or branch. Not the whole session. Conscious, summarized choices
Anyone else finds the LLMs version control discipline lacking?
The engineering practices in general are lacking. Not tests nor assumptions validation ever, unless explicitly asked.
> Anyone else finds the LLMs version control discipline lacking?
No? How do you define discipline? Claude code knows how to read and write commits. My team just granted it limited force push access a week ago. We’ve taught it to make more human-friendly commit messages.
What’s missing?
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.
Take a look at his keynote at WeAreDevelopers..he starts around the 17:20 mark
https://www.youtube.com/watch?v=eSoHzgrhk6Q
He does hint around removing away from pull requests!
> 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.
The security implications of scanning and merging external prompts at scale are going to be interesting.
Provocation: pull requests were always the worst way to do it.
And it costs at least twice the amount of tokens, so a full win for LLM providers.
Followup announcement post:
An Entirely New Git Hosting Network
https://entire.io/blog/an-entirely-new-git-hosting-network
(https://news.ycombinator.com/item?id=48833019)