A New Essay on Martin Fowler's Site Says DSLs, Not Prompts, Make AI Agents Reliable. Is a Domain-Specific Language Your YC F26 Startup's Real Moat?

LLMs can write a whole system from a paragraph of English. The problem every YC F26 founder building an agent hits next: getting them to write exactly the right thing, the same way, every time. A new essay that reached the Hacker News front page today has an unfashionable answer. The fix isn't a better prompt. It's a domain-specific language.

The piece, published this week on Martin Fowler's site and written by Thoughtworks distinguished engineer Unmesh Joshi, is titled "DSLs Enable Reliable Use of LLMs." If your F26 application is a thin wrapper whose whole pitch is "we prompt GPT really well," this is the argument that should worry you. It's also the one that points at a real moat, if you take it seriously.

What does the essay actually claim?

LLMs are unreliable in a general-purpose language like Java because there are countless valid ways to express the same intent. A DSL strips that variation away. Joshi points out that models are already remarkably good at PlantUML, Mermaid, SQL, and Kubernetes YAML, and that's not a coincidence: every one of those is a small, deliberately constrained language that a few in-context examples can pin down. The reliability doesn't come from the model getting smarter. It comes from shrinking the space of things it's allowed to output.

That reframing matters. Most founders try to buy reliability with a longer system prompt and more examples. Joshi's claim is that you get far more of it, far more cheaply, by narrowing the target.

Why does this matter for an AI agent specifically?

Here's the part F26 agent founders should tattoo somewhere. An agent is an LLM running in an autonomous generate-and-check loop, not a single-shot generation. And a DSL almost always ships with a deterministic validator: a parser, a JSON schema, a type checker, or a compiler. So the agent generates a candidate, runs it past the validator, and repairs itself from the error, with no human in the loop.

Better still, the errors are phrased in the language of the domain, like "you cannot select an action before choosing a client," rather than a stack trace buried in generated code. In Joshi's words, the space of valid programs is so much smaller than the space of valid Java that the LLM has "very little room to hallucinate."

That is the entire difference between a demo that works on stage and an agent an enterprise will actually deploy. The validator is the harness. Without one, you are one weird input away from a silent, confident, wrong answer in front of a paying customer.

So is a DSL your YC F26 startup's real moat?

It can be, and here's the reframe. Everyone applying to F26 has the same models. Anthropic and OpenAI ship the weights to you and your competitor on the same day. What they don't ship is your domain's language and the validator that makes an agent reliable inside it. That constrained interface, the vocabulary of your customer's world plus the checker that rejects anything invalid, is something a generic ChatGPT wrapper cannot clone in a weekend, because building it requires actually understanding the domain.

Joshi splits the LLM's job into two phases, and both map onto what YC looks for in a team.

Phase one: you design the language

This is where founder insight lives. The LLM is a useful brainstorming partner, but you own the decisions about what your domain's concepts, operations, and constraints actually are. Those decisions can't be fully specified up front; you discover them by building. That hard-won judgment is your unfair advantage, and it's the opposite of a prompt anyone can copy.

Phase two: the LLM becomes a natural-language interface

Once the DSL exists, a plain-English request maps almost directly onto valid, checkable output. That's your product's magic moment, and it feels like magic precisely because the harness underneath it is quietly rejecting everything that doesn't compile.

Which YC companies are already selling "reliable"?

Reliability is fundable, and YC is funding it. Langfuse (YC) is an open-source LLM engineering platform for traces, evals, and prompt management, a whole company built on the premise that shipping LLM software dependably is hard enough to pay for. Chatter (YC) pitches itself as "Postman for LLMs," letting teams test prompts across model families against fixed test cases. Sepal AI (YC) turns eval and training-data generation into something automated and standardized, and counts Fortune 500s and top research labs as paying customers.

None of these is a model company. They exist because the gap between "the model can do it" and "the model does it reliably, every time, provably" is exactly where durable businesses are being built right now.

The honest caveat, before a partner says it for you

Joshi is careful, and you should be too. A DSL is not a one-size-fits-all solution. It carries a real upfront cost to design and maintain, and the payoff only appears when the language stays small and genuinely constrained, backed by a validator. If your domain doesn't have that shape, forcing a DSL onto it is over-engineering, and a YC partner will smell it in the first two minutes.

The point for your F26 application is not "we built a DSL because it's clever." It's "our agent is reliable because we constrained it to the exact operations our customers need, and here's the validator that proves it."

What to show in the 10-minute interview

Don't demo the happy path. Demo the recovery: show your agent generating something invalid, catching it against your validator, and fixing itself. That self-correction is the reliability story partners remember.

Name the space you shrank. "We don't let the model write arbitrary code; it writes our language, and anything invalid can't compile" is a sentence that lands.

Explain why a wrapper can't catch you. If a competitor could reproduce your reliability by prompting GPT a little better, you don't have a moat yet. If reproducing it requires understanding your domain deeply enough to design its language, you might.

There's a neat parallel between Joshi's argument and the YC application itself. A generic, free-form answer gives a reader endless room to find the flaw. A tight, constrained answer, the exact metric, the specific insight, the one sentence that proves you understand your domain, leaves almost no room to hallucinate a reason to say no. The best applications are a kind of DSL for your startup: dense, precise, and hard to poke holes in.

That's the tightening YC Roaster's alumni reviewers do. They read your F26 application the way a partner will, hunting for the loose, generic sentence that invites a "no," and they tell you exactly where to constrain it. F26 applications close July 27. Shrink the space for doubt before someone else finds it.