More and more code is being written with automated tooling—Copilot, Poolside, Cursor, Cody, Factory, and Devon, to name a few. Some of these tools autocomplete ideas that engineers actively type. Others work in background servers to put up asynchronous pull requests. The amount of competition in the space is impressive, and I suspect no one code-generation tool will rule them all.
Why? Code generation is a mixture of three components:
Contextual data
A foundational LLM model
An interface to save the code change to
There is unlikely to be a major winner in the code generation space because there is no easy way to achieve long-term, outsized advantages. Foundational LLMs are rare, expensive to create, and increasingly accessible to all code-generation companies. I doubt any dev tool will create its own powerful, unique foundational model that isn’t accessible by others. Even Google worries it can’t create a moat around their LLM, as highlighted in a leaked memo. Furthermore, the development of open-source models like Meta’s LLaMA exemplifies how foundational LLMs are becoming increasingly accessible. This democratization of LLMs diminishes any potential competitive advantage—so you can’t differentiate on the LLM.
The interfaces to log code changes are open and standardized as well. You can save a code change in only three places—the IDE, the local file system, or the remote repository. VSCode allows for extensions from any aspiring developer, the file system is completely open for programs to write to, and GitHub allows any installed app to publish PRs. Open standards like JSON, XML, and RESTful APIs facilitate interoperability, making it easier for developers to switch between tools. So, there’s no room for a winning code generation tool to monopolize the interface to which changes are written.
Lastly, there’s context—the information about the state of the world needed for the LLM to produce relevant code changes. Unfortunately, context is fragmented across tens of SaaS applications—GitHub, Figma, Jira, Notion, Google Docs, Zoom meeting notes, Teams, Slack, etc. At best, a code generation tool can gather as much context as possible—but so can any competing tool. There’s no moat in indexing freely accessible data sources; everything can be copied and shared.
Given these factors, we find ourselves in a landscape filled with numerous code generation tools, each vying for attention but none able to secure a definitive lead. Some are further developed than others—but none with a distinct edge. They come in different forms—some run in the background, others in VSCode, some on-prem. However, unique form factors don’t lead to long-term sustained advantages in business or software.
This competitive dynamic aligns with Hamilton Helmer’s 7 Powers framework. None of the code generation tools have achieved any of the seven forms of power that could lead to a sustainable competitive advantage:
Scale Economies: The cost structure doesn’t meaningfully improve with size.
Network Economies: No strong network effects between users of the same tool. Unlike social media platforms, where each additional user increases the value for others, code generation tools don’t benefit significantly from user networks.
Counter-Positioning: Established players can easily copy innovations. Innovations are rapidly adopted across the industry, preventing any single player from gaining an edge.
Switching Costs: Developers can easily switch between tools. The Stack Overflow Developer Survey 2022 shows that tool adoption is highly fluid, underscoring the low switching costs in the developer tooling space.
Branding: Limited emotional attachment to code generation tools, especially as they become headless. While some developers may prefer certain tools, the emotional attachment is limited.
Cornered Resource: All key resources (LLMs, interfaces, context) are accessible to competitors.
Process Power: No significant proprietary processes that others can’t replicate. As noted in the MIT Sloan Management Review, software processes are often transparent and easily replicable, limiting this form of competitive advantage.
Without any of these powers, the code generation space will likely remain fragmented with multiple competing tools, each finding its niches but none achieving a dominant market position. Economic theory argues that in competitive markets, firms struggle to earn excess profits in the long run due to the absence of barriers to entry. The code generation space mirrors this scenario, where minimal barriers and rapid innovation sharing prevent any single player from dominating. Note - this won’t stop short-term competition, profits, and high valuations.
Currently, and in the long future, I think different IC engineers will leverage Swiss army knives to generate code changes. One bot might be good for asynchronously fixing accessibility on front-end components. Another might run fast locally for autocompleting functions. Developers often prioritize flexibility and efficiency, choosing tools that best fit their workflow. This preference reduces the likelihood of a single tool becoming dominant.
Engineers will fight over the differences in subjective style generation between different tools. The Vim vs. Emacs war will resurface in the form of Copilot vs. Cursor. Some might argue that a superior user experience or unique integrations could give one tool an edge. However, these advantages are often short-lived, as competitors can quickly replicate features, and developers can switch tools with minimal friction. Companies won’t enforce any standard set of tools because as long as developers are happy and the code is flowing, they don’t care.
In essence, without the ability to establish sustainable competitive advantages, the code generation tool market will remain fragmented. In the limit, the space will become a commodified knife fight, with the possibility of a local open-source, LLaMA-powered tool becoming “good enough” that revenue-seeking competition dies altogether. Ultimately, the evolution of code generation tools may lead to a landscape where open-source solutions become the norm, and proprietary tools struggle to justify their value proposition in a commoditized market.
