How should the developer platform evolve beyond GitHub's model?

An article in The New Stack frames a quiet debate between three major developer tool companies. All agree GitHub is showing its age; they diverge sharply on what should replace it.

Where it happened

A June 2026 article from The New Stack synthesizes the strategic positions of three developer tool companies: Cursor, GitLab, and Zed. While not a direct, threaded conversation, the piece frames a fundamental disagreement about the future of software development workflows, using GitHub's perceived stagnation as a common starting point. The debate is not about whether GitHub is dominant, but about which layer of its stack is most vulnerable to disruption.

The AI-Native Overlay (Cursor)

Cursor's position, as framed in the article, is that the core of GitHub (git repositories, pull requests, social coding) is sound, but the developer experience built on top is obsolete. Their approach is to treat the existing ecosystem as a foundation and build a superior, AI-native interface over it. The argument is that the next leap in productivity will come from deeply integrating large language models into the editor and coding workflow, automating tasks from code generation to debugging. This strategy accepts GitHub's network effect as a given and focuses on capturing the user-facing layer, effectively turning the incumbent into a backend.

The Integrated Platform (GitLab)

GitLab offers a contrasting vision. For years, its proposition has been to replace the fragmented toolchain that often surrounds a GitHub repository. Their argument is that the primary source of friction is not the editor experience alone, but the entire software delivery lifecycle. By integrating issue tracking, CI/CD, security scanning, and package registries into a single application, GitLab claims to offer a more streamlined and efficient workflow. Their solution is not an overlay, but a wholesale platform replacement. The underlying problem, from this perspective, is toolchain complexity, which neither a better editor nor AI alone can solve.

The Performance-First Editor (Zed)

Zed represents a third path, focusing on a more fundamental layer of the developer experience: the speed and responsiveness of the core tools. Their argument is that before advanced features like AI or full-lifecycle integration can be truly effective, the editor itself must be exceptionally fast and built for real-time collaboration. This position suggests that the primary bottleneck is cognitive load and flow state interruption caused by slow, cumbersome tools. For Zed's proponents, the foundation of any next-generation platform is a high-performance core that makes the act of coding itself seamless. Everything else is a secondary concern.

What's underneath

All three companies are implicitly betting that git itself is the permanent, commoditized protocol for source control. None are trying to replace it. The debate is a competition to own the value-capture layer built on top of that free and open foundation. Each company's strategy reveals a different bet on where the most valuable friction lies in modern software development: in the human-to-code interface (Cursor's AI), in the team-to-deployment process (GitLab's platform), or in the raw speed of the developer's primary tool (Zed's editor). The consensus that GitHub is "breaking" is really a consensus that its user-facing monopoly is now contestable.

The investor read

This debate signals that GitHub's moat, while wide, is not unassailable. The competition is not attacking the core repository hosting (a low-margin commodity) but the high-margin workflow and experience layers on top. This suggests three distinct investment theses for the future of developer tools: AI-native augmentation, all-in-one platform consolidation, and pure performance/UX plays. The market is large enough to potentially support winners in all three categories, indicating a fragmentation of the developer tool market rather than a winner-take-all scenario.