MediumThe future of developer tools. Predictions about where the industry is… | by Mike Hearn | Jul, 2026 | Mike’s blogSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Mike’s blog

Code, politics, thoughts

The future of developer tools

Predictions about where the industry is heading

Mike Hearn

12 min read·<br>Just now

Listen

Share

Press enter or click to view image in full size

For over fifteen years my job has been building, open sourcing, evangelizing and selling productivity tools to software developers. It wasn’t a conscious career choice. More like one thing led to another, and it was fun, so that’s what I did.<br>Now I’m pondering what this work looks like post-LLMs. It’s on my mind a lot because, as always, I’m currently working on developer tools.<br>This is a thinking-through-writing essay and covers some personal predictions about what the next five years of tooling progress might look like. It doesn’t represent the views of my anonymous employer, which as far as I know doesn’t have any position on the matter.

T+0 days: Bewilderment<br>The most common reaction when I say I’m working on a new programming language is surprise. Why bother? It’s not like anyone is going to use it. If you believe that nearly all code in future will be written by LLMs (and I do) then it’s reasonable to ask:<br>How will they learn a new tool without examples in the training set?<br>Who cares what tools models use anyway? It’s not like they’re going to complain, or go work for a competitor because your tech stack is obsolete.<br>But I think there are good answers to these questions.<br>Let’s start with the training set. Is there really a catch-22 here? No, for two reasons. The first is obvious enough: LLMs support in-context learning where you load skills into the context window. This increases costs because the skill has to be processed on every single server round-trip (cached tokens are only cheap, not free). But there’s clearly a break even point here: for some skills the token savings are big enough to pay for themselves.<br>The second reason is a bit less obvious. Modern LLM training exposes the model to trillions of tokens, but it’s common that each token in the training set is only seen once. A conventional understanding of ML says you need millions of examples to learn a new skill, but this isn’t true when thinking about LLMs learning developer tools. Frontier models can remember the details of very obscure tools that have almost no examples in the training set. For example try asking about Hydraulic Conveyor, a tool for deploying desktop apps that’s used mostly by proprietary apps so there’s only a handful of config file examples on GitHub.<br>I suspect the frontier labs are all using curriculum learning, so by the time they’re introduced to the documentation for these tools they’ve already mastered all the knowledge needed to understand them and the details can be successfully encoded into the weights with a single backwards pass.<br>In other words, getting knowledge into models is actually quite easy. You don’t need a massive community creating millions of examples. As long as the crawlers find your website and as long as that website has plenty of docs, the models will get some understanding of how to use it. They might not memorize every single detail but they’ll remember enough to be useful. The expensive period in which you need to explain everything in a skill is not necessarily long. Soon enough, all you need for LLM success is a tiny skill that only contains the changes from what it learned to the current version.<br>Now, an LLM won’t organically choose your obscure new tool if all you have is a website. The model has ‘opinions’ about what it ‘wants’ to use, and affecting those is harder. We’ll come back to that later.<br>The second reasonable question people ask is, “Does it even matter what tools models use?” Companies equip humans with better tools hoping for cost savings, lower time-to-market, improved morale, and maybe an advantage in the hiring market. Humans like adopting new tools because they’re more enjoyable or productive to use, to buff their CV or because they’re bored. But language models are cheap, don’t suffer morale problems, don’t write CVs and you can hire them with just a credit card.<br>Yet the cost argument remains. LLMs and humans differ in many ways but better tools make both of them work faster and therefore cheaper. Fast and cheap is good. That’s the only motive you need to continue creating new tools, languages and abstractions.

T+1 year: Proof of Productivity<br>I think by mid 2027 these sorts of conversations will have stopped happening and we’ll have new conventional wisdom: developer tools have value because they reduce token costs and wall clock time. Although hardly anyone is advertising tools this way today, soon enough everyone will think it was obvious from the start.<br>Some big changes are implied by this goal. One is that development of any kind of tool comes to...