The case for statically typed languages has always rested on one premise: humans write code, humans forget function signatures, and compilers catch those mistakes before the program runs. Developer Huahai argues that premise is now outdated, and the argument holds up.
The compilation error argument no longer lands
Frontier coding models almost never stay stuck on a missing parenthesis or an incorrect primitive type. They read the compiler message and fix it in the next generation. The expensive mistakes AI makes are not compilation failures. They are misunderstandings: wrong business rule, overlooked edge case, race condition that type-checks perfectly, authorization logic that compiles but permits unauthorized access. A type checker cannot catch any of those.
Types have a token cost
In a statically typed language, a single operation can require explicit type declarations, generic parameters, interfaces or traits, lifetime annotations, error-type conversions, optional-value wrappers, data-transfer objects, serialization annotations, and adapter layers on top of all that. Each of those is an additional token the model must generate and keep consistent across the entire context window. More tokens mean more opportunities for error, not fewer.
Huahai points to a token efficiency study where Clojure, a dynamic language, ranked as the most token-efficient language tested.

What this means for your stack decisions
Types still have legitimate uses: documenting interfaces, defining module boundaries, and encoding genuine domain constraints like “a cancelled transaction cannot be settled again.” The argument is not that types are worthless. It’s that the cost-benefit calculation has shifted. The old benefit (catching human syntax and type errors) is shrinking. The token cost is not. If you are choosing a language for an AI-heavy project, that tradeoff is worth pricing in honestly.
