Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- > Version Control Will Evolve for the Agent Boom
Isn't this the idea behind Yegg's "Beads"?
by erelong - > 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. [...] Humans can more easily understand and verify what was built and why, providing a provenance layer that leads to far faster review periods.
Did they understand the coming issues (reviews), but just came up with a completely wrong hypothesis (session logs)? I mentioned it in another comment some time ago, I think the biggest issue in VCS software arises from the combination of two separate ones...
These two things in combination are also part of the reason why we deem software engineers replaceable in the current hype cycle. Adding session logs to the VCS seems like treating the symptoms instead of the disease.- A (technical): Reviews are currently not part of the VCS - B (cultural): The amount of merged source code currently grants for higher authority/ownership of a code base than the review/verification of that codeby whilenot-dev - I don't see this taking off. LLM's produce absolute novels worth of verbose text; and nobody wants to read someone else's conversation with it, and certainly nobody wants to read a multi-year old session log that's 20,000 words long. Also, this is what commit messages are supposed to solve! And the only reason anyone looks at logs are to see what's going wrong, and usually a bisect is easier for finding bad commits rather than doing a deep dive into the specifics.
In the interest of not just being a hater and suggesting an alternative though: if you're implementing a feature (whether yourself or with the agent) have the agent write a spec for the feature and commit THAT. Now you have a nicely organized thing that AI's or people can consume which captures all the intent of the session log with much less noise.
by overgard - 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.
by oftenwrong - > 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.
by paulbjensen - When your AI consumes documents that are out of date it introduce bugs and incorrect behavior into the system. Code is the only source of truth that actually matters.
The only artifacts outside of code that I don't explicitly end-date are user-story style requirements documents that I periodically revisit with the AI to make sure they're up to date.
One of the most annoying things I've seen AI do is accidentally pull in old requirements and start building off of them.
by xcskier56 - 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.
by mickeyp - > 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.
I don’t think this scales. We recently have been doing “spec driven development” and we are committing the specs and prompts to our repo, alongside the generated code. At the beginning it seems fine: you wanna change something, you update the spec and ask the machine to regenerate the code. Easy. Over time, though, you have hundreds if not thousands if spec files in MD. It’s all English prose. There is duplication and subtle inconsistencies. It’s difficult to search for sections of a spec. Do you create a new file for this new requirement or update an existing one? What level of detail is enough here? Should I hint the machine about using the “saga” pattern or just let it know that we are dealing with non atomic transactions distributed across services? Etc. When a colleague opens a PR updating a spec, it’s hard to suggest objective changes (at least with code, you can demonstrate the presence of bugs… not so much with English prose. Sometimes I feel like a lawyer)
All in all, it seems as if maintenance of english prose is way worse than maintenance of actual code in big enough systems. You not only need to review the spec but also review the generated code. It’s painful
by sdevonoes