The Programming Language LLMs Can't Use: An Alternative Exploration of Anti-AI Design

In an era where AI coding assistants are becoming increasingly ubiquitous, one developer has gone against the grain by building a programming language specifically designed to be "unusable" by LLMs. This project, which sparked discussion on Hacker News, touches on deep issues surrounding programming language design, code ownership, and the boundaries of human creativity in the AI age.

A Deliberately "Anti-AI" Language

According to the project's discussion thread on Hacker News, the author's core claim is clear: he has built a programming language that LLMs cannot effectively use. The post received 23 upvotes and 19 comments—not particularly high engagement, but the topic itself is quite provocative.

The value of this project lies not in its technical complexity, but in the question it raises—one that mainstream narratives have overlooked: when the design goals of programming languages expand from "convenient for humans" to "convenient for machine generation," should someone proactively draw boundaries? The author answers with action: rather than waiting for platforms to restrict AI scraping, why not make it hard for machines to intervene at the language level?

It should be noted that the original material only provided the title and basic community discussion data, without disclosing the language's specific syntax, implementation approach, or "anti-LLM" technical mechanisms. The following analysis is based on the design intent conveyed by the title and the general trajectory of Hacker News community discussions.

esolang (esoteric programming language) is short for "esoteric programming language," referring to programming languages designed for experimentation, challenge, or artistic expression rather than practical purposes. Classic examples include Brainfuck, which has only 8 instructions; Whitespace, which encodes using spaces and tabs; and Piet, whose code resembles works of art. These languages typically deliberately violate mainstream language design principles (such as readability and maintainability) to explore the boundaries of computation and expression. Although the author's language is not explicitly positioned as an esolang, its approach of "deliberately excluding a certain class of users" is highly consistent with that tradition—esolangs typically exclude ordinary programmers, while this language excludes LLMs.

Why Would Someone Want to "Block" LLMs

Over the past two years, the capabilities of AI coding tools have expanded rapidly, moving from code completion to whole-file generation and repository-level refactoring. The developer community's attitude toward this is far from unified. Some embrace the productivity gains, while others worry about code homogenization, the hidden harvesting of training data, and the dulling of human developers' skills.

The phrase "unusable by LLMs" is essentially a declaration of design constraints. It could mean the language employs a symbol system that is difficult for tokenizers to segment, relies on context intuition unique to humans, or deliberately introduces ambiguous structures that LLMs are prone to getting wrong. Regardless of the specific approach, the goal is the same: to return the code generation process to human hands.

This line of thinking is consistent with the "anti-scraping" and "anti-training" movements that have emerged in recent years—only the battlefield has moved from the data layer to the language layer.

Tokenizer is the first step in how an LLM processes text: it segments the raw character stream into tokens (subword units) in the model's vocabulary, which are then mapped to vector inputs. Different models have different tokenizers (such as BPE and WordPiece), but they share a common reliance on character combinations that appear frequently in training corpora. If a language uses rare Unicode symbols, unconventional whitespace structures, or deliberately constructed ambiguous notation, the tokenizer may split it into inefficient or even meaningless fragments, significantly increasing the difficulty of model comprehension and generation. This is one of the possible technical leverage points for "making LLMs unable to use it"—the target of attack is not the model's reasoning ability, but its entry point for perceiving text.

Divergences in Community Discussion

Hacker News comment sections are known for their technical rigor. The typical debate surrounding this project can be grouped into two camps.

One camp sees it as a meaningful design experiment. Programming languages are inherently human-defined symbol systems, and history is full of "niche languages" (such as esolangs) born for specific purposes. A language that deliberately excludes a certain class of users and a language that deliberately serves a certain class of users are not fundamentally different in methodology.

The other camp questions its practical effectiveness. LLMs' generalization ability means that as long as a language has enough public examples, the model can learn it; and a new language that no one uses precisely lacks training data, so the short-term reason it "blocks" LLMs may simply be that it's "too obscure," rather than any insurmountable design barrier. Once the language becomes popular, the defense naturally collapses.

This rebuttal gets to the core of the issue: a language's "anti-AI" property depends largely on its popularity, not on its syntax itself.

Generalization refers to a model's ability to perform well on tasks or distributions it has not seen during training. For programming languages, this means that even if a language does not appear directly in the training data, an LLM can perform transfer reasoning by leveraging cross-language commonalities (similar syntax paradigms, keyword semantics, and control flow structures). Thus "lack of training data" does not equal "the model is completely unable to use it"—it merely means generation quality declines. This also explains the deeper logic behind the community's rebuttal: the barrier a new language puts up against LLMs is temporary and statistical; once enough public code examples appear, generalization ability will quickly fill the gap. What is truly difficult to cross are those unique semantic conventions that cannot be derived by analogy from existing languages.

Implications for the AI Programming Era

Setting aside the specific implementation, this project offers at least three angles worth considering.

First, the design space of programming languages is being redefined by AI. In the past, language designers cared about expressiveness, performance, and developer experience; now there is an additional dimension: machine readability. Some choose to optimize for it, and others choose to resist it.

Second, code ownership and training data ethics remain unsolved problems. Developers' resistance to "their code being used for training" is real, and defense at the language level is a low-cost way to express a stance.

Third, the boundaries of human creativity deserve to be actively protected. Efficiency is not the only measure of value, and preserving some domains that are "difficult for machines to enter" may not be a bad thing for the diversity of the tech ecosystem.

This project is unlikely to become a mainstream language, but it serves as a small signpost, reminding us that amid the rushing tide of AI, there are still those willing to stop and ask: does this road really have to be walkable for machines too?

One-line Summary

A developer built a programming language deliberately designed to be difficult for LLMs to use, sparking discussion about code ownership and language design boundaries in the AI era.

Paragraph Summary

A developer showcased on Hacker News a programming language specifically designed to be "unusable" by LLMs, sparking community discussion. The article analyzes the design intent: when the goals of programming language design expand from being convenient for humans to being convenient for machine generation, some choose to proactively draw boundaries. The community debate splits into two camps—one sees it as a meaningful language design experiment, while the other points out that LLMs' generalization ability means the "anti-AI" property may simply result from the language being obscure, and that once it becomes popular, the defense will collapse. The article further distills three implications: programming language design gains a new dimension of "machine readability," code ownership and training data ethics remain unsolved problems, and the boundaries of human creativity deserve active protection.