Can AI Un-Slop Itself?
The author embarked on a six-month journey to build a memory-safe programming language using LLMs, only to discover that the AI-generated code was fundamentally flawed and often untrustworthy. Despite attempts to have the LLMs fix their own mistakes, the results were consistently unreliable, leading to a crisis of confidence in AI-generated code. To address this, the author turned to building custom tooling with the help of LLMs to improve code quality and trustworthiness.
- ▪The author developed a programming language and runtime using LLMs, but the resulting system lacked a MIR-pass, undermining its memory safety guarantees.
- ▪The LLMs repeatedly claimed to have fixed critical issues, but the code continued to exhibit memory leaks, segfaults, and thread-safety problems.
- ▪Custom tooling was created with LLM assistance to monitor code quality, as standard Ruby tools were insufficient for detecting AI-induced code inconsistencies.
- ▪LLMs frequently introduced redundant or incomplete code patterns, such as leaving behind unused systems or making inconsistent data type choices.
- ▪The author concluded that blind trust in LLMs is untenable, but that LLMs can still be valuable if used with robust verification mechanisms.
Opening excerpt (first ~120 words) tap to expand
Can AI Un-Slop Itself? Everyone knows that LLMs can, at least, sometimes create slop. The interesting question isn’t whether they can create slop. It’s: can they un-slop themselves? Problem I dreamed of a programming language for 10 years. After Gemini 3.1-pro, I figured LLMs were good enough that I should at least finally see what this AI "vibe-coding" craze was all about. I set on a 6-month journey to build a programming language. Within 2-months, I had a custom runtime built in Zig "competitive" with Go & Tokio. Within 3-months, I had an Affine Ownership-based "memory safe" language like Rust - but (in my opinion) much more intuitive.
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at GitHub.