Hacker News Reader

Comment by nater5000 | Hacker News Reader

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

View on HN

>Obviously you can prevent that from occurring with some extra infrastructure in-place, but at that point you're basically creating source control.

most of the harnesses are checkpointing most of the data of a git commit aside from the formal release and messaging, anyway; thats why they all have a similar problem with SQL dbs exploding in size after a bit of time.

Right now we're in this weird transition where most of the harness systems are layering git tool use w/ the constant snapshotting AND a memory subsystem often, probably leaves a lot on the table in saving wasted token use to just ditch the vcs all together and rely on the already persistent and existent checkpoints and memories for reconstruction.

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

Not all merges are equal, even if it's a monorepo, it's probably rare that you'd have to look at the whole codebase to implement a new feature or find the root cause of a bug. Once you start looking at the history of a specific folder, it becomes more tractable.

Of course that does require some folder structure, and agents are not necessarily great at that, but they're still decent enough that you do end up with many folders not being impacted hour or even daily.

I am not sure that I can agree with this at this scale, especially for the hotspots in the code. But I admit that I am speculating here.

That won't last. I see that as a disaster waiting to happen. There is absolutely no way they have control over what gets produced at that rate.

> There is absolutely no way they have control over what gets produced at that rate.

I'd wage that volume of changes is not leading to forward progress, but is a clear sign of code churn.

This in turn is a clear tell they are dealing with spaghetti code.

> spaghetti code wow, that's a term i haven't heard in a minute. almost makes me nostalgic for all the human-made slop we had to deal with

At least spaghetti code had one saving grace: whoever wrote it could only make so much of it before they gave up.

I imagine there's a lot more to this then just throwing agents in basic harnesses at huge repos with only git tools (I mean, that's what this article is about).

At the end of the day it's "just" a management problem. If you can do something like, say, distill development activity into a hierarchical summary (i.e., this merge does "this," and these collection of merges do "these" things based on the "this" that each is described to do, etc.), then, with enough agents operating in parallel, I don't see why managing that isn't at least theoretically possible.

In practice this seems like a mess, but they're the ones with intelligence on tap lol

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

> the operator would have to be more interested in understanding the root cause than in fixing the current form of the bug...

Can you even do the latter without the former?

You can "fix" it (make the current reproducer not reproduce it anymore).

I see it all the time, it is fixing the symptoms usually. It kind of works until it doesn’t and it fails miserably.

So yes you can and it works, sometimes…

For me, Claude regularly looks at git blame after identifying a bug, then reads the commit message and other changes in the commit to understand the context of why that behavior was introduced like that. I wouldn't be surprised if it pulled out a git bisect

Then again, my standard instruction is something like "{bug description}. Find the root cause and propose possible solutions" so I guess I fit your profile

Same, I basically take the derivative of a bug wrt every major dimension before I fix it.

not really an option when you're working on a large codebase where a bisect means that a lot of steps could be multiple-hours of compiles. E.g if on a simple 12-step bisect you get 6/8 with a full rebuild you've already spent an entire work day on this

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.

Right. But how to prevent adversarial agents working on the same code base from treating the ADR list as a form of malicious message exchange?

Don’t let adversarial agents work on your code?? What is protecting an ADR against adversarial agents going to solve if they can just embed a highly advanced, obfuscated ‘rm -rf windows32’ anyway

Why give an adversarial agent write access to your code

> Hmm, I have destroyed the file again, that's odd. Let me rebuild it from a half recollection of what it was supposed to do based on my compacted context.

It's the right approach if your business is selling tokens and the customer doesn't know any better.

You're absolutely right, this mistake is unacceptable. I take full responsibility for this.

You still commit the ADRs and keep backups. Adding agents to the loop doesn't free you from the basic responsibilities of developing software.

Anthropic can just replace pesky source control with a much better source guardrails. Aren't they all the rage and next step evolution in the computer security? Just ask Claud "pretty please do version control" and that should be enough, right?:)

You absolutely know there is one of those AI bros out there in social media posting on how they feel euphoric because their agents don't speak git anymore and just pass a zip with the source code around to other agents as handoffs.

> Obviously you can prevent that from occurring with some extra infrastructure in-place, but at that point you're basically creating source control.

Or code comments which they are already doing a lot of. I used to get annoyed by their verbose comments but at this point I've seen them help a few times and it's not like I'm actually maintaining the code myself anymore so it doesn't really bother me

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

You're referring to a completely separate system that, for all we know, might not even be run by AI companies.

With the way they are shipping code, source control history has no practical value. If barely any code older than 5 days still exists in the codebase, and nobody reads the commit logs, you can throw out most things in a source control system. It is basically a database of latest version of code, that's about it.

In this sentence who would be understanding the code changes, humans?

And which is understanding the code changes meant for?

The agents obviously.. I thought that was obvious.

That's not super reassuring, until I know they can read, remember, and reference reliably at suitable complexity.

Just have the agent rederive the revert, based on the facts of whatever made the change inappropriate.

Reply on news.ycombinator.com