The Case for 'Boring' Languages in the Age of Agentic Coding
A growing technical debate is emerging around how programming language design impacts the reliability of AI coding agents. In a viral essay, engineer Jacob of Sancho Studio argues that developers should prioritize "boring" languages with highly consistent, low-variance ecosystems—most notably Go—when building with LLMs. The core theory is that languages with a single canonical way of doing things (enforced by rigid tooling like gofmt and standard libraries like net/http) produce a highly stable training corpus. This high cosine similarity in the training data allows LLMs to predict the next token far more reliably, avoiding the fragmented "options paralysis" and outdated patterns common in ecosystems like JavaScript or Python.
Jacob writes:
"Languages and ecosystems with low variance in their training corpus are represented better and executed more reliably by coding agents." — Use boring languages with LLMs
However, the Hacker News community is sharply divided on this "boring is better" thesis. A prominent counter-argument asserts that "boring" languages rely on implicit human assumptions and boilerplate, which actually compound as an AI agent modifies the codebase. Instead, these developers argue that strict, type-heavy languages with aggressive compiler guardrails (like Rust) are superior for agentic workflows. Because LLMs have an infinite tolerance for "busywork," they can easily satisfy strict type systems and borrow checkers, while the compiler itself acts as a flawless, real-time feedback loop to correct hallucinations before runtime.
One commenter argued:
"The more assumptions I can move to compile time the better models are at dealing with emerging complexity." — Comment by sheepianka
Others pointed out that the critical factor is not language ergonomics, but sheer training data volume. A technically "perfect" language designed for agents is useless if the model hasn't ingested millions of lines of it:
"I'll take a slightly sub-optimal language with excellent training data coverage of my use case over a perfect language that the models have barely seen 100% of the time." — Comment by SwellJoe