Cursor, GitLab and Zed agree GitHub is breaking. They disagree on how to rebuild it.

Justy Okay so there's this piece going around — Cursor, GitLab, and Zed all agree GitHub is breaking, but they completely disagree on how to rebuild it. And I read it and thought, is this actually a thing or is this just three companies pitching their own product?

Cody I mean, it's both, right? Like, of course they're all positioning. But the premise — that GitHub is 'breaking' — I don't know, man. GitHub works. It's boring, it's stable, millions of people push code to it every day. What's breaking?

Justy I think the argument isn't that GitHub is down or losing data. It's that the pull request model — the whole branch, review, merge dance — assumes a certain kind of developer workflow. And that workflow might not fit how people work when they're using AI tools to generate and review code.

Cody Sure, but that's a workflow evolution, not a platform failure. GitHub has adapted before — merge queue, required reviews, code owners. They're not sitting still.

Justy Right, but the article's point is that the adaptions are all still within the PR paradigm. Cursor's approach — I think they're building more of a continuous review thing, where diffs get reviewed as they're made, not batched into a PR. GitLab's angle is different, they're pushing more automation into the pipeline itself. And Zed's building a whole new editor that treats collaboration as the default state.

Cody Hm. So the 'breaking' claim is really 'the model is showing its age under new usage patterns.' I can get behind that framing more. But I'd still push back — most teams are not using AI to generate whole features. They're using it for boilerplate, test writing, refactoring. PRs work fine for that.

Justy Classic Cody — 'my specific use case works so everything's fine.' But the teams that ARE doing heavier AI-assisted development — they're hitting friction. The article cites Cursor's internal data showing that PR review time actually increases when AI generates more code, because humans trust the code less. That's a real problem.

Cody Okay, that's interesting. So the fix isn't 'make PRs faster' — it's 'change the review model entirely.' I think that's where I get skeptical of the article's framing, because it presents these three approaches as competing alternatives, but they're really solving different slices of the problem. Cursor is optimizing for the individual developer's flow. GitLab is optimizing for the CI/CD pipeline. Zed is optimizing for real-time collaboration. Those aren't the same thing.

Justy No, but they're all responding to the same pressure — that the PR model was designed for a world where humans write all the code and review all the code. And in a world where machines write a significant chunk, the bottleneck shifts.

Cody Fine. I'll concede that the PR model has friction points that are getting worse, not better, for certain workflows. But I think the article overstates the consensus. Cursor, GitLab, and Zed agreeing that something is off doesn't mean they agree on what. And that's actually… healthy? Like, if everyone agreed on the fix, we'd get one monoculture replacement that probably sucks. Multiple attempts at the same problem from different angles is how good tools emerge.

Justy That is such an Exploring Next take. 'Fragmentation is actually good, actually.'

Cody I mean, I'm just saying — the article wants drama, three companies battling over the future of code review. But the real story is that workflow diversity is increasing, and different tools will serve different teams. That's boring as a headline but it's probably true.

Justy I think the real audience for this piece is teams that are hitting that friction but don't know how to name it. Like, you're a staff engineer at a company that's adopting AI coding tools heavily, and suddenly your PR cycle is taking longer, not shorter. Reading this might help you realize the problem isn't your team — it's the model. And the fix might be switching to a different workflow entirely.

Cody That I agree with. The article's value is diagnostic — it names a pain point that's real but not obvious. The solutions are vendor-specific, but the problem is real. I'll give it that.

Justy So where do we land? GitHub isn't breaking, but the PR model has a ceiling for AI-heavy workflows. And the variety of approaches to fixing it is actually a good sign.

Cody Yeah, I think that's fair. I'm not ready to write off the PR model entirely — it works for a lot of teams, and it will for a while. But the pressure is real, and the fact that multiple credible tools are betting on different fixes tells you something. I just don't think it's 'GitHub is dying.'

Justy Nobody said dying. Just… evolving. Anyway, I think we've officially beaten this topic into submission. Good talk.