Hacker News Reader

Comment by nikolay | Hacker News Reader

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 GitHub won't make much of a difference. GitHub is not just source control; everybody can set up Gitolite and have an amazingly configurable and secure Git setup. I did this 10 years ago, and CODEOWNERS, protected branches, and tags can't do 1% of what I had done before. Cursor is going all over the place as it can't compete with their model. So, this is a defeat, a pivot, not something glorious!

View on HN

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.

I use Claude with the Codex plugin as a critic (sometimes I switch and manually review with Claude). With the Superpowers skill (which I am trying to get rid of), it designs expensive models and implementations, uses cheaper ones for other, less important stuff, including Haiku, sometimes upgrading if it hits a roadblock, and then, finally, reviews with expensive ones. Why would I need Composer unless I'm a poor hobbyist? I care about value created, not about the affordable costs. So far, Claude and Codex have given me a huge ROI and are worth every penny. I don't even use an IDE, although I pay for Zed, or the terminal anymore - Claude and ChatGPT desktop apps give me everything and keep things simple. I just watched Theo yesterday [0], and I realized I'm not alone.

[0]: https://www.youtube.com/watch?v=dLhcLqoff6k

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.

> It can't be any worse than current github

Yeah, and the grass is always greener somewhere else.

The only way to finally end up in a happy state about your git hosting and automated workflows running, is by running the whole shebang yourself. Saves you so much sanity in the long-term, even if starting and scaling is slower.

Oh, I told my son to create an org yesterday with Cursor Origin, just in case in 10 years it becomes a thing, and he said: "Oops! Paid customers only!" A GitHub "alternative," really? Well, this is reminding me to cancel my Cursor subscription. I am paying for it but not using it because I don't need it as it offers me nothing. I won't even say that somebody already got my GitHub org name, so I'm sure there will be an aftermarket for org usernames and people who want to get 10-15-20x of their $20 investment. Cursor's shortsighted decision is definitely welcomed by parasites! They rushed out their MVP so badly that they created an identity fiasco!

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!

Maybe what we need is actually fewer ecosystems, and more products.

People are lazy, and when there are no standards (or when they are not followed strictly), it's no small challenge to build a generic interface that works with multiple providers transparently and interchangeably. Many moons ago, we built an LOS (Loan Origination System) for subprime mortgage companies, and I designed a service that standardized input and output for dozens of mortgage vendors - credit, title - you name it. Every vendor was adding their flavor to the standards; everybody read the standards wrongly to some extent, etc. So, when we were pitching the LOS to a bunch of lenders, many of them came back to us and asked, "Can we just buy your servicing subsystem from you?" although it wasn't a separate product at the time. So, naturally, software engineers don't like one-offs unless they support one of the vendors only (pun intended) - the GOAT. It's not so easy to create or extend a standard that works across all vendor implementations. So, it's human nature to try to avoid this process and just support GitHub. The bigger the mass, the stronger the gravity. The biggest mass has the strongest gravity.

Reply on news.ycombinator.com