Really, I think most of the hate comes from the way the self-checkout kiosks were handled and deployed. The systems themselves aren't so awful.

Hindsight is 20-20 and all that... but I think they should have only deployed them for the "12 items or less" type of express checkout. That would have helped acceptance and adoption. The people only trying to buy a few items are the ones prioritizing getting in and out quickly, even if it takes doing something differently than before.

Self-checkout gets exponentially frustrating when you have a lot of groceries like fresh foods where you can't just scan them. You've got to look them up on the touchscreen. That and purchases like alcohol where a human still has to check your ID before the process can complete.

Customers start feeling like they're doing a job that cashiers get hired for, so why aren't they getting a discount for it?

Nowhere in this do I see how maintaining the history in this manner even benefits AI. I haven't seen evidence that it can benefit from an insanely over-granular change history.

This is not debating the volume of code, it's the granularity of delivering it as tiny 'changesets'. Just because you *can* create a system that can partition changes into 3 second intervals does not mean there's any value for machine nor human in doing so.

To start, the condescension is hardly helpful.

The point stands, you have to consider the audience for the change tracking. How much granularity is really useful even for the AI models themselves to digest? Certainly no human will digest, but I also don't think the AI is going to be prioritizing putting hundreds of thousands of change history entries into the context window on the off chance that it is relevant to the task at hand.

It seems like a solution to pretend around change management while abandoning any actual use of change management, by human or machines.

Though in that scenario, it seems bad or useless for the AI as well, as the bloated change history is a waste of context window. Unless they just ignore it in which case what was the point in bothering.

But perhaps it is just another attempt to normalize "human shouldn't be in the loop" mindset, the new toy is but an excuse to say you *should* be having a codebase that is being changed every couple of seconds without bound.

I just cannot wait for that day. When people have a least a *little* less incentive for certain folks to butt in on other people's jobs and tell them how it should be done, despite never even doing nor using an AI to do said job in a serious capacity.

This story triggered a colleague to tell me that I need to stop using git, despite never having used *any* version control scheme nor even using an AI to generate code, just super armchair software development. I do not understand that mindset of people that invested in the nitty gritty of software development without the will to actually do software development.

A changeset history is only so useful compared to analysis of the code as it is. Even pretty large context windows need prioritization. I would think an overly granular changeset history would be a really low prioriity.

Compared to more aggregated changes into fewer changesets, where the history would be probably more digestable, even for AI consumption.

We can't actually know if it is 'actually quite good', because we have only their own self-assessment to go on.

No way to debate how it compares with git partial/shallow clones in broader circumstances. They don't want to share it, they just want to use the concept to fluff their image. It might be amazing, it might be trash, impossible to say anything substantial based on this.

The issue is the situation isn't binary.

Linus comes along with an attempt at nuance and suddenly all sorts of high-slop vibe coders think they are just like Linus.

I know a team that has gone very hard on slopping it up AI, though they just had a flamewar where the AI bros bitched that the more careful people were holding them back by insisting on human review and rejecting merge requests where the human didn't understand what they were submitting.

The thing is, this team was already pumping out shit code for years, so in their case the AI might actually be compelling. Infested by PHB thinking of 'hire many people in random geography, to change each year as different geographies are proven to be shit when you only pay bottom of the barrel'. They have been rotating cheap labor forever hoping for the magical geo where the cheapest people are still skilled (no such geography exists, the bottom of the barrel in any geo is trash). So AI is next on their search.

Absolutely on point. Even if you did decide the volume of code was acceptable, there's no way you need to land 30,000 commits in a day. That's less than 3 seconds per change.

If a human were pushing too many changes, I'd tell them to slow down and take a bit more time per commit. Larger commits that are more manageable instead of rapid fire tiny commits that are impossible to wrangle. If you say the AI commits are large even rapid fire, the point still stands in relative terms.

Commit histories should be there for humans to operate on. To follow the progression of changes, to bisect in case of a long delayed bug, or as the increment to trigger a deployment activity. No human can follow a commit log of 30,000, the AI doesn't need a commit log to do whatever it is doing, bisect is prohibitively slow with that many commits, you need to jump to something other than just picking out of the commit log by that time, and there's no software on earth than needs to be redployed every 3 seconds.

Slopping it up so hard that git was the bottleneck absolutely should not be the brag they think it is.

Your comment sounds like nothing more than another anti-Apple rant with no substance behind it.

Quite a bit of computer tech gets no real "second life" once the manufacturer decides it's no longer supported. It's insane to pretend this is an "Apple thing". Just going through my small pile of formerly useful e-waste, I'd point out such things as one of my old VoIP modems/routers, which was required for a residential VoIP service that's no longer in business. Looked into it to see about potentially re-flashing its firmware to "open source" it again, but came up empty.

iPads registered to users and impossible to unlock is no different than what happens with Samsung tablets, except using Google and Gmail accounts instead of Apple iCloud. If people could be trusted not to steal, this would never have become a thing. (If you can prove you were the original purchaser of a locked iPad or iPhone, there are ways to provide a copy of the sales receipt to Apple support's "unlock team" and they'll unlock the device again for you. I've had to do that before.)

Though already CI/CD pipelines were choking on the unit tests. So they aren't *free*.

Had an LLM generated request that was pretty straightforward, and the LLM generated 272 unit tests for a very simple function. Can't really afford that.

Also, despite the 272 unit tests, when I tried to try it out in the way a human would, it immediately failed. All the mocking the AI generated never actually properly imitated the real world. However, the submitter was *quite* proud of having hundreds of unit tests, despite them being, in this scenario, utterly worthless.

Like always, more code != more valuable software behavior.

So you have the AI doing overtly silly things. Someone asked to adjust layout to fix a gap in a webpage. Eventually they submitted their pull request, hundreds and hundreds of lines of CSS. Often the exact same rule repeated 5 times, which I'm guessing is how many rounds the operator went with the system before the gap actually closed. The lines were *mostly* just '!important'ing already existing rules, which had no impact, but hey, worth a shot right? Ultimately I discarded the merge request and made the one-line css tweak that was actually relevant.

Then you have the AI doing... well arguably slightly silly things. Like protecting against an invalid value redundantly throughout a call stack. Arguably defensible, as maybe one day the deep function will be called from somewhere else and passing through the error might not present it with the most informative context.

Finally the AI doing... well things the human should have been doing. With the advent of a lot of code scanning, this is less likely, but things like calling functions in C and charging ahead without ever checking the status of the call. functions that, practically speaking, will likely never fail, however you really *should* be being more defensive about the possibility.

The 'human review as a bottleneck' isn't really the angle I would fixate on. Completely unfettered AI usage also stalls out in many situations. If the AI can't get there on its own trivially, then it's going to leave an almost-correct looking mess that isn't quite there but is very hard to get across the finish line. If the AI can get it, then it's probably not 'software being shipped', because while perhaps slightly better than a generic off-the-shelf existing procedure, probably not worth the trouble to 'ship' a solution that largely overlaps with a lot of generic stuff.

Everyone knows that pretty much by definition volumes are low, that's the whole definition of a shortage.

The vendors may still be happy, perhaps even happier if the sky high prices produce at least as much revenue at high margin.

I'm with you, but realistically speaking, if the mindset is already there, the material was likely already at high risk of plausible nonsense, not as thought out as the reality, but something to satisfy a check box for someone else. And the hope for process improvement is frequently not there, as raising a "do we really need to do this" invites "you must not care about safety/security/whatever". In many scenarios *no one* wants to be potentially on the hook for approving a process optimization that ends up biting them because they didn't understand why those things were in the process. Even if it is patently obvious to all involved there's no point, or if there was it was already failing. Frequently process dictated by someone that has no *real* stakes in anything involved, but needs to be performative.

The GenAI approach is the way to pay lip service and skip the debate. And if something messes up? "Ooops, well you know how AI just does that sometimes". I've seen that *so many times* and people just laugh it off and keep slopping and no one is holding folks accountable for failing to audit the AI results adequately. So they get credit when the slop works, and they deflect blame when it doesn't.