{"slug": "fight-fire-with-pedantry", "title": "Fight Fire with Pedantry", "summary": "A blog post proposes designing programming languages specifically for LLMs by adding extreme friction and guardrails that humans would find intolerable, such as forbidding variable shadowing, enforcing strict naming conventions, and requiring extensive documentation. The author argues that as LLMs become more powerful, they can power through messy code, so languages should lean into selective friction to enforce good practices. The post suggests that these empirical ideas are now testable with LLMs.", "body_md": "# Fight fire with pedantry\n\n##\nFebruary 22, 2026\n\nOver the last two years, I’ve heard a bunch of speculation about how to design a programming language specifically for an LLM. It usually centers around typechecking, formal verifiability, or context engineering. It’s a fun thought experiment, but always felt aimless.\n\nFirst, my experience has been that designing for humans is the best way to design for an LLM, as long as you restrict yourself to text. Second, being in-distribution is so critical that there’s no point unless you’re also training a frontier coding model. And in that case, what are you doing designing a programming language?\n\nBut a suggestive [post by Terence Tao about AI slop in mathematics](https://inuh.net/@tao@mathstodon.xyz/116117405232069678) offers a rich framework for thinking about this.\n\nOne possible solution is to introduce\n\nselective friction, making it harder (or less convenient) to publish a mediocre AI-generated idea than a promising one. One can see this philosophy in the design of programming languages, which often tend to promote a certain set of “good” programming practices by making them easy to implement in the language, while “bad” practices, while not completely prohibited, are made to be inconvenient to adopt in that language. [Many] selective friction features of programming languages are in the process of being erased by the powerful coding abilities of modern AI.\n\nAt its best, selective friction embeds hard-won wisdom, born of observing the long term consequences of engineering decisions at scale. It drives engineers towards better designs, left of boom. (Or more commonly, in the case of technical debt, left of a giant whimper.)\n\nThis selective friction was designed with humans in mind. But humans are significantly more responsive to effort gradients and to cultural norms than coding agents.\n\nAs models get more powerful, they will become *more* capable of powering through messes, which may further exacerbate this problem. This mirrors a problem that some very smart humans have: They are so good at explaining away inconvenient facts that they take longer to accept that they are wrong. Doing RL with extremely long time horizons–the evolution and maintenance of an entire codebase, not individual tasks–might result in models that don’t benefit from nudges from their language. But I’m not holding my breath.\n\nDesigning a programming language for an LLM might mean recognizing this trend and leaning into it hard by cranking the coefficient of friction way past 11.\n\nProgramming languages designed for humans have upper limits to what they can require, on pain of being too annoying to use. LLMs will power through requirements that humans find intolerable, so we can ask more of them.\n\nHere are some ideas:\n\n- It could forbid variable shadowing. In the extreme form, all code must be in SSA form.\n- It could enforce extremely strict naming conventions, in the interest of increasing local information density.\n- It could require docs on absolutely everything.\n- It could support extensive compiler-checked pre- and post-conditions.\n- It could require annotating functions as being pure (or not), as being able to panic/throw (or not), as allocating memory (or not).\n- It could limit the number of parameters to a function to three.\n- It could require that all boolean parameters be named types with associated constants.\n- It could require that every type and function be\n[in its own file](/post/perf_files/)with a predictable filename.\n\nMuch of this sounds roughly like “more typechecking” and “formal verifiability” and “designed for efficient context use”. But it does so around a unifying theme: giving up on human usability in order to add guardrails.\n\nAll of these ideas come with trade-offs, and they might not be net wins. Or they might not go far enough: The models might manage to dance around them. These are empirical questions. With the advent of LLMs, the cost of testing them is within reach.\n\nThe real point of this blog post is to open up the design space. Could an unbearably opinionated, pedantic programming language yield better agent-written code?\n\nAlso: You don’t need a new programming language for this. Start with a strongly-typed, tool-friendly language like Go or Rust and start layering on “compile-time” requirements, and see what happens. This keeps the code much more in-distribution and enables rapid prototyping.\n\nAt exe.dev, we’ve scratched the surface of this with some [vibe-coded static analysis tools hooked up to CI](/ai/vibed-static-analysis/). But I’d be curious to see what happens when someone who loves pragmatic programming languages or frameworks adopts some [deliberate naivete](https://factory.strongdm.ai), lets out their inner language lawyers, and really plumbs these depths.", "url": "https://wpnews.pro/news/fight-fire-with-pedantry", "canonical_source": "https://commaok.xyz/ai/llm-language/", "published_at": "2026-07-13 23:20:30+00:00", "updated_at": "2026-07-13 23:35:23.947659+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "ai-tools"], "entities": ["Terence Tao"], "alternates": {"html": "https://wpnews.pro/news/fight-fire-with-pedantry", "markdown": "https://wpnews.pro/news/fight-fire-with-pedantry.md", "text": "https://wpnews.pro/news/fight-fire-with-pedantry.txt", "jsonld": "https://wpnews.pro/news/fight-fire-with-pedantry.jsonld"}}