Naive question: why do we care about programming languages when we no longer read programming languages directly? Shouldn't we either design languages optimized for LLMs? (needs fewer tokens, easier for bots to process, easier to machine verify, not sure what else)
We do still read code. Most people are not doing a fully unseen development strategy because we have needs around efficiency, security, compliance etc and we can’t simply blame it on our agents like we don’t control them like OpenAI do
Relevant Calvin & Hobbes strip:<p><a href="https://static0.cbrimages.com/wordpress/wp-content/uploads/2025/05/calvin-and-hobbes-way-ahead-of-his-time.jpg" rel="nofollow">https://static0.cbrimages.com/wordpress/wp-content/uploads/2...</a>
We might still read them, but let’s set that aside. Some languages may offer ways to eliminate entire classes of bugs. Gleam and Haskell-ish languages do that through very strong type systems and expressive high-level functional constructs. Rust similarly eliminates a ton of memory errors through its borrow checker. LLMs aren’t infallible, so this can result in better quality code (or if you believe every bug will still be caught…less code to do it).<p>Gleam also runs on BEAM, which has important runtime characteristics vs other languages. That will impact your system and how it scales even if you never look at the code.
I mean, even if you've stopped even reading code (good luck with that), the right abstraction should make things things easier for the LLM. A good rich type system to stop incorrect code, linters to catch common errors. A good set of battery-included system libraries. BEAM should provide a good abstraction for highly parallel and distributed systems, which means the LLM doesn't need to build all those abstractions itself. If you're building a distributed system, it should be like providing a set of good guardrails, guiding the LLM in building a correct system.<p>I've seen even the best models try to build & debug parallel and distributed systems. The results are always a bit uneven at best, even with a good harness and a lot of guidance.<p>The disadvantage of niche languages is that the LLM won't quite know the language as well due to less training data being available. But if you actually need to build something distributed, then this might be a good trade-off.
Who's this "we" you speak about. There is a small subset of programmers who have become effectively become managers and ask their AI employees to do things. The rest of us still regularly read and write code.
I’d love to see some numbers on this, but this is not my impression from the communities I participate in (such as the Elixir forum.). Amongst programmers who are employed, I suspect it is a majority at this point who use agents to write code. It is hopefully a small minority who never read code, but it’s certainly growing.
Even in an AI intensive workflow, reading code remains a huge quality gate and I'd be wary of any software which hasn't been reviewed by humans.<p>Moreover, to me coding carefully is still a hobby, a pleasure, a craft. Gleam is exactly the kind of language that makes this such a pleasant activity.
I'd make two cases:<p>1. In a lot of cases, even if you're pure vibecoding and not reviewing any code, its still useful to <i>be able to read it</i> - you can then verify and reason about various aspects. LLMs are often flat out wrong on niche issues of performance etc, so for cases like this, not being able to read code is a big risk.<p>2. "Languages optimized for LLMs" sounds awesome, but so far, to me at least, it seems like LLMs work best in the same situations as humans- good test coverage, low-complexity, clean architecture, etc.
For what it's worth, I still parse code changes and feel uncomfortable if I struggle to understand code output without assistance.<p>On the "languages for LLMs front", isn't that a bit "cart-before-horse"? Doubt we are anywhere near the limit of what a model could do with a static verifiable language, even more so since stuff like TS has massive training data, any new language wouldn't benefit in such a way.<p>Add to that, I'd rather be able to understand the output, partly for aforementioned reasons, partly because we have seen with post Spud GPT reasoning/summarisation issues what happens when being able to read model output becomes even slightly harder. Having model-focused languages would only exacerbate such issues.<p>Also, absolutely not a Maths expert so take this for an utter layman regurgitating of what I have read, but apparently the Lean proofs by OpenAI are very hard to parse even for the experts in the field, lovingly called "Clanker Proofs", even when they are valid.<p>Having not just correctness but also human understanding as a goal has merit, so there is that to consider too. Rather models get more efficient at using what we have (and can understand+maintain as humans if need be) then make it more opaque.
> why do we care about programming languages when we no longer read programming languages directly?<p>Because, we do?<p>You may not, which is fine. A lot of developers may not... that's fine. I guess you're all employed and don't risk your livelihood when things go wrong.<p>I do though. I take responsibility.<p>And just like with any junior developer I guide AI and I do review what it creates in the project that matter. (Personal tools I've entirely vibe-coded, never any client projects though)