{"slug": "how-a-new-dsl-may-survive-in-the-era-of-llms", "title": "How a new DSL may survive in the era of LLMs", "summary": "A new domain-specific language (DSL) called Web Pipe is being developed to remain viable in the era of large language models by integrating with LLM agents through an AGENTS.md template file and embedding familiar languages like jq, Lua, and JavaScript. The language's creator argues that new languages must prioritize robust documentation, interactive browser-based landing pages, and comprehensive tooling—including a single binary that operates as both runtime and language server—to provide immediate diagnostic feedback and compete with established languages. This approach aims to break the feedback loop where only legacy languages benefit from LLM training data, potentially sparking an explosion of new DSLs in the coming years.", "body_md": "## How a New DSL May Survive in the Era of LLMs\n\nJune 11th, 2026\n\nThere have been an untold amount of projects written in Python, Rust, Ruby, and other \"legacy\" software languages over the last few decades. All of this code has made for great fodder for LLMs. As these models have progressed the instances of hallucinations have decreased dramatically.\n\nBut it's not just the mere volume of source code to train on. It's the advanced tooling around these languages. Type checkers, linters, language servers, compilers, interpreters, testing harnesses, you name it. All of these tools ground software in reality and give an LLM agent immediate feedback. For example, hallucinations are caught by the type checker before the code is even run.\n\nBecause of this even more of these legacy software languages are being used to create even more content for future models to train on.\n\nIt seems like we're stuck in a feedback loop of sorts.\n\nSo what's a new language to do to become viable in the era of LLMs?\n\nThe answer isn't too dissimilar to how things used to work: great documentation, great marketing, and great tooling. How does a prospective language user find out about a new language? How do they onboard? How does the language integrate with their existing tools and workflows? A modern language is going to need a robust language server. It is going to need an extensive set of documentation with a good onboarding flow.\n\nA new language also going to need a little bit more to play well with LLM agents.\n\n#### Documentation and Context\n\nOne approach is to have your new language create an AGENTS.md type file from the binary itself, something along the lines of:\n\n`webpipe init --codex`\n\nHere's the [LLM template](https://github.com/williamcotton/webpipe/blob/main/src/scaffold/templates/LLM.md.template) used by [Web Pipe](https://github.com/williamcotton/webpipe), an experimental web application DSL that I've been working on lately.\n\nIt's a bit unfair because Web Pipe has a number of advantages that other DSLs might not have. It embeds other languages like jq, Lua, JavaScript, SQL and a few more. LLMs are already going to have familiarity with these languages so the syntax and semantics of the pipeline-oriented approach are not that much more to learn.\n\nI've already 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.\n\n#### Landing Pages\n\nThe quicker you can get across the purpose and use case of a new language the better. The quicker you can get someone playing with the language the better. 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, as is the case with another project of mine called [Datafarm](https://williamcotton.github.io/datafarm-studio).\n\nSo don't just target one runtime like a CLI tool. Target a browser runtime as well!\n\n#### Tooling\n\nYou're going to need great diagnostics. From compile time, to runtime, to linting, you name it, you're going to need to throw the kitchen sink at this problem. You will need a language server and you will need multiple interfaces with the underlying diagnostic tooling. And of course we've got a plethora of agentic programming tools out there to assist with this!\n\nOne pattern I've come across is to create a single binary that operates as the runtime and the language server. This keeps all of the diagnostic feedback inline between the two. In addition, separating the diagnostics from the LSP APIs means you can ship WASM diagnostic tools for a browser-embeddable component like Monaco. Red squiggles under all of your typos and syntactical errors, no matter the tool or runtime, FTW!\n\nIt'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.", "url": "https://wpnews.pro/news/how-a-new-dsl-may-survive-in-the-era-of-llms", "canonical_source": "https://www.williamcotton.com/articles/how-a-new-dsl-survives-in-the-era-of-llms", "published_at": "2026-06-11 14:35:41+00:00", "updated_at": "2026-06-12 00:48:25.974455+00:00", "lang": "en", "topics": ["large-language-models", "artificial-intelligence", "ai-tools", "ai-agents"], "entities": ["Python", "Rust", "Ruby"], "alternates": {"html": "https://wpnews.pro/news/how-a-new-dsl-may-survive-in-the-era-of-llms", "markdown": "https://wpnews.pro/news/how-a-new-dsl-may-survive-in-the-era-of-llms.md", "text": "https://wpnews.pro/news/how-a-new-dsl-may-survive-in-the-era-of-llms.txt", "jsonld": "https://wpnews.pro/news/how-a-new-dsl-may-survive-in-the-era-of-llms.jsonld"}}