Imagine if 94% of your compilation errors just … vanished. Your skin would clear. The laundry would be folded. ✨ A new study shows that’s exactly the percentage of LLM errors that are just type-check failures. Cassidy Williams explains why AI is settling the "typed vs. untyped" debate. ⬇️ https://lnkd.in/dw64HmUp
The Typed vs Untyped debate is now purely an economic calculation. In an aiAssisted workflow, the bottleneck shifts from writing code to verifying code. Static types provide an automated, zeroCost audit layer at the compilation step. Choosing a dynamic language for AI generation increases the cost of verification and the risk of hallucinated object structures. In terms of Ops efficiency, strict typing is the only logical choice
This is usually due to programming in Python 3, as it produces errors just like other programming languages. I'm sorry, I only finished Java, and it's the most complete; it only fell out of use due to a lack of talent and jobs in this field. It's interesting how AI can be added to create an operating system in something like Firebase Studio, a mini sandbox with minimal capacity to recompile something as valuable as a new and 100% functional operating system.
LLMs don’t struggle with code because they “hallucinate” — they struggle because most code hides intent. Dynamic types + mutable state force the model to guess. Strong types and FP make intent explicit, which is much easier for an LLM to reason about. The next step after AI-written code and unit tests isn’t better testing — it’s proofs. Type-level guarantees and formal correctness, not tests derived from an implementation. Lean 4 feels less like academia and more like a preview of where AI-driven coding is heading. I’m working on Lean 4 learning resources for working SWEs — happy to share early versions if there’s interest 👇
It's not just about compilation errors, but proper linting in general. A well-configured linting setup gives your coding agent invaluable information to improve code (which is really just improving LLM performance with reflection with external feedback). The article mentions TypeScript, but lots of the TypeScript code that LLMs have learned from doesn't follow best practices. More often than not, generated TypeScript code will use 'any' to disable type checking altogether. That's problematic, and the compiler won't catch it as an error. That's where linting, especially ESLint, when properly configured, provides excellent insight to the coding agent. Finally, there's something really interesting to consider: coding agents within an IDE vs. CLI (or web, like Claude Code on the web). When agents run from within an IDE, they generally access data directly from the problems tab, which is generated by IDE extensions automatically. When running outside of an IDE, it's important to explicitly instruct your agent to run linting and incorporate that feedback. Using coding agents actually forced me to improve my linting configurations.
GitHub Cassidy Williams This data is a reality check. I’ve always felt that in an AI-assisted workflow, the bottleneck shifts from writing code to verifying it. When 94% of errors are type-failures, it shows we’re often asking LLMs to write 'Logic' while they’re busy writing 'Prose.' For me, strict typing has become a Semantic Contract. It turns the compiler into a real-time 'Logical Linter' that keeps the AI within the system's guardrails. It’s not just about catching bugs anymore; it’s about giving the AI a blueprint so it stops guessing and starts proving. Type safety might just be the most scalable 'unit test' we have right now.
I’ve been working on a new open-source core called SafeChange. It’s a state-invariant execution engine that allows AI systems to safely modify and evolve software without ever creating invalid or broken states. Instead of letting AI edit code directly, all changes go through: Propose → Validate → Commit → Timeline This makes AI-driven refactoring, no-code platforms, and autonomous software safe to run in production. GitHub (open source): https://github.com/jaityagi11/safechange-core I would really value feedback from anyone building AI developer tools, infrastructure, or large-scale systems.
Not sure if javascript vs typescript was ever a debate. I feel the only reason people default to javascript is not willing to learn typescript. Once I learned typescript I don’t think there were any projects, besides a quick snippet on a webpage here and there, I would rather use javascript. It is still a very fun language to use and the peace of mind types bring are such an asset! The fact AI is really good at it is an additional plus! Very little runtime errors indeed!
What other compilation errors are there? Well if it was just randomized junk it would be syntax errors. A tier up is these kind of errors. Above that you have logical errors. The code compiles but it does the wrong thing or contains bugs. These are impossible to catch with a type system.
Completely agree. The main issue right now is that LLMs often try to work around typing issues. Sometimes I can fix them with rules, but more often I end up having to double-check and explicitly ask them not to disable the checks 😅. Hopefully this will improve soon.
I've been a Python fanboy most of my career but have started using TypeScript a lot more specifically because of what this post talks about. Hard to ignore the gains you get from reliability/ safety using typed languages. (I still have a soft spot for Python ... )