Your acquaintances aren't changing their minds because the arguments are weak. Both the article and your comment assume that the only mode of interaction for natural language is a very high level description of programmer intent.

You can interact with AI and say "code me a calculator" or "now declare a array of booleans to map to each of the keys in the UI and set the corresponding array position to true when the key is pressed".

These commands are written in natural language at such different levels of abstraction that is hard to put them in the same bucket. It would be fair to call the latter an imperative language with the LLM in the role of a compiler. That's very similar to how I use AI.

> AI models don't replace compilers, they replace software developers.

No, they replace the need for a precise description of what you want the computer to do by a mechanism that's really good to fill in the gaps. But guesswork only takes you so far.

You mean the English to code layer is stochastic while code to assembly is not?

This stochastic nature existed before AI. Humans are stochastic too. Two engineers convert specs to code in two different ways. I would argue the distribution is wider among humans than among agents.

The LLMs don't replace compilers, they challenge the next generation of compilers. And they don't replace software engineers, they shift them into yet another metasystem.

I think this might be a false dichotomy, because for instance, I think LLMs are programmable in natural language, and they act as compilers, I even think they can replace programmers; but still I agree with Dijkstra, that programming in natural language is a bad idea.

But I am going in an opposite direction. Instead of rejecting formal languages in favor of natural ones, I think we should embrace formalism even on the level of specifications, requirements and our model of the world. Partly because that's what LLMs actually do - they de facto formalize these things.

> AI models don't replace compilers, they replace software developers

No, what agents do is expand the scope of problems software developers can solve. It is no different than the introduction of compilers, type checkers, garbage collection, and so forth. A programmer in the 1950s could not have imagined how anyone could build a software system like Hacker News, let alone the complex software systems we basically take for granted in this century. It is hard to imagine what kind of software future generations will take for granted because of how much more power programmers will have with things like agents (and whatever comes next -- this is hardly the end of the story).

It is all about definitions. Writing instructions for llms is a new activity and we can call it as we wish - but I like to think about it as a new type of programming language instead of thinking about it as something completely new, because many analogies do transfer and you can use them to reason about larger systems composed of prompts. It is after all a way to instruct a machine.

There are differences and the article highlights some of them - but there are difference between programming in a functional language and an imperative one, there are differences between programming for a RISC machine and a CISC machine, there a lots of different semantics that programming languages support. Now we have a language with underspecified semantics.

Thank you for articulating this!! This idea has been rolling around for a while but I haven't been able to put it into words.

I think "I'm working in a higher level of abstraction" is easier for some devs to say than "I asked somebody else to do the thinking and the work." I don't think there's anything wrong with asking an LLM to do the work. But pasting jira tickets into claude is not abstraction lmao.

I guess arguments on either side of this can get difficult for a reason that another commenter already mentioned: you can use LLMs on a wide spectrum of granularity. You can one-shot a whole project, or you can tell it to rename some vars in a single file. I guess there are uses that are probably closer to programming. But if you're not even looking at the code, I'd say that's closer to somebody else doing the work

It's applied to the programming language too - the given source can be compiled to unlimited number of possible machine code representations (it can different just by NOPs).

>Dijkstra's arguments tend not to change their minds.

Maybe they trust the practical results they see over what a professor wrote 50 years ago as an essay.

Agree. For me, that's exactly what happened. I work with the agents the way I'd work with a team of developers, not the way I use a compiler. Since the end of September, they've made about 970 commits to a project of mine, and I haven't read a line of its code.

And like with a team, many programs could meet what I asked for, but I check the behavior of what they built, not the code directly. I think of it as working on the level of an engineering director, who also doesn't review code directly. Each agent shows me its change running in the app, in a short narrated screen recording, like in a launch review for the director. When it's not what I meant, I say what, and it goes another round.

> The reason software developers rarely look at assembly code is that compilers (and emulators and VMs) are able to precisely preserve the semantics of the original program.

'Precisely' is doing a lot of work here. Depending on your language some things might be preserved and some not. Eg if you write stuff in Haskell, you don't really preserve much of anything about memory usage, you leave that to the runtime system to figure out, and exactly how the GC works isn't really specified in the language standard.