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 are the second order effects?

Personal notes

I have not posted in a while, for two reasons: First, I have been bogged down with type theory and implementation for a year now, and that is too demanding to blog about. Second, I am doing freelance consulting again, which takes time and attention away from Newton.

So this post is not about my progress on Newton. Instead, it is about how Newton 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.

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 still need to be reviewed and vetted by a human. For instance, a business analyst who was previously dependent on technical staff to help her with custom calculations may now turn to AI instead, but only if she is able to read the resulting code and convince herself that it is correct. The code has to be legible to the new class of “programmers”, or they will not trust it. This implies it has to be more like Excel or Python than Rust, at least for business analysts.

The argument against

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

This sounds convincing at first, but in practice the effect seems to carry over from one language to another. For instance, Anthropic were able to generate a C compiler in Rust, even though no such compiler was in the training set.

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 can be achieved through small restrictions that do not affect idiomatic application code.

Conclusion

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

Stefan