Nate Meyvis

Do LLMs make code a "materialized view"?

Here is Tanner Linsley on React and Preact.1 One hears versions of its central claim often these days:

We only treat code as the source of truth because regenerating it is expensive. Flip that cost and the model inverts: the ideas become the base table, and the code becomes one projection among many.

I am indeed optimistic about the future of migrations: see here, here, and here. Indeed, I think that most programmers are still underestimating how different this part of the job will be.

I disagree with the "code is just a projection" view, though, for several reasons:

  1. Hyrum's Law reminds us that users will depend on any observable behavior of your system.2 Your ideas underdetermine your code, so the code must be more than a materialization of ideas.3
  2. Different platforms, languages, and tools are different. The "ideas" and their expression will, therefore, be different. Consider a fairly simple idea like: "show all options to the user and let them pick up to three." This task is way different on the Web and on a phone. It might even be quite different in React and a different front-end framework: they're often different in the details, and the details tend to matter a lot.4
  3. Performance matters is underrated as a determinant of the user's experience. The code-as-materialization view overlooks that different materializations will often have different performance profiles. Similar comments apply to reliability.

So: let's embrace LLM-assisted migrations but reject the "code is just a materialization" thesis.

There's a standard rejoinder here: LLMs are getting better and better, and in the limit, each of these points will go away (LLMs will detect even the tiniest implementation details, will add all features and options to all systems, and will make performance consistently great). But that needs an argument: LLMs will improve, but improvement within a system might make it more distinctive. Think about what makes Rust Rust, what makes React React, what makes SwiftUI SwiftUI, and so on. Then think about what these will look like in a medium-term future, when they and their ecosystems have been shaped by zillions of future-LLM tokens. They will, arguably, be more distinctive than they are today. LLMs will push languages, tools, and platforms to be more similar and mutually translatable in some ways, but will also push them to be less similar in others.


  1. It's an interesting subject, but I didn't actually read the article, because I'm generally averse to LLM prose. So, this isn't a recommendation. But the article got some traction, and the idea I'm discussing is very much "in the air."

  2. Whether this is a matter of potentiality or statistical near-certainty depends on your scale.

  3. ...at least in the sense of "ideas that can be written down or form the basis of a migration." I don't intend this as an anti-Platonic argument.

  4. As John Gruber likes to remind us, different platforms are different.