LLMs ate the training data. New DSLs need better tooling to survive.

Every new programming language born today faces a chicken-and-egg problem that did not exist five years ago. The egg is the corpus of source code that large language models train on. The chicken is the LLM itself. A new language with almost no training data will produce almost no useful completions. A language with no useful completions will attract almost no users. And without users, it will never generate the training data it needs to escape the trap.

William Cotton laid out the problem in a post on June 11. He is the creator of Web Pipe, an experimental web application DSL. His diagnosis is blunt: the feedback loop of legacy languages like Python, Rust, and Ruby is self-reinforcing. “All of this code has made for great fodder for LLMs,” he writes. The advanced tooling around those languages — type checkers, linters, language servers, compilers, testing harnesses — gives an LLM agent immediate feedback. Hallucinations are caught by the type checker before the code even runs. More legacy code begets more training data, which begets better models, which begets more legacy code.

A new DSL does not get to play that game.

Cotton’s answer is not to out-train the incumbents. It is to out-tool them. His post sketches a survival playbook built on three pillars: agent-friendly documentation, browser-embeddable runtimes, and unified diagnostic tooling that collapses the language server and the runtime into a single binary.

The first pillar is an AGENTS.md file. Cotton’s Web Pipe project ships a template that an LLM agent can consume directly. The template describes the language’s syntax, its embedded sub-languages (jq, Lua, JavaScript, SQL), and the semantics of its pipeline-oriented approach. Cotton reports that he has had “a lot of luck with one-shot prompts in codex to create demo applications using Web Pipe with just this single AGENTS.md template file as guidance.” The insight is simple: an LLM cannot learn your language from first principles, but it can follow a well-structured prompt that describes the language’s surface area. The AGENTS.md file is the bridge — a documentation format designed not for human reading but for agentic code generation.

The second pillar is the landing page. Cotton argues that the quickest path to adoption is getting a potential user to run code in the browser within seconds. “Since it has never been easier to create WASM runtime environments for new languages you can benefit immensely from adding an interactive editor right at the top of your landing page,” he writes. His other project, Datafarm, does exactly that. A WASM-compiled runtime means the language runs in any modern browser with zero installation. The interactive editor becomes the first impression, the tutorial, and the demo all at once.

The third pillar is the most technically specific. Cotton recommends shipping a single binary that operates as both the runtime and the language server. This keeps diagnostic feedback inline between the two. Separating the diagnostics from the LSP APIs means the same tooling can ship as a WASM component for a browser-embeddable editor like Monaco. “Red squiggles under all of your typos and syntactical errors, no matter the tool or runtime,” he writes. The payoff is that an LLM agent working inside a browser-based IDE gets the same real-time error feedback that a Python developer gets from Pyright.

The answer is not to out-train the incumbents. It is to out-tool them.

Cotton’s framework is convincing in its specifics, but it sidesteps a harder question. The AGENTS.md approach works for a DSL that embeds familiar languages like Lua and SQL. An LLM already understands those sub-languages, so the template only needs to describe the orchestration layer. A truly novel language with no embedded sub-languages has no such crutch. Its AGENTS.md would need to describe an entire syntax and semantics from scratch, and the LLM would have no prior weights to draw on. The quality of generated code would be lower, and the feedback loop would be slower to start.

There is also a data paradox that Cotton does not address. If a new DSL succeeds in attracting users and generating code, that code becomes training data for the next generation of LLMs. Those LLMs will then be better at generating code in the new DSL, which will attract more users, which will generate more training data. The feedback loop that currently favors legacy languages can flip in favor of the new DSL — but only if the DSL reaches a critical mass of usage first. The chicken-and-egg problem is not solved. It is merely postponed to a larger scale.

Cotton is optimistic about the near future. “It’s my opinion that we’re going to see an explosion of new languages, especially of the DSL variety, over the next few years as it becomes easier and easier to cover the bases needed for liftoff,” he writes. The bases he names — agent-friendly docs, WASM runtimes, unified diagnostic tooling — are genuinely easier to cover today than they were five years ago. The infrastructure for shipping a new language has never been cheaper.

The open question is whether that infrastructure is enough to overcome the gravitational pull of Python, Rust, and JavaScript. Those languages have millions of repositories, decades of tooling, and LLMs that can generate entire applications from a single prompt. A new DSL that ships an AGENTS.md file and a WASM playground is still asking developers to learn a new syntax for a marginal gain in expressiveness. That is a hard sell in any era.

Cotton’s playbook is the best answer available. It is also a bet that the next wave of programming will be built not on general-purpose languages but on narrow, purpose-built DSLs that are easy for both humans and agents to pick up. The bet is worth watching — because if it pays off, the feedback loop that currently locks in legacy languages will start to favor the newcomers instead.