Large language models have transformed how we write software, but they haven't eliminated the need for programming languages. While AI is changing development practices, code (at least for now) isn't "over." In this post, I discuss the implications of how code is changing from a conversation with two groups (humans and compiler/interpreters) to three (humans, models, compiler/interpreters).

## Code is Still Important

In 2023, Karpathy called English "[the hottest new programming language](https://x.com/karpathy/status/1617979122625712128)." In February of this year, he coined "[vibe coding](https://x.com/karpathy/status/1886192184808149383)" to describe natural language programming without engaging about the code models were generating. In controlled contexts, coding can be automated through natural language.

Yet most development remains off these happy paths­­. Even agents require human review: today, people still need to be engaging at the code level. Code, which has been how teams of people maintain a mutual understanding of what a computer should do, is becoming a medium for models and humans align on program behavior. [Models have specific discursive needs](https://arxiv.org/pdf/2406.00515) to be able to effectively participate in this conversation (2024). Those needs are diverse and changing. "Code" as a form of communication is adapting to these changes.

## LLMs and Humans Read Code Differently

Let's start by talking about what code is and why models don't code like people. Programming languages structure complex instructions through patterns like composition, inheritance and interfaces. LLMs process these patterns differently than humans do. They read codebases quickly but operate within limited context windows. While models can be made to understand specific patterns (example: [python classes](https://arxiv.org/html/2504.15564v1) (2025)), they currently need explicit guidance for things developers take for granted, like variables declared in superclasses.

There are many cases where [more human-readable code is less model-readable](https://arxiv.org/abs/2404.16333) (2024). While humans and models both use language, we process language very differently. As architectural patterns that prevent automation become liabilities, the question becomes: What shared representations work for both humans and models? This question is new and a key concern in software engineering. The introduction of a "third group" (agentive models) in what had always been a dialogue between humans and computers is a paradigm shift. In addition to being compilable/interpretable and understandable between human coders, code must now also be intelligible to models that do not think or use language in the same way that humans do.

## AI & Programming Languages

The first programming language approach in AI is the most conservative: the use of existing programming languages. Most discussions about code and AI start binary: often, people either expect that models will learn to use existing code or that code will become obsolete as models will simply directly replace existing codebases. In early models, corpus size was the primary driver for model quality, so the industry bias was towards popular languages with more lines of code accessible for training. It was never quite that simple though: [language features have always mattered](https://arxiv.org/html/2404.16333v2) (2024) to some degree. Advances in [language-agnostic learning](https://news.mit.edu/2025/making-ai-generated-code-more-accurate-041) (2025) and [grammar-specific training](https://arxiv.org/html/2312.01639v2) (2024) have upset those scales. Models can increasingly perform well in less familiar grammars, decreasing the value of established languages. [Model readability](https://arxiv.org/pdf/2406.08731) (2025) has become a research priority in programming language study and design. As code becomes a three-way conversation, I find myself thinking about model readability in every PR: can this code be made clearer to the reviewers (human or model)?

More ambitiously, new languages designed for use with AI do exist and are interesting. The most striking to me is the second approach I want to highlight: [pseudocode](https://en.wikipedia.org/wiki/Pseudocode) being used as, well, code. There is no formal definition of pseudocode, but it often involves using XML-like tags, or syntactically impressionist bits of Python, FORTRAN, etc. Some of this is built as features into specific models, and some isn't. Discursively, pseudocode was created for humans to talk about coding problems. Now it's also used in dialogues between the human and the model, so that the model can then "understand" and hopefully communicate the "actual" code for the interpreter/compiler. When this goes well, it's like a compiler generating bytecode (no need to review the bytecode, barring extremely rare cases of optimization and debugging). When it goes poorly, it's like a game of telephone.

A third language approach are the creation of new programming languages. An interesting example is [Mojo](https://www.modular.com/mojo). Mojo is a new language predominantly built for speed and cross-compilation to GPUs and other chip classes. Syntactically, it is promising for AI agents as it leverages Python grammar while addressing context window issues by providing better static analysis: the compiler can provide more feedback to the model. (Caution: Mojo is still very new. While it may or may not be easier to generate, it will likely require more effort to debug, as its grammar leaves it prone to reference errors that are currently hard for models, compared to languages like Rust with more rigorous static analysis. As automated remediation improves, this will become less important, but today the immaturity and lack of compilation guardrails do present operational risk.) A similar new language approach is [Moonbit](https://www.moonbitlang.com/blog/ai-coding), which looks a lot like typescript and focuses on understandability with existing model constraints instead of primarily focusing on cross-compatibility.

I think that these languages are very interesting, but underutilize static analysis/formal methods. Static analysis helps predict runtime behavior—critical for both humans and models. For models, formal methods are improving [consistency](https://arxiv.org/abs/2401.05443) (2024). If the risks of inconsistency can be mitigated, models could immediately replace code for many use-cases blocked today by indeterminacy. I feel that there is still rich opportunity for more formal guarantees on the code side: for auditability, correctness, and performance ([I wrote more about this in 2024](https://dominic.computer/blog/2024/side_effects)). Speculatively, those use-cases sound a lot like how people have been talking about SMT solvers and similar, and it seems like formal methods work may benefit from AI as AI benefits from formal methods: the remaining "code" may become the technical language for high-performance or extremely formalized applications, leveraging ever-more ambitiously rigorous compilers.

## Conclusion

The gap between human and machine code comprehension is a communication gap. The gap is hard to bridge because models think differently than we do. As models become better at learning new languages, we can design grammars that serve both audiences effectively. A big part of our work over the next few years is to recognize code's evolving role: not just as instructions for machines or communication between humans, but as a three-way conversation between humans, models, and interpreters/compilers. The question isn't whether to optimize for humans or machines—it's how to do both.