Source linked

TypeScript's Unsound Type System Is a Liability When AI Writes Your Code

iankduncan.com@proud_leopard2 hours ago·Developer Tools·3 comments

Ian Duncan argues that TypeScript's deliberate unsoundness makes it a poor default for AI-generated code, because the compiler cannot catch subtle errors that LLMs produce at speed.

typescriptllmsprogramming languagesian duncanblub paradoxai code generation

TypeScript's type system is unsound by design, and that design choice becomes a critical liability when large language models are generating the majority of your codebase.

The Blub Paradox Revisited

Twenty-five years ago Paul Graham wrote that your choice of language is a competitive weapon. His Blub paradox: a programmer fluent in a middling language can recognize everything less powerful than what they use but cannot see what's more powerful. From inside Blub, the more expressive language just looks weird and unnecessary.

Ian Duncan argues we are relearning this lesson, except the pressure now is AI. The new Blub, the agreed-upon reasonable middle, is TypeScript. The pitch is seductive: LLMs are spectacular at TypeScript because they have digested every line on GitHub. You get types, a sense of discipline, and fluent autocomplete. Why reach for something more exotic? Because TypeScript is the worst of both worlds in exactly the dimension that now matters most.

Unsound by Design: A Feature That Becomes a Bug

TypeScript's unsoundness is not a bug or an unfinished corner. It is a stated goal. The team chose to permit type errors at runtime in exchange for pragmatism and JavaScript compatibility. as casts launder lies past the checker. any is a hole straight through the floor, and it is contagious. Array indexing hands you back a T while cheerfully returning undefined at runtime. Objects have more keys than their types admit, and may not have the stated keys depending on provenance.

Now put that in a world where machines generate large volumes of plausible code you did not write and will not fully read. What is actually catching the model's mistakes? In a sound type system, a large fraction of plausible-looking errors simply do not compile. The invariant you encoded forbids them, full stop, on every build, in seconds, without anyone getting tired. That is the cheapest and most scalable error correction you have, and its value goes up when generation speed goes up. Your reviewers and test suite do not scale with the model, but the compiler does.

Fundamentally, TypeScript gives you the appearance of machine-checked safety without the guarantee. The green checkmark from the TypeScript compiler says the generated code type-checks; then you ship to production, and the runtime says cannot read property 'x' of undefined. In a hand-written codebase you might internalize where the soft spots are. In a generated one you are trusting a checker that has formally reserved the right to be wrong, applied to code authored by something that is also allowed to be wrong. You call that combination "type-safe."

Why LLMs Thrive on TypeScript's Escape Hatches

Current LLMs are extremely good at producing TypeScript that type-checks and is subtly wrong, because the training corpus is saturated with exactly that. They know every idiom for satisfying the checker, including the escape hatches. Ask for something tricky and watch how readily an as unknown as T or a stray any appears to make the red squiggle go away. LLMs have learned that the goal is a passing tsc, and TypeScript has provided a rich vocabulary for passing tsc without writing correct code. You get a confident generator of code that clears a bar specifically designed to be clearable without correctness.

Beyond that, TypeScript's view of any library it does not compile itself comes from a .d.ts file: a hand-written claim about JavaScript that nothing checks against the actual code. It is a type annotation with no implementation tethering it to reality, frequently authored by someone who isn't the library's author, for a version that has since changed.

Duncan is not arguing against using TypeScript where it genuinely fits: browser frontends, teams already embedded in its ecosystem, or library dependencies that demand it. His quarrel is with making it the unexamined default for everything on the strength of "the AI likes it." Teams defaulting to TypeScript because LLMs produce it fluently might want to reconsider before their green checkmarks become a false sense of security.


Source: The New Blub Paradox, or: Why TypeScript Is a Poor Choice for the AI Era
Domain: iankduncan.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.