There's nothing Cursor can do that GitHub/Microsoft can't in 2026... And vice versa... after several years of Cursor vibecoding a GitHub clone while catching up with GitHub's new features. Git's performance it's not the issue; it's GitHub Actions, PRs, etc. The moment Cursors steals paid GitHub customers and gets the same workloads, they will start having similar issues! Stealing engineers who couldn't fix this at Gi…
I'd argue that for whatever other faults they have, Composer 2.5 is pretty competitive as an implement-planned-work model. It's several times faster than Sonnet 5, cheaper, and performance is comparable. Ears wide open for a model that does better for the same parameters. Pareto efficiency is important, but Anthropic doesn't seem to care about it. They desperately need a Haiku 5, IMO.
Git at any scale
91–100 of 128 posts
Re: Git at any scale
#92A few scaling trends, all triggered by coding agents, make it unsustainable to keep stacking agents on the interfaces designed for human uses — Git, PRs, CI, review:
1. Time to produce a given feature dropped by orders of magnitude. Review, CI, and branch workflows were calibrated to human writing speed. The gates did not get faster.
2. Users will not consume 100x more features. They expect 100x more value from each interaction. The interesting artifact is no longer “the code that implements a feature.” It’s the mapping from intent to outcome.
3. Intermediate work exploded while durable output shrank. Agents leave scratch repos, traces, failed attempts, discarded implementations. The thing the user actually wanted got smaller and more valuable — closer to “satisfy this intent” than “ship this feature.” That is a lure to build much more complex software, and we are versioning the scrap heap with the same tool we use for the product.
4. The primary goal of software engineering till today is to share actions between users, so their intent are served through the same routines. Such software only satisfy commonality. It's now possible to build based on peculiarity. With that, a whole new space of personalization.
This looks like the history of machine tools: first powerful and imprecise, then more powerful and enormously precise. Software has to make the same jump — much more useful, and much more personalized.
I don’t know what the end state looks like. I doubt Git should remain the central mechanism.
Edit: Revised with help of AI.
Re: Git at any scale
#93There's nothing Cursor can do that GitHub/Microsoft can't in 2026... And vice versa... after several years of Cursor vibecoding a GitHub clone while catching up with GitHub's new features. Git's performance it's not the issue; it's GitHub Actions, PRs, etc. The moment Cursors steals paid GitHub customers and gets the same workloads, they will start having similar issues! Stealing engineers who couldn't fix this at Gi…
Perhaps you didn't read the article, but the implementation they describe is interesting and perhaps easier implemented in a new project from scratch. It can't be any worse than current github, and since we've heard plenty of people express their dissatisfaction with github recently, this is actually a good direction for Cursor. A product people may want. We'll see.
Re: Git at any scale
#94Any ideas how these interactive animated diagrams were made?
Re: Git at any scale
#95I don't care about what they say because of who they sold out to
Re: Git at any scale
#96Earlier quoted context omitted.
Perhaps you didn't read the article, but the implementation they describe is interesting and perhaps easier implemented in a new project from scratch. It can't be any worse than current github, and since we've heard plenty of people express their dissatisfaction with github recently, this is actually a good direction for Cursor. A product people may want. We'll see.
I am just too old, you know. I remember Bitbucket, GitLab, and the plethora of other GitHub killers. GitHub is an ecosystem, not a product. Cursor needs at least a decade to beat that! Maybe more!
Re: Git at any scale
#97Earlier quoted context omitted.
Just like with climate change, the problems Elon creates don’t go away just because people are reminded of them. He still pushes his agenda, he still has lots of followers who believe his nonsense
[flagged]
Re: Git at any scale
#98> The "fan-out" is synchronized with a classic consensus algorithm called 3PC (three-phase commit) so that a push is only accepted if a majority of the nodes acknowledge it. Doesn't 3PC require all nodes to agree, not just a majority?
I would think so - outside this sentence the author indicates they're talking about consensus across all members. IE - the interactive diagram and note about latency being bounded by the slowest replica
Ah, and then it looks like the losing nodes get marked unhealthy:
> In essence, every write operation goes through a voting protocol, and any replicas on the losing side of the vote are marked as unhealthy—unavailable for reads or writes—until they can be repaired. Repairs are automatic and quick. Because a majority agreed either to accept or to roll back the update, there are still at least two replicas available to continue accepting both reads and writes while the unhealthy replica is repaired.
But not sure how unhealthy nodes are discovered. Maybe the coordinator marks them, and if the coordinator crashes it allows stale reads and detects invalid writes?
Re: Git at any scale
#99Re: Git at any scale
#100> What about consensus? Elections? Which server is the primary for a given repository? It also doesn't matter! There's no state and no consensus here. Any server can be the primary. All updates to the write-ahead log are synchronized with an atomic compare-and-swap (CAS) operation on S3, so it's always safe for any instance of a repository to receive a push. Again reminded of what an amaizing piece of engineering S3…