Live data from Hacker News

How version control will evolve for the agent boom

entire.io

41–50 of 72 posts

Re: How version control will evolve for the agent boom

#41
post #24

Earlier quoted context omitted.

> 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 co…

Can’t wait to get in trouble for having curse words in my chat with AI get flagged by the company’s anti-swearing-in-code automation.

I think it makes no sense to share the conversation but I do think developers will be required to provide lessons, notes and checkpoints in the conversation.

What I think will happen is you will be required to run the conversation through a company required prompt that will include things like, does the conversation contain "think harder" without providing any guidance for how to correct things.

Basically, did the developer treat the conversation like a literal slot machine.

Re: How version control will evolve for the agent boom

#42
> 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

Re: How version control will evolve for the agent boom

#43

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…

> One of the most annoying things I've seen AI do is accidentally pull in old requirements and start building off of them.

This is actually the reason for me wanting to create what I call "Brain checkpoints". After chatting with the agent and letting it do its thing for discovery, I needed an easy way to understand what it knows at any given point. What files it has read, what tool calls were made and so forth.

Checkpoints work extremely well in Pi since you can create a branch, and have the agent generate a checkpoint based on what has changed since the last checkpoint and this information will not pollute the main conversation but you benefit from the token caching.

Re: How version control will evolve for the agent boom

#44
> But as code becomes increasingly abundant through agents, the context behind "why" the code was written is becoming vital:

That’s the commit message. If something is not immediately clear from the title and the diff, you write it it in the commit description, like this:

https://cgit.freebsd.org/src/commit/?id=ed7e0ebfa20e7e798d2e...

If you can’t summarize your changes in a similar manner, that usually means you don’t understand the code and shouldn’t push it to other people.

Re: How version control will evolve for the agent boom

#45

> 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…

Exactly. The spec should go in a git comment, NOT vcs. Or, you keep the document in history for the duration of the PR and remove it post review or pre merge

Re: How version control will evolve for the agent boom

#46
post #24
post #14

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 futur…

> 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 co…

> I think it will be second nature to ask "how did you arrive at the code".

What about “Do you understand the code well enough to argue about it, its past, and possible evolution paths”?

Re: How version control will evolve for the agent boom

#47
> 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...

  - 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 code
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.

Re: How version control will evolve for the agent boom

#48
post #24

Earlier quoted context omitted.

> 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 co…

> I think it will be second nature to ask "how did you arrive at the code". What about “Do you understand the code well enough to argue about it, its past, and possible evolution paths”?

I think that would be implied by "how did you arrive at the code". I think the conversation will revove around how did you "guide" things.

Re: How version control will evolve for the agent boom

#50
post #45

> 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…

Exactly. The spec should go in a git comment, NOT vcs. Or, you keep the document in history for the duration of the PR and remove it post review or pre merge

Disagree completely. The spec is vital so that future changes continue to conform to it. Specs absolutely need to live in the VCS, because they continue to be needed to keep the code conformant. They essentially are a form of code now. And code goes in the VCS.
Post reply on HN