alt Hacker NewsAgents use source control, too. It's a pretty important part of the development process to understand how code has changed.
For example, you can imagine, at the extreme, that agents could get caught in code change loops: a code change seems appropriate, it is implemented, it turns out there's some external factor which makes it not appropriate, the change is reverted, then that same code change seems appropriate again, etc.
Obviously you can prevent that from occurring with some extra infrastructure in-place, but at that point you're basically creating source control.
Replies
In theory, an agent could use git-bisect to identify when a bug was introduced. But the operator would have to be more interested in understanding the root cause than in fixing the current form of the bug...
> Agents use source control, too. It's a pretty important part of the development process to understand how code has changed.
This is a great idea, now they just have to use/do it. Maybe they can use it effectively by cloning the repo and having all the history at hand, rather than continuously scraping web pages with git content formatted for human brwosing.
> Agents use source control, too.
This is true, but at 30,000 merges a day we're talking about nearly 1 million merges a month, and purely autonomous agentic merges tend to be noisy. Is this still a tractable problem, even for an agent? Do revisions older than a few days, other than perhaps release snapshots, have any relevance for such a process?
In this sentence who would be understanding the code changes, humans?
Just have the agent rederive the revert, based on the facts of whatever made the change inappropriate.
[flagged]
I’m not advocating for no source control, but you can avoid loops like this with Architectural Decision Records. If you’re real lazy, let the agent maintain the ADRs and they will usually call out when these “painted into a corner” scenarios happen and you can then reason them around it.