Hacker News new | ask | show | jobs
by csbrooks 4 days ago
> commits were on pace to hit 14 billion in 2026, up from 1 billion in 2025

So AI means 14x the checkins? That's not 14x features completed, but still... wow.

6 comments

AI has 100x'd our productive capacity such that we're moving at unforeseen speeds at digging holes and refilling them!
This is too generous, they aren't even filling in the holes.
It’s filling in a lot of the holes, but it’s putting a very convincing paper cover over the ones it misses. So it’s very hard to find the ones it didn’t fill, better hope your most valuable customers don’t walk over the paper ones!
I am surprised it is that low. The Bun Zig-to-Rust AI port was 6755 commits in like two weeks. If you make 10 commits per working day, that is 2500/year.

While that is (hopefully) the upper end of the distribution, several companies have loudly encouraged engineers to light tokens on fire to the AI gods, so it only takes a handful of the devout to push up the average in gas town like ventures.

Is that even a lot?

Spread over a year, roughly estimating a generous 4 kbytes of data per commit, comes out to a throughput of a little under 2 MB/s.

Of course, it isn’t spread out uniformly and there is also a lot of hashing and other things going on.

Maybe pulls and clones drive more I/O ?

I suspect there is a cacophony of work that happens when a commit hits the server. That request needs to get replicated, git repositories need to be repacked, pull requests need to calculate diffs, CI jobs need to execute, on and on.

That's also just assuming the good-faith usage. There are probably plenty of adversarial and poorly behaved scrapers that are putting additional load on the system.

Recalculate percentage of each language in the repo, recalculate top contributors, recalculate the stats for the committer's profile etc etc.
Scalable algorithms and data structures have existed for decades.

Even if they had 10 billion users with 10 billion repositories it shouldn’t be a big deal on a home PC.

With agentic stuff there's also a large amount of commits which are not code.

For instance with OpenClaw and similar, they often simulate institutional and short term memory with markdown files in folders. Other tooling that runs companies using agents as staff, for example, do the same - but also with files for inputs, outcomes, handovers etc.

All of this means a lot of extra churn as these kinds of files can be changing with every interaction not just every traditional commit point.

That commit count alone should not become any problem for infrastructure, even for Azure. They probably developed some ungodly mess with actions that did not/could not translate very well on Azure infrastructure.
Seems very reasonable, from my use. I commit much more often, as checkpoints, with branch rules that prevent force pushes/deletions, so the agents can't delete anything. And, suspect MS is only counting commits, and not the eventual squashes to one commit.
And every checking runs a whole CI run?

We had it internally with our teams that open a PR to then push like 10-20 more commits but never actually interested in the client builds etc. turned out they opened the PR as a checkmark/ way to share the current state. We set cooldowns and auto cancel for the ci. And then there is the developer who uses the CI compute to run tests instead of running them locally for various reasons. We had to remind that compute isn’t for free.

Nope. You can configure CI to not run for every commit of every branch (seems insane to have full CI for every commit, unless you don't allow your devs to push until done with something, which also seems insane).