AINEWS
Designing a Language for the LLM Agent
Legacy languages dominate LLM training data, and the toolchain gap keeps widening. William Cotton's Web Pipe shows a concrete path for new DSLs to compete, and what that path costs.
Legacy languages dominate LLM training data, and the toolchain gap keeps widening. William Cotton's Web Pipe shows a concrete path for new DSLs to compete, and what that path costs.
Most new programming languages die quietly, never reaching the developers they were built for. The graveyard is full of elegant grammars that nobody trained on. William Cotton, creator of the Web Pipe data-flow DSL, argues the LLM era has made that hill steeper for new entrants, but not impossible to climb, provided the language designer treats the model as a first-class user from the first commit.
The structural problem is data. LLMs are trained on huge corpora of code in a handful of legacy languages, especially Python, Rust, and Ruby. A new DSL arrives with essentially none of that. Worse, those same legacy languages ship with rich toolchains: type checkers, linters, language servers, compilers, test harnesses. When an LLM agent writes a Rust program, the compiler can flag the hallucination before the program runs, and that fix feeds the next training cycle. The feedback loop keeps running. A new language that lacks even a parser that returns a clean error starts several rounds behind.
This is the argument Cotton lays out in a recent post on his personal site, written from the vantage of someone shipping a DSL in production. He is not pitching Web Pipe as a cure-all. He is using it as a worked example for a more general claim: a new language can survive the LLM era, but only if it gives the agent something to work with on day one.
The first lever is context. Cotton suggests a new language should ship its own AGENTS.md-style file: a plain, model-readable description of the language's purpose, idioms, and constraints, generated alongside the grammar. The goal is to compress the distance between "I have never seen this language" and "I can write a correct program in it" without a human in the loop. This is not magic. It is the same onboarding document a new hire would read, formatted for the model that will write the first thousand lines of code.
The second lever is familiarity. Web Pipe deliberately embeds syntax from languages the models already know: jq for transforms, Lua for scripting, JavaScript for expression context, SQL for joins. The bet is that borrowed surface area lowers the model's error rate even before it has seen a single example in the new language. This is a contrarian move among language designers, who usually prize orthogonality. Cotton is betting orthogonality is a luxury new DSLs cannot afford in 2026.
The third lever is the toolchain. A robust language server is not optional, in Cotton's account. It is the channel through which the model receives feedback on its own output. A type checker that catches a hallucinated field name is worth more than a paragraph of prose in a README, because the model can act on the error and try again. The compiler becomes a teacher. Web Pipe ships with one, and Cotton treats that as a non-negotiable part of the language, not a downstream concern.
None of this is free. Cotton is explicit about the cost: great documentation, great onboarding, great marketing, and agent-grade tooling. That is a four-line budget for a project most language designers launch with a GitHub repo and a dream. The LLM era has not lowered the bar for new languages. It has raised it, by adding an agent-shaped customer to the list of people a new DSL has to please.
The honest counter is that the training-data moat is real. Even a perfectly designed-for-agent DSL still loses to Python on raw familiarity for years. The feedback loop Cotton describes is a genuine advantage for legacy languages, and no amount of context files or borrowed syntax will close the gap overnight. The argument is not that new DSLs will out-ship Python. The argument is that the gap is narrower than it looks, and the path through it is concrete.
Web Pipe is the proof of concept, not the product being sold. Cotton built a working DSL, gave it a model-readable spec, embedded familiar syntax, and shipped a language server. None of that required a research lab or a foundation model. It required treating the LLM agent the way a library author treats a new developer: as a real user with real failure modes, deserving a real onboarding experience.
The lesson generalizes. Any new language that wants to be written in 2026 has to decide, before its first release, what the model will see when it looks at the docs. A page that reads well to a human but ignores how the model parses instructions is a page that asks the agent to guess. The DSLs that survive the LLM era will be the ones that stop asking.