tecosystems

AI Tooling, Evolution and The Promiscuity of Modern Developers

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit


Zhixin Sun, Fangchen Zhao, Han Zeng, Cui Luo, Heyo Van Iten, Maoyan Zhu, CC BY 4.0, via Wikimedia Commons


Historically, there have been two constants with developer tools. First, that their users were loyal to them. This was in part attributable to simple baby duck syndrome, but there were practical considerations as well such as keybindings and shortcuts. Many developers were unwilling to invest in retraining their muscle memory to an entirely different context and set of commands, and thus stuck with their text editor or IDE of choice even as a given tool aged and began to lag from a feature standpoint. There were exceptions, of course: Sublime Text attracted a sizable number of former Emacs and vi users, as did VS Code after it. But in general, migration away from popular tools were the exceptions that proved the rule.

The second thing that has been a given for developer tools is that they were free. Those with back problems or who need reading glasses to read a menu might object citing examples like Borland, but the reality is that it’s been decades since developers needed to find real budget to access quality developer tooling. The aforementioned Emacs and vi text editors were free, as was VS Code, and IDEs would soon follow. The open sourcing of NetBeans in June of 2000 by Sun was followed by the formation of the consortium a year later by IBM that eventually became the Eclipse Foundation, which meant developers not only had a free IDE at their disposal, but a choice between them. This industry trend was so strong, in fact, that up until very recently it was effectively impossible for startups in the developer tooling space to attract venture funding. When the competition is both quality and costs nothing, the returns on invested capital are far from certain.

Fast forward to four years ago last month.

On June 29, 2021 – a little less than a year and a half before OpenAI launched ChatGPT – GitHub introduced a brand new product called Copilot. Driven by talent acquired with the Semmle team, Copilot was regarded as a revelation at the time. There were precedents, to be sure: Tabnine, for one, has roots going back to 2013. But the combination of Copilot’s unrestricted access to the corpus of data that is GitHub and its timing proved transformational. With AI just beginning to accelerate in the wake of the publication of Google’s “Attention is All You Need” paper – which introduced the transformer architecture that so much of today’s AI relies on – Copilot lit the software world on fire, triggering dreams of hyper-productive software engineers while simultaneously stoking fears of wide scale developer unemployment.

GitHub was the first company in decades to buck precedent, and prove conclusively that it was possible – given the right product – to charge for developer tooling. Within two years, in fact, it was a $100M ARR business – an unimaginable figure given how reluctant developers and enterprises alike had been to pay literally anything for the primary tool of a developer’s trade.

If the second foundational assumption was shattered, however, surely the first would hold. It was widely assumed that developers, who already had had a long term affinity for GitHub itself, would demonstrate their characteristic loyalty to the coding assistant they had first imprinted on.

Except they did not, and do not.

What GitHub did in two years, in fact, Cursor did in 12 months: a year in, the company – with reportedly zero marketing – hit a hundred million run rate. Many of its users were former – and potentially future, as we’ll come back to – Copilot users.

Almost everything we knew, then – or thought we knew – about the developer tools space turned out to be wrong. Promiscuity has replaced loyalty, but the good news is that the budget is no longer anchored to zero dollars. There is no single reason for these developments, as there are a number of contributing factors.

Arguably the most important is the degree to which AI is inherently a transformational technology. With its ability to ingest, process and act on natural language, for example, inputs are often now a prompt or a spec – for neither of which keybindings or shortcuts matter particularly. AI has also has heralded a massive era of experimentation as vendors and projects seek creative new ways to apply the technology to the task of developing software. There is, at present, no consensus, no dominant approach, and there may never be. Some developers prefer the more free-wheeling “vibe code” approach via prompts; others prefer the more deliberate spec driven development – in many respects emulating the divide between authors of fiction who go by the seat of their pants versus those who rely on predetermined plots. In some cases developers want to be gradually stepped through proposed steps or changes; in others they just want the machine to come back when it’s done. Some tools merely propose changes, others like the recently relaunched Aboard will combine development with a full stack including a database. Some tools retain the UI elements of traditional IDEs; others are nothing more than a text field.

In short, we are in the midst of a Cambrian explosion of developer tools, and a dizzying array of approaches are currently being tested for their evolutionary fitness. Consider even an abbreviated, absolutely non-exhaustive list of related tools: Aboard, Bolt, Cline, Copilot, Cursor, ChatGPT / Codex, Claude / Code, Gemini / CLI, Factory, Lovable, Poolside, Replit, Same.dev, vibes.diy, v0, watsonX and Windsurf. Not all of these will succeed, and indeed some argue that all of these are doomed because the economic footing they’re built on is fatally unsound. That argument is built on two core assumptions, however: that vendor costs will never come down and that user costs can not be raised – neither of which seems entirely safe. More likely is that some of these options emerge and fundamentally change the way the industry builds software moving forward. Others, meanwhile, will be abandoned as dead ends in a manner consistent with both biological evolution and technical innovation. Developers, regardless, are far more willing to experiment with new tools, because they are fundamentally differentiated from one another in ways that past generations of developer tools have typically not been.

Also fueling the willingness to flit from tool to tool are cost and token inventory concerns. While developers are now objectively willing to pay for tools, they still appreciate free tiers and will use up whatever resources are made available to them at no cost. For paid plans, meanwhile, developers are frequently outstripping their allotted inventory of tokens at their given paid tier, and simply move on to the next tool with available credits. Whatever their tooling preferences, therefore, in some cases costs lead them to use deploy multiple distinct developer tools in development on the same application – again, a practice which would have been unthinkable even a few short years ago.

Lastly, there is the firmly engrained idea amongst developers that these tools are useful. The organizational metrics may argue otherwise, but a clear majority of individual developers feel more productive. There are, again, many who would argue that the tools are inherently unusable, inherently uneconomic, inherently immoral or some combination of all three. But that is, at this point, the minority opinion and as stated eloquently here it seems extremely unlikely the tools will be uninvented. As such, developers will both keep using the tools, and will be willing – if reluctantly – to pay for them – likely even if the costs escalate, which creates the worrying potential for a greater economic divide. To that end, some developers are willing to pay to the degree that my colleague recently reported that in contrast to some skeptical enterprises that balked at the idea of paying $20-$40 a month per developer, a developer acquaintance of his recently stated that if one wasn’t spending hundreds of dollars a month on AI tooling they were not a serious developer. Which, again, raises the spectre of haves and have nots. A world in which the best developer tools cost nothing was a world with fewer barriers to entry, after all.

But if it’s clear that the rules have changed with respect to developer tools, the implications of this are more opaque. A few conclusions suggest themselves, however.

  • It’s Not Too Late: if it wasn’t too late for Cursor in the wake of Copilot’s explosive growth, it’s not too late for the next Cursor. Which, given that that was Windsurf, which was valued at $3B, seems to demonstrate the point adequately. There will remain opportunities for these businesses for the foreseeable future. There is room for experimentation, for user acquisition and for vendors that charge for developer tools. So while rumors suggest as one example that AWS has a new tool on the way – purportedly called Kiro – its window would still be open. There is also, importantly, opportunity for products that have “lost” users to gain them back, as developer promiscuity cuts both ways.
  • Partnerships Will be Important: under appreciated currently, at least as far as enterprise usage is concerned, is the white space that remains. All of the tools take novel approaches to accelerating software development. The majority, however, are narrowly focused on some aspect of the application development process, and like GitHub once upon a time, leave anything else as a problem to be solved by some combination of customers and partners. Tool vendors and downstream build, test, observation and deployment targets alike would be wise to start integrating to close the gaps in their developer experience. Importantly, however, this will require AI companies willing to engage with third parties, something many of them have seemed too busy to do to date.
  • Lack of an Approach Consensus Will Slow Enterprise Adoption: speaking of gaps in the developer experience, after the publication of the linked piece, RedMonk heard from dozens of organizations who perceived the same issue and were attacking the problem with a new product and/or company. The challenge was that they all took slightly different approaches to addressing the developer experience gap. As a result, enterprises struggled to compare the proverbial apples to oranges and the market for tools that would impact the problem lagged. AI tooling will be less susceptible to this, but the sheer variety of different approaches will suppress adoption to a degree as businesses are forced to wade through the variety of approaches the tools represent in an effort to decide which will be most impactful for their particular needs.

Evolution, at its core, is always a messy, non-linear process, and AI tooling will be no exception. But it inexorably hammers, reshapes and refines models, producing output that is ever more fit for purpose. And in that, too, AI will be no exception.

Disclosure: AWS (Kiro), GitHub (Copilot), Google (Gemini / CLI) and IBM (watsonX) are RedMonk customers. Aboard, Anthropic (Claude), Bolt, Cline, Cursor, Factory, Lovable, OpenAI (ChatGPT), Poolside, Replit, Same.dev, Tabnine, vibes.diy, Vercel, and Windsurf are not currently RedMonk customers.