Comment by nickm12
9 hours ago
I send this article to everyone who tells me how English is now a high-level programming language, the next level of abstraction up the chain from machine language to <their favorite language>. This analogy tends to be followed by "Just like most programmers never look at assembly code, looking at higher-level source code is going to become something only a few people do".
Dijkstra's arguments tend not to change their minds. I think the analogy takes hold because there is a kernel of truth in it. AI models now give us the magical ability to program in natural language, but the implication that an AI model is a form of compiler is deeply flawed. AI models don't replace compilers, they replace software developers. 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.
A natural language spec is not a program, and there are many possible programs that can meet the spec. Software engineers and AI models turn specs into code, but the code is not the spec I think the analogy clouds our thinking about the value of programming languages as a tool for formally describing what the computer should do and enforcing properties of the program that should not be left to either humans or AI models to uphold.
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.
If AI is natural language programming then they already had it in 1978, because AI is in fact "asking a programmer to write code for you". And you can even ask them to do it at different levels of abstraction!
It's the same as "natural language bricklaying" where you make walls appear by speaking instructions to a brickie whom you're paying.
>If AI is natural language programming then they already had it in 1978, because AI is in fact "asking a programmer to write code for you"
That would just be the "I" part, since was missing the A for artificial: you asked a naturally made person.
And yes, nobody argued that they didn't have I in 1978, so I'm not sure what the argument is supposed to prove.
The latter is also very far from specifying a calculator. And based on what we see in the "Show HN" projects, also very far from what the average person process is of using AI for generating software.
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.
As I said, "AI models don't replace compilers, they replace software developers" so yes, I agree that AI models are like humans.
while both LLMs and humans are not 100% deterministic, I don't think that's the interesting part. It's both true that there are many assembly language programs that implement a C program and that there are many valid programs (in any programming language) that correctly implement a natural language spec. But there's a significant qualitative difference between the two types of translation and that would be true regardless of whether the translations are stochastic.
The stement to which we are replying will (has?) launched a 1000 startups.
It would be interesting to state sane measurments that determine a "distance" between a spec and software that claims to implement it
I would argue the distribution is wider among humans than among agents.
Please go ahead and do.
> Two engineers convert specs to code in two different ways
So? Two compilers convert source to binary in two different ways.
The same compiler will convert source to binary in different ways! Hermetic builds are hard!
Even if we allow for hermetic builds in some cases in many many other cases your runtime will recompile your code based on its observations about your environment and that’s frequently what we want.
This fetishism of “determinism” seems crazy to anyone that has had to spend time really digging into modern JIT based compilation.
Arguing that two humans' distinct interpretations of a single specification is stochastic is patently absurd and requires, I think, some shred of evidence.
I would argue that, in the absence of such evidence, we cannot conclude that the English-to-code conversion process is stochastic; it is merely not deterministic, which is altogether different.
Would they write the same code, if given the same spec? No? How about over multiple trials? No? Even the individuals' own code would differ from one trial to the next?
Well, then, their interpretations of the spec are stochastic. Good enough for me, anyway.
1 reply →
> 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.
Is that not what software engineers do?
It is, but software engineers have a much broader understanding of the problem, they also ask questions, and if they are good, they ask the right questions, something LLMs still have a problem with.
Personal example of what LLMs can't do, but I could: I made a script to update some version numbers in some files, based on some other files. Simple stuff, and one of my colleagues told me "ask the AI, it will take 5 minutes". Well, no, because the files sit on different machines, and extracting the files from one machine and putting the result on the other machine requires knowledge of the infrastructure. Again, simple stuff, but the AI doesn't know, and we certainly are not going to let it run wild in our network. I know all this because I talked to the team, attended meetings, and did a bit of careful exploration. I am trusted with resources to do my work in a way the AI doesn't, I am sure it is mostly because I can take the blame me if I misuse them.
I recently vibe coded an application fully and tested it with users. So all the functional requirements were there.
Guess what wasn’t?
The nonfunctional requirements.
Also: my app needs to do LLM classification. But instead sometimes the coding assistant wrote not an LLM api call but it wrote a regex to classify instead. This was despite the fact that I mentioned to not use regexes to classify things with.
Non-technical people don’t know what a regex is. Usually they also aren’t knowledgeable enough about nonfunctional requirements.
All of this may improve over time of course. But right now, I am not impressed (in terms of replacing SWEs).
4 replies →
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
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.
Why do compilers worry about the challenge? Just call an LLM internally from a compiler if LLMs are better than compilers.
In my opinion, LLMs don't challenge anything.
>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.
> 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.
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.
How do you check, from examining behavior alone, that the code does not contain stuff like this:
if (date == <some random future date>) { crash_and_burn_the_world() }
??
You just get an agent to look for traps.
I actually found code exactly like that would break a test on a certain date, using an agent.
It's really good at flagging things like this, which tend to be leftovers from a human process that nobody has had the time to clean.
How do you do that with a human team? Trust?
1 reply →
If you like being a software tester or director, go ahead with it.
However you can't prevent some other people from working as software developers who write and read code.
Even with cars, you still walk. Even with factories, someone still craft handmade bags.
I can't prevent them, and in fact, I don't want to. Didn't mean to imply that.