Do LLMs make code a "materialized view"?

Software engineer Nate Meyvis argues against the view that large language models make code a mere 'materialized view' of ideas, citing Hyrum's Law, platform differences, and performance concerns. He embraces LLM-assisted migrations but rejects the notion that code is just a projection of higher-level concepts.

Do LLMs make code a "materialized view"? Here https://tannerlinsley.com/posts/projecting-react 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 https://www.natemeyvis.com/the-future-of-migrations/ , here https://www.natemeyvis.com/migrations-with-ai-again/ , and here https://www.natemeyvis.com/the-future-of-migrations-again/ . 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: Hyrum's Law https://www.hyrumslaw.com/ reminds us that users will depend on any observable behavior of your system.Your ideas underdetermine your code, so the code must be more than a materialization of ideas. 2 fn-2 3 fn-3 - 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 fn-4 - Performance matters is underrated as a determinant of the user's experience https://www.natemeyvis.com/notes-on-software-performance/ . 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. It's an interesting subject, but I didn't actually read the article, because I'm generally averse to LLM prose https://www.natemeyvis.com/the-case-against-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." ↩ fnref-1 Whether this is a matter of potentiality or statistical near-certainty depends on your scale. ↩ fnref-2 ...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. ↩ fnref-3 As John Gruber likes to remind us https://daringfireball.net/2026/07/claudes criminally bad mac app is an inside job , different platforms are different . ↩ fnref-4