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

That is like arguing everyone should master Assembly when using high level languages. :)

For one thing, who said “everyone”?

We do still read code. => We do still read Assembly code in the world of compilers.

Deterministic vs None-Deterministic

Heck, OpenAI can't even get their models to reliably do what they intend, so yeah.

AOT without PGO, manual memory management, traditional optimisations vs AOT with PGO, JIT, tracing GC, machine learning optimisation passes.

Which have what to do with the relationship between the assembly and the higher level language?

It is the answer to you Deterministic vs None-Deterministic.

If you don't get the difference, I get there isn't much that you know about how instruction selection works, across all those approaches.

Ok, I feel you know what this is actually about, but here spelled out:

Do any of the optimizations you mentioned affect the underlying behavior of the run code? Does the source ever lead to a different observable behavior? If not, it doesn't fit to LLM use, where this is very much the case.

There is the observable behaviour, and the machine code instructions that actually get generated in every single case for the same kind of text input.

Which for example, unless you can exactly replicate the world every single time a PGO data gathering session is done, there are no guarantees that the compiler will generate exactly the same machine code pattern, when given various PGO files generated at different occurrences.

Thanks, yes. To get back to the "We do still read Assembly code in the world of compilers" analogy, in the case of LLM usage, the observable behaviour is...

Assembly naturally,

https://www.phoronix.com/news/Frame-X11-Server-Assembly

Not seeing it. “We do still read code” implies neither that every single person does, nor that they need to master the language being read. Taken together, it sems to me that you need a fair bit of extrapolation to make the analogy work.

Which tangentially brings up another analogy: many high level languages don’t compile directly to assembly but to an intermediate language first (LLVM). We don’t read the LLVM code ourselves.

But LLVM compilation is deterministic. LLM code gen isn’t.

Only when not used alongside PGO data or as a JIT, as its inputs are not deterministic in first place.

No it isn’t. I think you read into my comment too much.

I don't want to say what people should and shouldn't do, and a world in which all the world's professionals spend their days talking to sycophantic machines with only a loose commitment to the truth is really funny to me.

But, high level languages don't really lose precision in any way that matters (except when you need extreme performance, resistance to timing attacks, or niche stuff like that). Natural language on the other hand loses precision that's usually important, so I don't see how your comparison is valid.

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.

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.

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.

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.

Relevant Calvin & Hobbes strip:

https://static0.cbrimages.com/wordpress/wp-content/uploads/2...

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).

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.

For what it's worth, I still parse code changes and feel uncomfortable if I struggle to understand code output without assistance.

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.

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 traces what happens when being able to read model output becomes even slightly harder. Having model-focused languages would only exacerbate such issues.

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.

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.

[delayed]

> why do we care about programming languages when we no longer read programming languages directly?

Because, we do?

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.

I do though. I take responsibility.

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)