AI and the market for dev tools

AI makes it easier than ever before to produce code. It helps actual programmers produce more code in less time, and lets more people who are not trained programmers participate. But what does this mean for compiler writers and language designers?

Personal notes

I have not posted in a while, for two reasons: First, I have been bogged down with type theory and implementation for over a year now, and that is not good for blogging. I just end up revising the posts forever as I learn more. Second, I have been busy with contract work, which takes time and attention away from Newton.

So this post is not about my progress on Newton. Instead, it is about how the entrepreneurial project that Newton is part of may be impacted by changes in the industry. It is clear we are going through a huge shift right now, and I am trying to figure out what it means for new programming languages and the market for them.

An abundance of code

When new groups of people start producing code, and professional programmers also produce more, it seems obvious that there will be much more code overall. This implies that more code will be executed, analyzed, and read. And if more code needs to be executed, it makes the tools that execute them more important.

This should be bullish for companies that make compilers and runtime environments. Anthropic’s recent acquisition of Bun (a Javascript runtime) is an indication that this logic is already playing itself out. And a few days after I posted this, another acquisition was announced: Astral is joining OpenAI.

When more code is run by autonomous agents, or by humans who do not fully understand it, safety guarantees also become more important. Languages that can be analyzed statically, and sandboxes for the remaining cases, will be more attractive.

Another factor to keep in mind is that the generated code may need to be readable by non-experts. For instance, a trader at an investment bank who previously relied on technical staff to implement custom calculations may now turn to AI instead, but only if she is able to read the resulting code when she needs to understand how a particular figure was derived. The code has to be legible to this new class of “programmers”, or they will not trust it. This implies it has to be more like Excel or Python than Rust, for this use case.

The argument against

A common argument against new languages in the age of AI is that not being represented in the training set is a severe disadvantage.

This sounds convincing at first, but in practice the effect of the training seems to carry over from one language to another. For instance, Anthropic were able to generate a compiler written in Rust by learning from compilers written in C and C++.

Another counterpoint is that a new language does not have to be very different from its predecessor to be useful. Significant gains in execution efficiency and static analysis could be achieved through restrictions that do not force idiomatic application code to change much.

Conclusion

I do not see strong reasons to correct course. The direction I am taking still seems right.

Stefan