A question on Hacker News asked what the universal programming language of future LLMs would look like. Not a language humans read or modify, but one built by LLMs for LLMs. A language that can build any kind of application: backend, mobile, desktop, web, embedded. The question is worth taking seriously because the answer is already taking shape, even if it does not look like a programming language in the traditional sense.

The Language LLMs Already Use

LLMs already have a universal interface. It is JSON. Function calling schemas, tool definitions, API contracts, configuration files, and structured prompts all use JSON or close derivatives. When an LLM needs to express a data structure, it produces JSON. When it needs to invoke a tool, it produces a JSON object matching a schema. When it needs to configure a system, it writes YAML or TOML, both of which are JSON's close relatives.

This is not an accident. JSON is trivial to generate, trivial to parse, and trivially validated against a schema. An LLM can produce valid JSON with high reliability because the format has minimal syntax, no ambiguity, and a small surface area for errors. Human languages have idiosyncrasies, naming conventions, and style rules that vary by ecosystem. JSON does not.

If you are looking for the universal programming language of LLMs, you may already be looking at it. The question is whether it stays that way or evolves into something more expressive.

Why Human Languages Do Not Fit

Human programming languages are designed for human cognition. They use keywords that resemble natural language. They have indentation rules, naming conventions, and structural patterns that help humans scan code quickly. They prioritize readability because humans spend more time reading code than writing it.

LLMs do not read code the way humans do. They process tokens. Indentation is irrelevant to them. Naming conventions are learned patterns, not comprehension aids. A function called calculate_total_amount is no easier for an LLM to process than one called cta. The human-oriented design choices that make Python readable or Rust expressive are wasted on a machine that processes text as a sequence of tokens with statistical relationships.

What LLMs need is something different. They need unambiguous structure. They need composability. They need a format where the relationship between elements is explicit rather than implicit. Human languages rely heavily on implicit relationships, which is why LLMs sometimes produce syntactically valid but logically broken code: the implicit conventions were not captured in the tokens.

What a Language for LLMs Might Look Like

A language designed for LLMs would likely have several properties that differ from human languages. First, it would be maximally unambiguous. Every construct would have exactly one interpretation. Human languages use overloading, implicit type coercion, and contextual meaning extensively. An LLM language would avoid all of that.

Second, it would be composable at the token level. LLMs generate text sequentially. A language that works well for them would allow valid partial completion. You could stop generating at any point and have something meaningful. Human languages do not work this way: a half-written function in Python is a syntax error. An LLM language might treat a partial expression as a valid program that simply returns the value computed so far.

Third, it would separate intent from implementation completely. The language would describe what should happen, not how. This is already how LLMs work when they produce code: they describe behavior in natural language and translate it into an implementation language. A native LLM language would formalize that translation step, making the intent the primary artifact and the implementation a derived output.

Fourth, it would be trivially serializable. LLMs work with text. The language would need to compress complex program structures into compact token sequences. This is where something like Protocol Buffers or Cap'n Proto already points: binary schemas that express type information compactly. An LLM language might extend this idea to include control flow and behavioral specifications.

The Shape of What Already Exists

Several existing approaches hint at what this language might become. Declarative configuration languages like Terraform's HCL describe desired state, not implementation steps. SQL describes what data to retrieve, not how to retrieve it. Workflow definition languages like Temporal's workflow APIs describe execution paths without specifying the runtime mechanics.

All of these share a common trait: they are already easier for LLMs to generate correctly than imperative code. An LLM can write a Terraform configuration with fewer errors than a Go implementation of the same infrastructure because the declarative format has less surface area for logical mistakes. The format constrains what the LLM can express, and those constraints are features, not limitations.

The universal LLM language might not be a single language at all. It might be a family of declarative schemas, each optimized for a different domain: data models, API contracts, UI layouts, infrastructure definitions, business rules. What unites them is not syntax but semantics: they all describe intent in a format that a compiler, runtime, or another LLM can translate into working systems.

What This Means for Human Developers

If LLMs develop their own native language, human developers do not disappear. They shift roles. Instead of writing implementation code, they write specifications, constraints, and evaluation criteria. The LLM produces the implementation. The human reviews it, tests it, and validates that it matches the intent.

This is already happening. Developers write natural language descriptions of what they want. LLMs generate code. The bottleneck is not the generation step. It is the specification step: expressing intent clearly enough that the LLM can translate it without ambiguity. A formal LLM language would make that specification step more precise, which would make the generation step more reliable.

The question on Hacker News assumed that this language would be built by LLMs for LLMs. That is the most likely path. Humans are not the target audience. The language does not need to be readable, writable, or maintainable by humans. It needs to be generatable, parsable, and executable by machines. That is a fundamentally different design space, and we are watching it emerge in real time.