I feel the opposite way, that git branching and merging will become a bigger part of the job as more code is written by agents in parallel and then accepted by other agents or humans.

for now yes absolutely. but I’m already hearing rumblings that some people are having luck letting multiple agents edit the same directory simultaneously instead of putting changes through PR merge hell. It just needs coordinations tools, see https://github.com/Dicklesworthstone/mcp_agent_mail as one (possibly insane) prototype

for example it’s not out of the question that we could end up with tooling that does truly continuous testing and integration, automatically finding known-good deployments among a continuously edited multiplayer codebase

we’d have to spend a lot more energy on specifications and acceptance testing, rather than review, but I think that’s inevitable - code review can’t keep up with how fast code gets written now

Having tried a janky version of this myself with a NOTES directory, I am very bearish on this being a better workflow than just improving the ui wrapper around git worktrees and the isolation that provides.

Codex already has a fantastic review mode, and gemini / claude are building tools around pr review that work no matter how that pr was produced, so I think this interface is going to get baked in to how agents work in the near term.

That’s a very optimistic outlook for the future.

Often projects need a history of stable checkpoints, and source control is one way to provide that.

Yes, but does it need all the ceremony surrounding it? If, every time I saved the file, the changes were analyzed and committed to git, and a useful commit message included, and commits squashed automatically and pushed and tested and tagged (using magic, let's say); if the system existed in the background, seamlessly, how would our interactions with source control and with other developers look?

> if the system existed in the background, seamlessly, how would our interactions with source control and with other developers look?

They would look like noise.

You would be the source of that noise.

One commit per edit? Nonsense.

Me and any other developer would hate to share a repository with you.

ye gods, have you never heard the word squash?

Why should I do your work instead of mine?

Even your comment is also noise =)

Who's asking you to do my work instead of yours in this hypothetical magic future system that I've invented in my head?

automated commit message will tell you the "what" not the "why".

In any circle of "what makes a good commit message and why even do it" discussions, invariably the recommendation is to explain the "why" and leave out the self-evident "what".

If your stance is that commit and commit messages can be automated away then we might as well not even have them.

I don't share this view, but yeah in this world we don't need AI to do things that shouldn't be done in the first place.

> we might as well not even have them.

You can't see any value in being able to see the "what" in a short bit of English at a glance vs having to analyze a 300+ line diff to figure out what it's doing?

increasingly, the automated systems have access to the original ticket or bug report, and maybe even the conversation while implementation is happening. They can record the “why”

Use jujutsu

Counter argument to living software is that it treats "never done" products as a virtue instead of a failure of design.

Here's a thread where the person replying to me makes this case: https://news.ycombinator.com/item?id=45455963

I love it when I have a tool that’s “done” but the software I work on in my career is never, ever done. It’s almost like there’s two different things we call “software”. there are tools like, idk, “curl” where you can use and old version and be happy. and there are interactive organizations in the world, like, eg, Hacker News, which mutates as the community’s needs change

Software for evolving business-needs is the same for me. What's insightful is that we (I) take continuously evolving software as just that: evolving. It's a defacto virtue to continuously tinker.

Doing away with check-ins entirely is the extreme end-game of that pov. I'm in product and every day and every week yes we very much continually change the product!

But I'm growing less convinced that the natural end-state of this methodology produces obviously better results.

Ohh no, you should be able to decide which changes to commit, line by line, before committing them.

What you describe sounds like a security nightmare to me.

Maybe you are using a remote dev server, and every change you do needs to be committed before you see the result?

Please setup a local environment instead. Not even F5 should be required, you save a file, you see the result in the browser.

When your work is finished, and only then, you should commit your changes.

it doesn't work quite well for complex projects that require integration with other teams/software.

You would need to either have separate versions running at the same time or never do breaking changes or devise some other approach that makes it possible.

It's not always feasible to do it this way

I think that’s a tooling problem. Maybe we do end up running a lot more versions of things in the future. If we believe that code has gotten cheaper, it should be easier to do so.

I wonder how many nines of uptime your team is required to have..

Imagine if someone clicks the deploy button when you're in the middle of typing something and then the service goes down due to a syntax error. To prevent this, we will need some sort of way to set a global lock to indicate that "I'm not done typing yet" and you can only deploy once everyone has released this lock.

Or you don't deploy unless it makes it through at least testing, and a build started while someone was editing the code would probably fail fast unless you coincidentally hit the button right when it's valid, but wrong, code.