Yeah, I'm just a little tired of seeing these pull requests of multi-thousand-line pull requests where no one has actually looked at the code.

The solution people are coming up with now is using AI for code reviews and I have to ask "why involve Git at all then?". If AI is writing the code, testing the code, reviewing the code, and merging the code, then it seems to me that we can just remove these steps and simply PR the prompts themselves.

▲

zephen 7 hours ago | parent | next [-]

> why involve Git at all then?

I made a similar point 3 weeks ago. It wasn't very well received.

https://news.ycombinator.com/item?id=47411693

You don't actually need source control to be able to roll back to any particular version that was in use. A series of tarballs will let you do that.

The entire purpose of source control is to let you reason about change sets to help you make decisions about the direction that development (including bug fixes) will take.

If people are still using git but not really using it, are they doing so simply to take advantage of free resources such as github and test runners, or are they still using it because they don't want to admit to themselves that they've completely lost control?

	▲	8note 4 hours ago \| parent \| next [-]
		> If people are still using git but not really using it, are they doing so simply to take advantage of free resources such as github and test runners, does it have to be free to be useful? the CD part is is even more important than before, and if they still use git as their input, and everyone including the LLM is already familiar with git, whats the need to get rid of it? there's value in git as a tool everyone knows the basics of, and as a common interface of communicating code to different systems. passing tarballs around requires defining a bunch of new interfaces for those tarballs which adds a cost to every integration that you'd otherwise get for about free if you used git
	▲	tombert 7 hours ago \| parent \| prev \| next [-]
		> are they still using it because they don't want to admit to themselves that they've completely lost control? I think this is the case, or at least close. I think a lot of people are still convincing themselves that they are the ones "writing" it because they're the ones putting their names on the pull request. It reminds me of a lot of early Java, where it would make you feel like you were being very productive because everything that would take you eight lines in any other language would take thirty lines across three files to do in Java. Even though you didn't really "do" anything (and indeed Netbeans or IntelliJ or Eclipse was likely generating a lot of that bootstrapping code anyway), people would act like they were doing a lot of work because of a high number of lines of code. Java is considerably less terrible now, to a point where I actually sort of begrudgingly like writing it, but early Java (IMO before Java 21 and especially before 11) was very bad about unnecessary verbosity.
	▲	codebje 2 hours ago \| parent \| prev \| next [-]
		A series of tarballs is version control. Git gives you the series of past snapshots if that's all you want it for, but in infrastructure you don't need to re-invent.
	▲	fragmede 6 hours ago \| parent \| prev [-]
		A series of tarballs is really unwieldy for that though. Even if you don't want to use git, and even if the LLM is doing everything, having discrete pieces like "added GitHub oauth to login" and "added profile picture to account page" as different commits is still valuable for when you have to ask the LLM "hey about the profile picture on the account page".

▲

alephnerd 7 hours ago | parent | prev [-]

Yep.

Also, the approach you described is what a number of AI for Code Review products are using under-the-hood, but human-in-the-loop is still recognized as critical.

It's the same way how written design docs and comments are significantly more valuable than uncommented and undocumented source.