June 11th, 2026

There 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.

But 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.

Because of this even more of these legacy software languages are being used to create even more content for future models to train on.

It seems like we're stuck in a feedback loop of sorts.

So what's a new language to do to become viable in the era of LLMs?

The 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.

A new language also going to need a little bit more to play well with LLM agents.

Documentation and Context

One approach is to have your new language create an AGENTS.md type file from the binary itself, something along the lines of:

webpipe init --codex

Here's the LLM template used by Web Pipe, an experimental web application DSL that I've been working on lately.

It'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.

I'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.

Landing Pages

The 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.

So don't just target one runtime like a CLI tool. Target a browser runtime as well!

Tooling

You'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!

One 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!

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.