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.
> 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.
No, the article explicitly says that the difference is formal vs informal language.
> Programming remained the use of a formal symbolism and, as such, continued to require the care and accuracy required before.
One can define an operational semantics for (at least a subset of) the programming language (even for sloppy one, since they are still very small and restricted). One can prove the semantics preservation theorem formally, or reason somewhat in a similar way informally.
With natural language you kinda lose it, and we don't even touch the fact that models are probabilistic.
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!
The magic sauce in intelligence is context-awareness. If a prompt is somewhat general ("make me a calculator") an AI should either ask questions, or make reasonable assumptions, or both.
IME LLMs often make reasonable assumptions, but sometimes they don't and you have to backtrack and say "No, what I meant was..."
When the process works it's almost magical because the LLM successfully anticipates your needs, and implements your request in a much fuller way than you might have done yourself.
When it doesn't it makes a mess you have to clean up.
But generally I've been impressed by how well the leading LLMs will Do The Thing from a brief description, interpolating useful and correct details without being told to.
Compilers don't work like that. They're translators, not (entry level) inventors with independent agency.
Some compilers can do that, but only in a very controlled way. For example Haskell's deriving or inference of the correct method called on typeclass. Or the Prolog/Datalog/SQL - they will also fill in many details on how to arrive at an answer.
> I'm not sure what the argument is supposed to prove.
I’m guessing it’s supposed to show that if you have to have arbitrary levels of intelligence to interpret natural language, then nothing’s changed between now and 1978 when considering whether “natural language programming” is a thing. Just because the intelligence is artificial now doesn’t really change the answer.
>Just because the intelligence is artificial now doesn’t really change the answer.
Not only it changes the aswer, it's literally the whole of the question. When people talked of the posibility or imposibility of “natural language programming” they *always* meant "natural language instructions which *a machine* translates to running code".
They didn't have to spell it out, since nobody doubted a human programmer can write code when given natural language instructions - that was already a thing since ENIAC, if not since Ada Lovelace.
That's what we have now, and that's what changed between now and 1978 when considering whether “natural language programming” is a thing.
- You can tell an AI what to do in natural language, and it can gather requirements, sketch up a design, write code, search the web for error messages, and iterate on the program until it works.
For certain things people care about, they’re equivalent (I tell the computer what I want and out pops a program) but for certain other things, they’re absolutely not (natural language doesn’t map deterministically into machine instructions.)
When people talked about natural language programming decades ago, they were talking about a system that compiles natural language into machine code. They weren’t talking about a system that autonomously gathers requirements, decides what frameworks to use, searches the web to look up error messages, iterates on ideas, etc… these things are so different from “natural language maps to machine code” that I don’t think we’re going to have a useful discussion if you think “I tell the computer what I want” is the only aspect of this worth looking at.
>They were talking about a system that compiles natural language into machine code. They weren’t talking about a system that autonomously gathers requirements, decides what frameworks to use, searches the web to look up error messages, iterates on ideas, etc… these things are so different from “natural language maps to machine code” that I don’t think we’re going to have a useful discussion if you think “I tell the computer what I want” is the only aspect of this worth looking at.
This confuses two things still:
People wanting to have natural language to machine code via AI, just AI that was implemented the way they thought was achievable then (symbolic AI).
People wanting to have natural language style programming language, similar to later AppleScript or some 4GL languages.
Natural language programming, or natural language processing, as it was called, was tied to the first, and the AI research of the time, from the beginning:
So, yeah, they didn't have LLMs, but they pretty much understood such a program or "compiler" would need to understand world facts and natural language to even work.
> Natural language programming, or natural language processing, as it was called
NLP has nothing to do with programming. The Wikipedia article you linked doesn’t even mention programming once. NLP is old-school AI like you get when you try and cram all language into an ontology and try to “parse” it in an unambiguous way. It’s how Siri worked from the beginning, and it’s a complete dead-end. (I have some background here, I was an engineer on Siri for over 10 years.)
The fact that a compiler using old-school NLP would need a complete understanding of the world and all relevant facts in order to make natural language “process-able” is the reason the whole thing was a failure and why LLM’s are needed to make the idea work. You can’t just go from “parsing language” to “make me a TODO list app” without having an arbitrarily intelligent system to understand all the relevant background that such a statement implies.
When people realized human-level intelligence is necessary to make natural language programming work, is basically when the idea died. And now we have LLM’s and (what many would define as) human level intelligence, and its ability to program is just one side effect of many of it being truly artificially intelligent.
You misunderstood my comment - I meant that if instructing a programmer to program something is "natural language programming" (what AI agentic coding is), then they had "natural language programming" in 1978. I wasn't saying they had AI in 1978.
> 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!
There are a few little differences between human beings and computers that you should know about.
For example, humans are sentient, have agency and can be held accountable.
So when you give humans a bad spec, you can still get what you want, because, with some luck, you're simply delegating the task of thinking and making choices to another human, who, by the very premise, understands the language you are communicating in, and can work out your intents with you.
The whole "this meeting could've been an email" thing, you know.
That meeting could've been a pull request if whoever needed a thing to be done could figure it out on their own.
LLMs can be helpful for figuring things out, sure.
But "sudo make me a sandwich" style of vibe coding is just removing the obstacles to enshrining ambiguities and bad decisions in code.
>But "sudo make me a sandwich" style of vibe coding is just removing the obstacles to enshrining ambiguities and bad decisions in code.
I'm of the opinion that if you think it will stay this way you haven't been paying attention. "sudo find me a security flaw" already embarrasses top security researchers who have been working on the same code for decades. "sudo decompile this program/firmware/game" is doing absolute wondrous things right now even if there are still some flaws. If it can do these things better / significantly faster than humans already, and if it keeps improving at the rate it has been "sudo make me an operating system" that spits out something actually pretty good is probably within a decade.
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 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
And if the latter is guaranteed to be interpreted unambiguously...
...Congratulations!
You have invented a programming language!
But now, that requires 20x more typing and 1,000,000x more compute to compile to machine code.
> 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.
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).
I think the point is that it doesn't "just work" of you don't know what you are doing.
In general I got the feeling that AI saves a lot of work, avoids a lot of big category, but also introduces new but categories that you need to account for.
>Guess what wasn’t? The nonfunctional requirements.
OK, so you test it, see which nonfunctional requirements it doesn't meet, and ask the AI to change the code to include them - repeat until you're happy.
Yep and then you'll have some war stories how things break in production because they weren't initially included in the nonfunctional requirements. Have enough of these war stories and you'll basically be a software engineer. Albeit, a software engineer that has never coded before, but definitely someone who understands production issues.
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.
> they also ask questions, and if they are good, they ask the right questions, something LLMs still have a problem with.
Sure, but LLMs do ask some questions already, and there is no reason to think they can’t keep getting better at knowing the right questions to ask.
Humans also often fail to do this well, and I think we all have experience with developers who do a very poor job at understanding what is actually being asked of them.
Maybe LLMs will never become as good as an expert developer at being able to suss out what someone is actually trying to do when they make a request, but it is certain LLMs will become better at it, and there is no reason to currently believe they couldn’t eventually become as good as the best humans eventually.
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.
"Time flies like an arrow" is a valid English sentence that one person can find numerous ways to interpret. A programming language that has the kind of ambiguous syntax that natural languages have would not be useful.
What makes agents useful is not simply that they interpret natural language, it is that they are interactive and ambiguous instructions can be corrected when the agent's output is not what the programmer intended. That is not the same as writing out a spec and giving it to a developer to implement.
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.
lol I saw the exact same JIT non determinism argument on reddit. The thing is, if JIT cannot replace a hotspot with a 100 percent functionally identical snippet of code then the JIT is just in time wrong and will be either patched, repaired or orphaned.
So all of a sudden all focus is on the word "determinism", and before even going down this route you have to agree on what aspect of the subject are you declaring to be "deterministic?"
Its sort of like chatting with libertarians, as soon as you agree that taxation is theft and democracy is tyranny then all problems melt away!
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.
The term 'stochastic' refers to characteristics or properties that are measured and/or understood on a statistical basis rather than on an individual basis, because they are driven or biased by random processes. What's your understanding of the term, if you're not working from a widely-accepted definition?
Two people interpreting a specification in different ways isn't stochastic because human processing is not a statistical process in any meaningful way. Or, to put it another way: given a specification, you could not reasonably enumerate all the ways two humans might interpret it, much less assign statistical likelihood to those outputs.
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.
The LLMs use compilers, so I am not seeing the challenge here. Compilers do a lot of useful and important things like type checking and agents will typically check their output by invoking a compiler, then correcting errors reported by the compiler.
If anything what agents will mean is a move toward compilers for languages with more expressive type systems that can do more static checks for semantic correctness e.g. F*, which is an extension of F# that introduces dependent types.
I think you're missing my point which is more or less that compilers are these original harness and will continue to anchor human-computer interaction as they have always done.
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.
It is something completely new and we should be thinking about it as such. Analogies can help us here, and I think the analogy of "instructing a software team" is a much more useful analogy than "instructing a compiler" and the latter clouds our thinking.
> 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).
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.
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
You're welcome! I'm struggling with when and how to look at the code and what really matters now. I personally work across multiple codebases that each have teams of 5-7 developers, so someone else was always doing the work and I personally never could read or understand all the code.
What I want to preserve in the AI-code-gen age that I still can form a high-level "theory of the program" and be able to dive deep and understand parts of it, both with and without AI. I'm concerned that we're headed towards a world where it's not possible to understand or modify even the simplest programs without a swarm of agents that you direct with incantation.md files.
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).
Yes, definitely. And the same program can run on completely different architectures. But it has a well-defined semantics that must be preserved by the compiler or runtime.
I'm not saying it's all mathematical purity. Programming languages themselves have specs and sometimes they are ambiguous or allow undefined behavior. Compilers have bugs. But the gap between the source code and program behavior is typically extremely thin and language implementations work towards making it airtight.
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.
I agree. I work in a similar way, and it is quite like managing developers. One difference though: I have no compunction against asking them to write incredibly tedious and long end-to-end tests exercising the user journeys with playwright and an actual db and backend. That helps a lot in making it more likely that regressions will not happen.
Haha, well, I don't because I have no reason to assume this is in the code. In fact, I have reason to assume it is not in the code because the models aren't trained to produce this.
Could there be a less egregious version of that in the code? Sure, but then that's just a normal bug where implementation doesn't match intention, and that happens to human developers as well. I find that Opus 5.5 is so good that it writes pretty good code that follows YAGNI, KISS, DRY, and is fine with writing a lot of tests, so my sense is that the rate of normal bugs is actually lower than with human developers.
Now, if you're assuming malintent on the side of the model creators, well, that's another story. FWIW, in a commercial project, where I also work at the "engineering director level" since Opus 5.5, all non-trivial changes go through reviews by Codex and Grok (locally) and Greptile (on the PR), so there would have to be some serious level of collusion by the labs to produce your example ;)
Well, I just used a contrived example to illustrate my point.
You would be well served to review the code. I don't usually need to do much of that since I work with models edit by edit, with every single line they write approved by me.
You would be surprised at all the errors even Claude Opus 5.5 commits. Not syntax or even basic logic errors, but more insidious errors that betray a lack of being able to see the bigger picture, or serious architectural errors.
If you want example, I have them in abundance. These models still need serious supervision. Unless you are spot checking the code deeply, you won't notice.
"I work with models edit by edit" – That could be the cause of bias: Maybe because you're supervising small step iterations of the model, you notice issues that the model would have noticed itself if you had let it tackle a larger scope by itself. Worth a try in my experience. And the extra review agents make a big difference. Even if it's Opus reviewing Opus. Just by having a fresh context window, the model finds issues it created itself in another session. And with a different model, you get yet another fresh perspective. I find Codex is particularly thorough in reviews.
How do I know? It several times present deep architectural decisions to me, where each options may seem plausibly good. I rely on my deep architectural knowledge and experience, and knowledge of my vision for the product to steer it to the right option.
If you are checking every line written by an LLM , what would you estimate is the probability it would ever do this?? I look at most code still and I have a high level of trust that it would never do anything remotely similar to this.
"trust" and "responsibility" mean nothing for a fully digital entity who isn't required to feed its family, looking for an eventual new job, and being under pressure for not being fired
Code review, style guides, and a large set of tools like fuzzers that try to check for bad behavior before the code makes it into production. At least that's how it is done where I work and the use of agents to write code has not obviated the need for such a process (in fact we have added agents to that large set of tools and seen improvements in code quality as a result).
> 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.
If a compiler doesn't preserve the semantics of the program, that's a bug in the compiler. Programs in GCed languages mostly don't describe the behavior of how memory is managed and that is left to the compiler and runtime.
Your two sentences contradict each other. Programming languages decide what parts of the programme behaviour they want to specify, and what they leave to the implementation.
Of course, you can redefine what 'semantics' means to say it's the kind of stuff that should be preserved in a translation. But as I said, different languages care about specifying and preserving different things.
See also how most languages (or their specs) don't particularly care about letting the user specify exact timings of operations.
I think this essay has aged pretty well and remains pretty spot on.
Some people will push back that agent development is "natural language programming" but I don't think that's right. I think in that case the agent is the one programming, and the programming still always happens in a deterministic language like Rust/Python/Typescript/etc. Maybe that'll change, but to me at least the other way would be a disaster.
The best exception I know of though, is definitely the Inform 7 language which is for writing text adventures[0]. It has a lot of fans, and I've never gone deep with it, but seems to do a pretty elegant job or marrying up natural language and programming together in a unique way.
Either way, definitely a must-check-out for any language-geeks interested in natural language programming.
"We'll just store prompts in VC and the agent will pick those up", "Code isn't going to exist anymore", "We will just write comprehensive specs of what the software is supposed to do"
This is short-sighted IMO. (Conversely, maybe my argument is short-sighted).
This is exactly why we use code... Natural language is ambiguous, to a fault. Any statement can impact depending statements in multiple ways, which creates this huge dependency graph that has millions, billions, trillions of "plausible" specifications.
It's pretty much ALWAYS going to be easier to just use a deterministic programming language to build the actual software.
We may never need to look at it, we may never need to write it, but having a deterministic specification of what a software system does seems like a much easier jump-off point to work with agents (whether or not we interface with the code).
Feels solved to me... A simple software example that creates users, logs them in, and shows them a dashboard turns into a TON of language and ambiguity.
Must be logged in to see dashboard datapoint A. Can log in with email or username. No log in if their IP is outside of [range]. Can log out. Logging out during a dashboard update cancels the transaction. Cannot see confidential data. Unless the user is an admin. User needs a strong password. Password must contain a capital letter.
Stuff like that just seems easier to parse + modify in code (whether human OR agent). Also, debugging natural language feels super icky. Which statement was it that got the password out of the formal spec?
And my biggest argument, we already HAVE code - reinventing the wheel for something that already works feels misguided?
> This is exactly why we use code... Natural language is ambiguous, to a fault. Any statement can impact depending statements in multiple ways, which creates this huge dependency graph that has millions, billions, trillions of "plausible" specifications.
Devil's advocate here: Why is having many possible implementations a bad thing? Sure, you don't want to half-ass your specifications and fail to pin down your product properly, but if you do pin down what matters, then by definition what remains is discretionary. Formal specs (e.g. the C spec) behave the same as informal specs in this regard.
The real question is whether humans in an agentic workflow can actually identify all of what's structurally and functionally necessary for their product. Either the spec writer must be expert, or the agent must be savvy enough to identify and collaborate with the non-expert. Right now, agents like to just plough through underspecification or bad ideas so that they can deliver as quickly as possible.
You're right - having many possible implementations is NOT the problem here, if a natural language spec covers all the 'necessary' functionality of a piece of software, the implementation does not matter (whether it's implementation ID 4 or ID 27548323)
My argument is more of a forecast, and your last paragraph fits it correctly. I don't think we'll be able to maintain it once we get past a certain level of complexity. Or the maintenance / modification of that specification will be much more difficult to work with, to the point that we'll decide code is the solution.
Yeah, just because higher level programming languages (PLs) emerged doesn't mean lower-level PLs or assembly disappeared. Programming with LLMs in natural language is somewhat like programming in a higher level PL that gets translated into lower level PL, all the way down to assembly.
When it comes to precision it's easier to express instructions in formal languages and I don't see that changing anytime soon unless natural language itself changes drastically, which I highly doubt. Formal syntax, well-defined semantics, reproducibility and composability are traits that make traditional programming languages more reliable and precise than natural language for programming.
This is the bet I'm making with Croft. LLMs to figure out the messy bits but once it's figured it, software is the better tool. Let the LLM write the software.
This is what software engineers do but just more expensive and time consuming.
I'm not sure if you're being self depreciating or genuinely desire that, but this isn't an outcome that leads to good software engineering.
You should own and be the expert on the architecture and design of what you're building regardless of whether yourself, an LLM or another person is writing the code.
The LLM isn't "smarter" than you, it's more resourceful. It can (to varying degrees of success) translate your design into code. If you aren't still taking ownership and driving the design of that logic, the LLM isn't going to bring you success with anything other than single-use or hobby applications.
The thing is, if you’re good at designing and breaking down problems and coming up with a good system, code is not likely an hindrance.
You can take any idea and try to flesh it out with pseudo code. Once that’s done, try to convert it to real code and you’ll see that process is fairly mechanical. This is why people says that coding wasn’t an issue for ages. Coming up with the algorithm is the hard part.
People that have an issue with coding either are not familiar with the language/platform or is trying to think with real code instead of pseudocode or diagrams.
ADDENDUM
There are techniques to think with real code, moslty the Edit-Compile-Run workflow coupled with a good editor, or the REPL workflow (also helped by a good editor). Then add a good integration with a documentation system (manual pages?) and you’re golden.
But I’ve been on projects where a dev cycle relies on a 20 minutes local rebuild or one hour CI run. So it can be very hard to try to apply those workflows to legacy projects.
I find this to be intrinsically true in my experience. I was put into senior-level engineering positions very early in my career because I'm a strong problem solver and mentor. I've taken on several positions as a programmer working with a language stack I had little to no experience in without much issue.
Of course there are problems where knowing the code deeply is essential to solve the problem, but those really aren't the majority, if even less than 1% of business problems.
When it comes to what the average developer needs to understand, having a strong grasp on one functional and one procedural language can enable you to solve almost every problem in any language ecosystem, provided the correct resources. If you can do this, you can utilize an LLM for programming assistance well. If you can't, you probably should not heavily rely on one at all yet.
I somewhat doubt the "fairly mechanical" claim. I think when you actually turn it into real programming language code, that's when lots of the edge cases become apparent and then you will face a lot of new questions, that the natural language or the pseudo code didn't cover.
I think those are mostly technical issues (accidental complexity) and those are either documented or there should be someone experienced with the technology on your team (even if that experience came from trying it out).
Critical thinking is essential for nailing down your essential complexity (the core solution of the problem). You can try to define invalid and edge cases alongside the happy path in the pseudo code diagrams version, even if it's a TODO comment.
Of course instructing agent is programming; the agent is an interpreter (albeit in some cases nondeterministic, but that's true for most programming languages that have a function to get current time) of the natural language. How exactly it is interpreted is given by the weights, the context, and possibly the random seed.
But even if we write in Python like foo.bar(), the interpretation depends on what is in module foo and function bar, how they are defined contextually.
You can try to find some difference but most modern AI agents come more close to a language interpreter than not, if the actual instructions are given.
OTOH, giving instructions to people is not programming. People do not consist of binary code that is reliably executed; they are biological organisms subject to environmental pressures such as being tired. They have their own consciousness and will, and can refuse to follow the instructions. LLMs are programs; they cannot decide not to respond.
Having software build software is programming. An agent is software, a human isn't. I can draw a UML diagram, software generates code from that, and software turns it into binary. That still counts as programming I would say, we're just changing the language. Otherwise you would have to say that writing JavaScript is not programming because it's too far removed from Assembly.
Having animals eat animals is food. An animal is food, a human isn't. I can draw up some hay, animals eat it, and another animal eats it. That still counts as food I would say, we're just changing the organism. Otherwise you would have to say that dogs aren't animals because it's too far removed from plants.
It really is the determinism aspect for me. Okay, it’s programming if you sample at temperature 0 with a fixed seed on a fully deterministic inference stack and you have made your prompts the artifact that you iterate on (repo full of natural language that “builds” into the running software it describes with the use of the LLM sampling at temperature 0)
> That still counts as programming I would say, we're just changing the language.
Anything can be anything it isn't once you start changing the language.
"When at first you don't succeed, redefine success."
> Having software build software is programming. An agent is software, a human isn't. I can draw a UML diagram, software generates code from that, and software turns it into binary.
It's not programming, it's cuckoldry. Articulating the perfect guy, inviting him over and watching him get to do all the stuff you used to enjoy literally makes you a manager.
That's not really what we're talking about though. Compiling verilog from simulink or whatever is totally different than an agent writing code.
If you design a custom piece of furniture, then hire someone to build it, that's totally fine! But if you then tell everyone "I constructed this cool table," well, that's just not true.
If I was brainwashed - maybe (hypnosis is sometimes called programming). But I am not, and AI agent is - it's trained to follow instructions, cannot help itself but do it.
Another difference is the binary code - I can run the same agent on a different computing substrate (e.g. different CPU), but with humans no one can do that. That has implications, we can study or modify AI agent behavior, for instance.
I've tried Inform 7 before for fun and one thing that struck with me is how incompetent I was with it. I was never sure if something was written right or not because of how free the syntax was. The practical effect of the English syntax was that instead of memorizing just the function an argument order, you had to memorize an arbitrary number of prepositions. And you couldn't even tell what a piece of "code" was doing just from looking at it since you need to parse the grammar with your brain first instead of just looking at the function name.
Inform 7 is a fascinating case study. There are a lot of really neat ideas in it such as “default driven development” but in the end it doesn’t succeed at being a way English majors can write interactive fiction because it takes the same discipline to write Inform 7 that it takes to write ordinary programs.
I like the idea that the code looks like English and is therefore readable, long ago I pitched a plan to make an “Inform 7 for European Air Traffic Regulations” where that readability was a big plus.
To be fair, Inform7 can't succeed, generally, because there is no market for the kind of games that you create with Inform7. Even if I was going to create a game like the kind you can make in Inform7 today from scratch while trying to keep more or less the same UI, I'd still want to add things that the emulators don't support natively, like some way to quickly tell which commands you can type.
That's not even considering the fact that in practice if you were to make a proper game like that today, you wouldn't choose text input because of mobile. You would have some sort of touch input instead.
I do want to say that I like the fact that a game made in Inform7 is a file that runs on a separate emulator, and some browser-based implementation even exist. It's kind of like Java, or kind of like a webpage.
I wish there was something like that for small games in general. An application that you can download to your computer that runs a game file sandboxed, so you can safely play random games that aren't browser games because the environment doesn't provide an API for arbitrary file access. That's pretty much what I wish Flash was, as well.
But Inform7 doesn't seem to be a NL programming really. I went to read the website (it's a mess btw), and my understanding is that it's built around strict rules, and patterns one must follow, i.e. it's is as formal as Python. It just takes a lot of efforts to look natural. So it's not unlike Perligata which was a joke allowing to write working Perl code in Latin. It just went much farther because it's not intended to be a joke, but the principle remains.
Yes, I think that's a pretty good description of Inform7.
Whether "natural-language-like syntax" is enough "count as natural language programming" is probably a question of definition. For Dijkstra's essay here, he doesn't offer a particular definition, but he certainly seems to be implying something much more fluid and ambiguous than Inform7 is.
I definitely didn't mean to imply Inform7 had achieved the holy-grail of natural language programming or anything.
I think Dijkra's main point he's driving at is here:
> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.
I'm inferring/assuming a bunch, but I think he's saying something along the lines of, programming is useful because it is precise, and natural language is not precise, so attempts to make programming languages more like natural language are butting up into this inherent contradiction of precision. And therefore will end up as worse programming languages (for attempting to be more naturalistic).
In the history of programming languages, I think most attempts to be "more natural language like", such as COBOL or AppleScript, do become worse for attempting to walk the tightrope between natural-language and programming. I think Inform7 is unusual in that it achieves that balance in a way that isn't just objectively terrible (you may disagree) - I think that's mostly because it offers very few programming constructs, and is a tool for writing a kind of prose (text adventure games).
Anyway, to come back around, that was my reasoning for mentioning Inform7 - I think it's an interesting deviation from other experiments in natural language programming so far.
Getting Inform7 to work well probably depended on 'text adventure'/IF culture, since the text adventures themselves rely on this kind of 'restricted natural language' interface to navigate. Conversely, IF developers built up a lot of intuition on how to make pseudo-natural-language input feel natural while keeping the restrictions obvious.
I’ve heard plenty of “tech enthusiasts” breezily talk about how close we are to natural language getting compiled down to machine code but has anyone credible got any idea if that’s even a path? Closest think I can think of is DSL type setups like a much richer version of the stuff Haskell people get excited about but that’s not close to an actual natural language "language"
Existence proof: everything Claude Code does, including talking to LLMs on GPUs via the Anthropic API, and shelling out to other tools installed on your system, could in principle be compiled into one big self-contained binary (or Turing Machine if you prefer) that is able to take natural language in and produce compiled binaries out.
If you wanted to go a bit harder you could train Claude to output machine code directly, but that's not necessary. Whether the machine code comes straight out of an LLM or out of a compiler that is fed source code that comes from an LLM is a mere implementation detail, there's not any fundamental difference.
It's more than an implementation detail. With an intermediate step of source code compiling & linking, there is a mechanical process checking for well-formedness that would otherwise be skipped. This is especially important if you're editing a large codebase, which even your agent's private-only repo would benefit from.
There are also times when you want the final product to be able to target different architectures and platforms. Generating into a higher level language allows for re-targeting the code by only changing a few compiler & linker flags or runtime/environment config. I would much rather that than hoping the LLM is feature- (and bug-)compatible between generation runs.
Not without some significant changes in how we turn natural language into programs. Yes, you can use an agent to do it, but the agent is going to rely on a compiler for the same reason human programs do: to check semantic correctness. In theory you could build an agent that outputs machine code, but the results would be pretty terrible.
I am not sure we actually want natural language to be compiled directly to machine code anyway. Those rich type systems that Haskell people get excited about are actually automatic proof checkers, similar to Lean, and having an agent check its output against such type checkers greatly improves the code generated by agents. If anything, we will probably see more widespread use of the lambda cube type systems (with extensions e.g. double negative elimination) as agents become a standard programming tool; human beings tend to find such type systems very tedious and difficult to work with, but agents are good at dealing with tedious tasks.
I don't know about the "stuff Haskell people get excited about", but IMHO, Haskell is a mathematician's language and the language of mathematics isn't a natural language. Dijkstra himself was also a mathematician, and his positions regarding programming languages features like 1-based indexing [1] are already conflicting with practice, the famous case being Lua which receives mixed opinions about it. I find for instance 1-based indexing more "natural", and that's coming from someone whose second and third languages are assembly and C (the first being... Basic).
Yet the point about DSL is interesting, in particular internal/embedded DSLs [2]. I lied a little earlier, my third programming language was actually Forth. His creator said in 2001, "When you devised an application you wrote a hundred words [i.e. functions] or so that discussed the application and you used those hundred words to write a one line definition to solve the application" [3].
I've been trying to do that exactly that in other languages, make it so that the code expresses "naturally" what it does as much as possible. When you succeed, people call your code "beautiful" or "elegant" (nobody ever told me that :-) which, I think, subsumes "naturality".
This is of course harder to do in low-level languages such as the ones I mentioned (except Basic maybe) because you get caught in details such as memory management. But high-level languages are not exempt of these problems (and contrary to Forth or Lisp, their syntax is often written in stone). Then there's essential complexity [4], which can be "unnatural" no matter what, like thinking about things in a concurrent programming context, with languages that don't natively support it like they support automatic memory management (i.e. garbage collection).
The topic is dangerously close to "readability", which is known to be 80% subjective.
Dijkstra's personal language design (GCL) actually used anything-based indexing -- you specify the lower bound explicitly when you declare the array, so even if indexing starting from some runtime value k (e.g. k=7, k=b.lower-bound for some existing array b, etc.) is most natural, you provide that as the lower bound. Then a(i) would be translated to e.g. a[i-k] in compilation.
IMHO instructing llms is programming - the analogy is not perfect but it is so close that it is quite useful. Programming is instructing a machine. We have now two types of programming - the traditional one that follows strict semantics and the new way of programming by prompting. The article still holds by showing the limitations of this new kind of programming.
I don't have strong opinions on when it's ok to use the work "programming" or not, but I think if you're using claude-code/pi/open-code/etc to produce something like a website or application, the "program" is the code the LLM outputs, not your prompt etc.
I don't think I'd want to call it "natural language programming" in the way Dijstra's implying here unless the prompt was the thing that was actively being executed/ran/whatever when someone loads your app or website.
I've seen some newer testing frameworks where you prompt for the outcome you want under a specific scenario. The first run is a LLM agent that figures out the steps but those steps are then used for recurring runs. If something fails, it goes back to the agent loop to see if it's an actual error.
This works well in e2e type tests where the test implementation might change but the customer experience hasn't.
So maybe there is a hybrid approach in our future.
Yeah, that's an interesting case study. It's pretty common practice to do something like llm-as-a-judge if your programming agentic systems.
I think those are different from pure "natural langyage programming" though because there's normally code you've written that's calling out to the LLM, so it's within the context of written code.
I think this, and lots of other comments are so interesting. There are a lot of different increasingly complex ways LLM outputs and coding are being tied together by people, that I hadn't really considered.
>So product managers have been programmers this whole time after all.
The entire point of the article was that human language isn't suitable for instructing computers, and you somehow make the leap to "humans instructing humans must be the same thing".
Reading comprehension must be a thing of the past at this point.
I read it the same way as well
Natural language programming would be more akin to my prose staying on file and the computer interpreting it again every time it is executed.
I've had the same view since coding agents appeared. LLMs are good for summarizing, thus I tend to use them to understand code. However, the more I understand a code base the more I tend to be more picky with the agent. While the less I know about the code base, the more open I am to let it do its thing.
I've realized that the agent doesn't write 'good' code, instead my vague understanding of what I expect makes me think it does. When I look at the AI code, I see that there are more nuances and decisions that needed to be taken before writing the code. One would say that a spec would suffice, but then I remember TLA+, developed by Leslie Lamport to help developers think critically about their programs/algorithms. Sitting down and formally writing what I want to do helps me better understand the problem and come up with a real -not vaguely defined- solution.
I think the difference is between communicating to a purely mechanical being versus communicating to an intelligent entity: unlike programs, which are purely formal languages, we write textbooks and papers in a mix of human language and formal language. often we introduce "just formal enough" notations. and the intelligent reader will read in-between, inter legere literally means just that: reading in between. filling the gaps, connecting the dots.
and in practice I find it _very_ effective to express key ideas with some formal language where applicable. a little ebnf here, some snippets of python or prolog there or other languages there. and I find llms wonderful at filling in the dots and, and that's the topic here, to translate our semi formal conversation into rigorous, formal language.
and I dare one step further: I also find llms useful in formulating and refining technical proposals, for human peer review and llm driven implementation, and of course these proposals mix natural language prose with semi-formal and formal detail. think PEP-12 and PEP-1 style. and these then get work packages which each loop in a spec as in sdd.
I'm going to take the contrarian view and say that formalism without jargon, friction and gatekeeping is just natural language.
I've been going through an identity crisis for a year now as I realize more and more that nearly the entirety of what I know comes down to arcane incantations producing transpilation instead of magic. My tech career was just converting specs from clients and employers into machine code, with extra steps.
To move now at the speed of thought and let AI complete whatever tedium was preventing me from getting real work done has been a revelation.
To the point that I fantasize about the day I can leave tech behind and get back to the human experience. No longer drowning in the unending workload that demands ever-increasing productivity for the same pay, but finally able to say enough's enough and provide time/money/resources for myself and eventually the community at large outside of the hierarchical economy.
If we can't automate our livelihoods with AI, then we don't have anything.
> I'm going to take the contrarian view and say that formalism without jargon, friction and gatekeeping is just natural language
Try to define a specific item like the closest cat to you so that anyone, just from reading the definition, can recognize that cat anywhere. You could write a whole book and not be done. Or you could stamp the cat with some id (symbols) in and refer to that. As long as that id is not repeated (rule), the system is ok.
Formalism is defining stuff, and add rigid rules that are consistent with each other. Once that done, it allows anyone to reach the same thinking location as the original person. Formalism is a knowledge transfer tool.
> My tech career was just converting specs from clients and employers into machine code, with extra steps.
If all you did was that, I’m quite sad for you as yourself should have automated your job to remove that tedium.
I would describe my job as designing a system that respect all the constraints of the situation. Some of them comes from specs, some comes from the technical platform, and some are just future possible interactions. The system is what I modify, coding is just how I do it.
When I see people abandon their work to AI, the other consequence is that they abandon their control of the system as well. They can’t explain how it works, what’s its reliability, and whether it can be improved (or part of it reused in another context).
> My tech career was just converting specs from clients and employers into machine code, with extra steps.
I guess the thing about that process is, you inevitably complete an incomplete spec. There are always fine details that will never be decided until they're required to complete the implementation.
You made it further than most. At least you're realizing our identity is formed off what we know, the more we know the fewer options we have.
The expansion of knowledge is what ends societies and erodes civilization but produces religion.
Perspective of the religions is that I is the devil, the unaffiliated individual's perspective as opposed to we. All the religions teach fasting is abstaining from I want and pursuing we need.
We drive ourselves to the truth of what matters by eliminating waste as much as possible for 6 weeks
Well we've been doing exactly this for 200 years! IMO the use of fossil fuels for manufacturing novelty products that go straight-to-landfill, and daily suburban commuting to bullshit jobs, and diverting water to inhabit cities in inhospitable deserts, is a greater cause of our 'slow genocide' than AI will be. So why would we stop now, when we couldn't be bothered to even slow down before? (Annual carbon emissions aren't even trending downward, much less getting to net negative!)
So while I also foresee and lament humanity's self-genocide, it seems a bit hypocritical to get salty about AI "automation" while broadly accepting our industrial civilization's trajectory.
> Annual carbon emissions aren't even trending downward, much less getting to net negative!
They were trending downward in the US. AI usage in the US did change that single-handedly. I understand carbon emissions are a global problem but since they are subject to political remedies, the solution to the global problem is solving the same problem within each political jurisdiction.
Natural language is full of nuances and implicit cultural and domain specific connotations. LLMs work because they have been trained on massive corpus of materials that encode some (but not all) of those hidden meanings.
With specification driven development, the prompts need to be very detailed in order to produce exactly what is required.
Humans also work because they've been trained on a massive corpus of materials, spanning like an average 15 year period or more. And humans too need to be prompted, sometimes everyday, with meetings and whatnot to produce exactly what is required.
I used to do software dev without meetings. It worked just fine. I would send whatever I did once it was done, and get direction on where to take it next. Maybe this breaks down in companies with more than a few leaders, or where the leaders can't otherwise keep in sync.
Also gave me plenty of opportunities to go above and beyond. I miss when that felt safe.
This depends entirely on how well the requirements have been communicated, right? If you could go for long periods without meetings on large projects, it means either you had great PMs or you’re very good at collecting relevant info and planning in advance. Or, it could mean that your target was quite flexible and open to interpretation. I don’t doubt it, and I’ve known some developers who could do what you did, deliver something great without that much back and forth. I’ve also known many developers (probably most TBH) who will focus on problems the customers don’t have and endlessly go down rabbit holes that have no bottom. Heads down software engineering for big-O and data structures seems to be a lot more fun for some people than fixing weird hard to repro bugs with vague repro instructions that customers complain about. Many very good devs still need to check in and iterate and get some steering, especially if the requirements have not been well or fully explained… which in my own experience has been more or less always. ;)
Maybe my definition of meetings is different than yours. To me, meetings are voice or video calls where multiple people talk about progress and direction, raise issues to the others, etc. and the leaders can make calls across the whole team at once. Staying in constant communication doesn't count as much because it's more async and incremental.
You’re right, my definition sounds different. Your comment left me with the impression that you meant you weren’t talking to anyone. Meetings in my book are any scheduled discussions, regardless of how many people are involved. 1:1s are still meetings.
1:1 meetings are still meetings, but casual messages about progress and direction (without a scheduled time block or synchronous call or whatever ) don't count to me.
Maybe those were some very detailed requirements you were getting, the deliveries were straight-forward, or you already knew the space pretty well. Or you're the only dev there. Somehow most teams just keep tripping over each other and need near constant management to ensure they're delivering what the stakeholders expect.
They weren't particularly detailed, but I did know the space quite well. I was a heavy user of other products of that type, and knew very well what I wanted out of one.
The problem is that your case is extremely rare. Most people work on systems that they never would use themselves or even know existed if not for working on it.
Wherever I work, I try to turn the system into something I would use myself. I am not always successful in this, but it drives a lot of my UX decisions, and it seems to work fairly well.
> I used to do software dev without meetings. It worked just fine. I would send whatever I did once it was done, and get direction on where to take it next.
You didn’t collaborate with other engineers? Or what if the spec you were given was unclear in places? Forgive me, but the style you describe sounds incredibly collaborative, super transactional.
Funny story actually, there were a few other engineers but not very much collaboration. They were resistant to sharing source code or algorithm details, so I had to essentially reverse engineer how their other products worked. I was good enough at it that I came up with several features they didn't know were possible. They eventually ended up letting me go and cloned my design, which I thought was weird, but it was developed for them in the first place so not a big deal.
To be fair, it's a very secretive industry, and betrayals are quite common. Worse, a lot of those betrayals are done on pure impulse without even thinking through the consequences first, so you can't actually build incentives against it because they'll just be ignored.
> Humans also work because they've been trained on a massive corpus of materials,
Massive? My introduction to programming (from noob to beginner level) has been like only 10 books worth of content. Including some alternative pathways like 3D, security, system administration,... To this day, I don't think I've reached 50 books of materials. And If I counted everything it would be still small.
Human learning is very efficient (not time wise, but cost wise, and even training data wise).
You're forgetting all the schooling before that, which taught you how to read, do math, etc. And the general daily experiences of just being a human being interacting with the world. Magnitudes more data taken in than any language model.
You should check out how much raw data just your eyes process for every second they're open (although a significant amount is discarded before it gets to the vision center, but still). Then consider the other senses also constantly doing their thing.
The vast majority of people don't internalize most things. Some internalize even less. It can become a big issue with things like dissociative disorders. (I have some experience with that)
LLMs don't internalize per se (assuming something akin to conscious intent). The foundation of a model is comparable to a human's daily experiences of just being, then the fine-tuning is comparable to formal schooling, and finally the prompting is comparable to meetings for workplace tasks.
I said nothing of LLMs. I don't compare the process of LLM training to any form of human education because they are fundamentally dissimilar. LLMs are engineered mathematics and cannot self-train yet.
There are of course parallels. Anyone who's done ML should be able to see it at least. But yes, there are fundamental differences in methodology due to the mode and level of access: with a human, the only way is to go through the senses and there's no - easy - way to affect the learning substrate; with a LLM, data is directly injected into the substrate, which is also human-architected.
Organic beings have more than just the senses, they also have higher level concepts and complex internal incentives. This is more important than the senses being the only method of access, I think.
Language models currently are mutated in the direction of exactly producing the desired output data, but gradually enough that they generalize across inputs in a way that appears understanding. It is more similar to compression, though, at least before a randomizing sampling strategy is applied during decode.
Anyway, circling back to my original topic: no organic being has the capability to integrate all the data arriving from their senses! They typically get more and more selective with experience, picking out only the pieces of information that are still important. Some are more selective than they're supposed to be, by choice or not (such as with dissociative disorders). In any case, the raw quantity of data coming through the senses becomes almost entirely irrelevant.
> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.
He's still quite correct. I generally see a machine as being "programmed in" whatever is tracked in source control. So as long as your git repo is tracking changes in Java, that's still programmed in Java, even if the Java was generated with the assistance of LLMs. I may consider the thesis of this article invalidated only when the majority of repos start tracking natural language rather than programming languages as the primary artifacts defining behavior of the software.
That would be one definition of "source code". But then there's also the definition by the Free Software Foundation as "the preferred form of the work to making modifications to it". As prompting LLMs becomes the preferred form of making modifications, I wonder if a lot of open-source repos will unwillingly become "closed (prompting) source" over time, with intricate legal consequences.
I still don't know if I'd agree with you. I think:
> the preferred form of the work to making modifications to it
Implies what you point to when you want to know where to make changes.
That wouldn't be a prompt - you might use a prompt to make changes, but the thing you're making changes to, certainly at present, is your java/python/rust++ /whatever codebase.
Lots of projects, even fully vibecodes ones, don't push and include prompts in their repos. But they all push the java code (sticking with java as an example for the sake of argument).
I can't imagine that working on a project where the java code is omitted, and people make changes to the software just by editing the prompts would go well. It's an interesting thought experiment, but I think you'd find it very hard to work on any kind of team where that was the practice.
> Implies what you point to when you want to know where to make changes.
Where do I point to when I want to know this? On a large and mostly LLM-generated codebase, I might dig through the code myself to find what needs to be changed where, but I would probably prefer to ask an LLM to do this.
Now if I had access to all previous prompts that were used in generating the codebase, it might very well be the case that I would prefer to work by changing those prompts and generating the whole thing again. In that case, the LLMs would basically turn into a compiler and the prompts would indeed become the new "source code". This is clearly not (yet?) a common approach to software development, but I wonder if it may become. Or should.
If one uses LLMs to generate the code, and others need LLMs to read the code, isn't this awkwardly close to someone publishing only compiled binaries and others then having to reverse-engineer these binaries in order to know where and how to patch them? Maybe the handicap is less grave, as the difference in strength of LLMs understanding code vs writing them isn't as huge as of decompilers decompiling vs compilers compiling code - but I think this difference still exists. It's still an advantage to have knowledge of the "secret" prompts that were used in generating the code.
True, and as such it needs to be considered like any other code output from a one-off code generator, with at least minor added risks from non-determinism and, in the case of LLM-as-a-service, potential lack of model availability in the future.
This means maintainability is as important as it is for hand-written code. Which varies, of course: there are plenty of valid use cases for one-off throwaway code. Just don’t assume checking in slop is suddenly cost-free “because AI”.
Natural language as code has existed for thousands of years. Today we call it legalese.
It's excruciating to write, excruciating to read, and even legit geniuses with decades of hard won experience still leave room for essentially infinite interpretation. laws and contracts are all still swiss cheese and can be made to demand or prohibit whatever the party with the most money or other influence wants.
If law was code, there would be no need for judges to make decisions. Instead, a "judge" would be someone making a mechanical derivation of the judgement given the situation and the law.
The law is rather a complex set of guidelines which need to leave some space for interpretation, so that additional relevant information for the situation at hand can affect the decision.
Only the legislated part of law is codified. In our American common law system, case law is, by definition, uncodified. So what judges are doing, is taking the codified legislation, and applying case law decisions in layers on top, to reach a final decision.
What Dijkstra said still holds true, and the essence is consistent with Brooks' discussion on essential complexity vs accidental complexity. I do think one thing has changed, though: when someone asks AI to implement XXX with very vague English, the implicit ask is picking the best[1] ever solution that someone else has done to solve XXX. For instance, if I ask AI to extract the Japanese subtitle of Shirojima show and convert it to an epub with all the nantural and cultural explanations, I was assuming that AI will fill in the blanks and do a good job and AI did. This won't help expert, but does it matter? Being good enough can be good enough to take away many people's jobs.
[1] For many people, the result is actually the mean not the best, but it's another topic.
Todays natural language program won't work tomorrow due to unstable nature of natural language.
Apart of natural evolution of meanings, look at Orwellian limitations some (cloud) models impose on is that our natural language program become illegal. Due to topic or combination of words the program needs to be flagged and soon likely reported to three leter agency.
Next, RMS would ask: can you make your own natural language program compiler from scratch?
I know we have (very expensive) local models, but wait until GPUs get a propper online subscriptions to work and surveillance taps.
Dijkstra elegantly explains why AI systems are effective at mathematics and programming but much less effective when writing prose or other realms where what is good is nebulously defined:
> "The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid."
LLM interfaces on everything these days equate to touch screen on cars. It is definitely a useful tool, but generally speaking, that's not how you'd talk to your computer.
NL programming is foolish to me not on technical grounds but on practical ones. It is most valuable when the business wants to understand how an already working thing does its job.
I have observed several samples where the business, when provided with a natural language configuration opportunity, will wind up staring blankly at the textarea until the original developer gives them a complete starting point.
I don't think "natural" language makes much of a difference unless you are already skilled in the art of developing useful engineering specifications. I often have to babysit the business through very basic boolean algebra concerns despite everyone having 3+ decades experience dealing with this stuff. Making everyone speak python could only make this worse, not better.
I use HN to keep myself warmed up on natural language expression. The difference between developers who post here prolifically and those who barely write one email a month is fairly shocking in my experience. If you intend to use a specific instrument to accomplish a complex task, you need to practice it constantly. Ideally every single day. There is no substitute for this. There never will be.
> I have observed several samples where the business, when provided with a natural language configuration opportunity, will wind up staring blankly at the textarea until the original developer gives them a complete starting point.
A lot of people lack “system thinking” when they can break down something into a set of elements and describe the relation between them. Once that done though , they can understand a part and manipulate it.
For some “system thinking” is innate. It can also be learned. But it’s a required quality in engineering where you need to create a solution where there was none.
The experiment in designing a language that resembled natural languages (English and Japanese) was not successful. -[1]- William R. Cook, AppleScript, HOPL IV
Now our new LLMs are different, because they don't use "language the resembled natural languages", but actual natural language. But the lesson is instructive nevertheless, because it gives us some empirical evidence to compare to Dijkstra's theoretical arguments.
And this is that natural language is at best a two-edged sword. Yes, there are benefits, but there are also huge drawbacks. And one problem is that the benefits are front-loaded and the drawbacks are long-term problems.
To me, one thing we are missing is that what LLMs do for us actually has 2 parts.
1. It allows us to use natural language, allowing us to be fuzzy.
2. It allows us to specify what we want at a much, much higher level than usual.
With our LLMs, these two are intrinsically linked. I think the whole would be much, much more valuable if we could separate them.
The most obvious reason natural language is a poor choice for programming is ambiguity.
Time flies like an arrow.
I saw the parade coming through the window.
For small programs that basically duplicate something else with a few tweaks, sure, natural language can be fine. "The same thing as A, but with a red border, and add a new button to do X." Beyond that things start to get tricky.
Interactive programming has far more value than natural language programming, and agents also give you that. An ambiguous natural language spec. that leads to the wrong result is less problematic when you can interactively correct the problem; "No, that button should have been on the left hand side." It is the new version of REPL.
>We would need all the intellect in the world to get the interface narrow enough to be usable,
It seems Dijkstra is describing potential calability of LLM model trained on published collective human knowledge enabled by the Internet
>and, in view of the history of mankind, it may not be overly pessimistic to guess that to do the job well enough would require again a few thousand years
Since the article was written in 1978 (about 50 years ago) and from the time the computing resources of CPU and RAM has increased exponentially until the LLM first appeared in 2020s, it seems the thousand of years prediction is merely several decades accelerated by the rapid advances of computer and communication systems technology spearheaded by companies like Nvidia.
Oh look at the last paragraph on the first page. Manually justified:
In order to make machines significantly easier to use, it has been
proposed (to try) to design machines that we could instruct in our native
tongues. This would, admittedly, make the machines much more complicated,
but, it was argued, by letting the machine carry a larger share of the
burden, life would become easier for us. It sounds sensible provided you
blame the obligation to use a formal symbolism as the source of your dif-
ficulties.
How does one even achieve that with a manual typewriter?
That's the HTML version, which Dijkstra did not himself produce. People took the handwritten and typed EWDs and transcribed them for the web. If you look at the PDF scan of the source document for this one it was not transcribed by Tristram Brelstaff, it was typed by Dijkstra.
Luca Cardelli created the handwritten typeface Dijkstra font in the late 1980s, to mimic the distinctive and precise handwriting of his colleague Edsger W. Dijkstra.
(You have to click on the "Fonts" tab, there's no direct link to it.)
Dijkstra [.ttf (2013 updated version by Reuben Thomas)] [.zip (old PC)] [.hqx (old Mac)] [Preview.pdf]
A beautiful handwriting font of unknown origin, first popularized by E.W.Dijkstra. Excellent for slides that appear to be carefully written, and for short, deep technical notes.
It's not just em dashes, it's 1: typewriter em dashes aka `--` and 2: usage of them in pairs, like parenthesis, that is completely different from how LLMs use them.
From a pragmatic perspective, I'm with Djikstra for a very specific reason.
Clearly it is possible to "program" in natural language. I have one- and few-shotted a number of apps that meet my requirements.
Generally as the number and complexity of requirements grows it becomes harder to parse them if they are in a poorly structured natural language format.
I can't think of a time that I have provided specifications in natural language with sufficient rigor that if I was to run the prompt ten times, the ten generated programs would look identical or provide exactly the same outputs for the same inputs under all situations.
Whenever I find that I need the rigor such that the code could be considered to be a cache, not an authoritative artifact, I find domain specific languages to help me to ensure the comprehensiveness of my requirements around the dimensions that I care about.
I also find such structure to aide collaboration with other humans trying to understand or extend such specifications.
So I think for code to become ephemeral, for substantial pieces of software that require the documentation of many complicated requirements, writing such specifications in natural language is not the best interface and would require substantial support from LLMs to project them in ways (flow charts, UX demos, etc) that humans could reliably understand and mutate them without introducing regressions.
But we'll see. Last year I still thought git was an appropriate version control system to use!
This feels so incredibly relevant for today.
This also makes me think about the cognitive delegation problem - structured interfaces in machines and structured methodologies in mathematics helped humans build structured thoughts to express abstract intuition. With machines starting to speak natural language, it's probably not too far fetched to say that humans will eventually stop organising their thoughts, which will turn their thoughts into a kind of brain fog.
Isn't philosophy the best example that you can organize your thoughts in natural language? Of course, there is the tradition of analytical philosophy. However, the vast majority of philosophy was and is written not in a formal language.
Philosophy, analytical or not, is actually math underneath. You use facts to derive other facts, typically about existence. It has a mathematical base. Reason why most ancient philosophers were mathematicians.
When comparing it to math, this always felt to me like a clear limitation in philosophy, though. Just look at how philosophers try to argue about "logic", compared to mathematics' elegant descriptions.
This article shows every now and then, and it's a must read. Indeed the natural language programming requires massive clusters of gpus just to make a half baked crud app
>And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.
Fun fact: there are over 600 definitions of the word "run" and over 400 for "set".
But yeah, English is really precise enough for programming.
How many times have we seen that there's been a spec for something and the programmers write something that is exactly like the spec said but was completely wrong?
> (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.)
It is perhaps for the best that Djikstra did not live long enough to witness this problem become orders of magnitude worse.
Programming in natural language still doesn't work, Btw!
whenever you're using a Ml model to either autocomplete code or as an agent, you're not really programming in natural language but "delegating" in natural language!
The old skeptics weren’t wrong about the foolishness of natural language as a programming language, it's just that they assumed the only possible intermediary way to "write" code was something compiler-like!
they never really thought about a future where ai would become good enough to translate natural language instructions into runnable code
Yeah - in my own personal experience building AI products this still holds true. And you can see it in the way they behave themselves, they don't really write prompts for themselves to use in the future (say CLAUDE.md) when they need the output to be deterministic. They write code for it, then write tests around that code, then fix the bugs in that code.
Yes it all started with "natural language", but even AI has an understanding that you need more structure than natural language when you want deterministic results.
My take is that this is largely right. To be specific though, I feel the future is natural language commands that will be translated into a proper language through llm systems.
In this way, the generated output, whether used as a proper program or just some scripts to do small activities, they can be audited later, reused, and tested even if a client created the request in plain language.
We would then mostly be translating bugs from english to the underlying language and bugs would mostly be people speaking ambiguously or just misspeaking
The human equivalent of LLM could be to build a wiki / semantic graph of all algorithms, tutorials, framework docs, stdlib docs and attach a make file at the end each node.
I've been stating it elsewhere, attention has made English into a context aware sensitive programming language by resolving ambiguities through anaphora and coreference resolution. Inform7 did limited anaphora resolution - it - but LLMs are able to resolve "move that file to this folder".
> Remark. As a result of the educational trend away from intellectual discipline, the last decades have shown in the Western world a sharp decline of people's mastery of their own language: many people that by the standards of a previous generation should know better, are no longer able to use their native tongue effectively, even for purposes for which it is pretty adequate. (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.) This phenomenon —known as "The New Illiteracy"— should discourage those believers in natural language programming that lack the technical insight needed to predict its failure. (End of remark.)
Tell me about it! This has only gotten worse in the meantime.
> From one gut feeling I derive much consolation: I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.
Sadly, this is no longer true. The floodgates are open. And as it turns out, many people get really angry if you curtail their ability to talk nonsense, even if the result it supposed to be software.
His point is moot. His argument considers that natural language would be the direct expression of the program. It's not. It's an abstraction layer, that is then converted in formal language. He could have foreseen that, given he takes explicitly the example of machine code and high-level languages. High-level languages do not replace machine code, they translate into it. Just like natural language programming translates into high-level language.
Consider the role of a Business Analyst, in corporate environments. He is the person that talks to stakeholders and users and translates their "natural language" wishes into piles of semi-formal language (UML anyone?). Later on this will become fully formal language.
But I think Dijkstra point is more that we can't fully automate this process and let the machines do the formalization thingy. I used to believe that but I've seen LLMs doing things that really, really surprised me.
In the end I still hold hope in the old saying: "make a something idiot-proof and someone will just make a better idiot". We see LLMs doing magic if they're used by people that know what LLMs are doing. I never saw LLMs doing magic in the hands of idiots.
What do you commit? As long as you commit high level code to your repo, you are still programming in that language. You don't commit machine code because you know it will be always the same after compiling. And it also doesn't matter that you are using very high level tools and basically don't ever look at or even understand your programs any more.
I don't think reproducibility is relevant, here. Otherwise, even your compiler example doesn't stand. No, machine code is not always the same after compiling high-level language. First, it depends on compiler. Clang and GCC won't produce the same output. Then it depends on the version of your compiler. GCC-9 and GCC-11 won't produce the same output. It obviously depends on the architecture too (arm vs x86), but even then, it depends on details about current configuration of the system you're building it on (CPU flags, hardening, etc). And then of course, there may be things randomized on purpose at each build, like randomized memory addresses to make the binary less exploitable.
Yeah I should have been more precise. What I was suggesting is that the behavior of the machine code will be always the same after compiling (assuming no compiler bugs).
Anyway, my work process is as follows: I have the agent write the code, and describe it's purpose etc. via comments so another session can later pick it up easily without me having to explain everything again. That's what I commit. Sometimes I even look at the code :)
What else could I commit? At the current state of the art, I could commit the whole natural language session that lead to the code, instead of the code. When I later check this out in a fresh environment (without the artifacts the LLM putted out), I'd just load the most recent version of the conversation as an initial prompt. Or I could want to check out the conversation at a point two months ago and rebuild the program from there.
Would that produce a program with exactly the same behavior? I don't know. But if it doesn't, the essay's argument is not moot. Not yet ...
Interestingly, it _is_ possible to get the exact same output from the exact same input with LLMs. For example, with llama.cpp/llama-server, you can set the temperature to 0, define a seed for the randomizer, turn off caching so it doesn't mess with the inference, and you would get the exact same result every time. But it's largely an academic distinction, because 1/ change a letter in your prompt, and it's over… and you're certainly going to want to change your prompt at some point, and 2/ model publishers have recommendation about the temperature setting, usually between 0.7 and 1, so your reproducible results… might be terrible at solving actual problems.
That being say, I really like the idea of committing our prompts. I can see a possible future in which that would be our work: write precise specs so that you can generate the program again with an other model, in an other programming language, and get the same behavior. Which sounds a hell lot like… a RFC. :)
We may be the culprit here, by the way. Maybe the only thing missing is us taking "prompt engineering" more seriously. It would be specification writing, really, or protocol design. I think it might already be possible, from an experience I had. I made Codex write a POSIX vi implementation from POSIX ex/vi specs. It took it a week-end, but I now have a POSIX vi, with only added on top multilevel undo/redo and syntax coloration, and without the baggage and instability of nvi2, I'm an happy man. I've been using it for more than a month and still have to find a fault to its POSIX implementation (and there are _a lot_ of details in POSIX vi specs). I think models are already there, when it comes to implemented behavior predictability, it's just us who are not precise enough in our specifications.
I built a music player by talking to Claude Code in Japanese, and I can barely remember a time when words failed and I had to fall back to code. For example, I asked it to "keep the sidebar's shape, but add margin on the top, left and bottom so it looks like it's floating a bit — you know what I mean?" and it got it right on the first try.
"...some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate 'the ease of programming' with the ease of making undetected mistakes."
> The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.
Hence, when communication via formal text results in nonsense, it is very clear that the originator of that nonsense is you. With LLM-generated code the nonsense may be much less obvious and when it does surface, you can feel like it's not your fault at all. You are a genius and the LLM fucked it up. No wonder all kinds of "developers" want their code generated by LLMs and don't even look at it anymore. It's the ultimate responsibility laundering.
We are now totally there: Programming With Natural Language.
I could only describe the "look and feel" of the ESP32-algorithm driving a sewing machine: "Snappy but not jerky, linear at low speeds, but accelerates fast".
Antigravity made it perfect but incomprehensible for a hewman.
I find c++ very unnatural, since it's a giant collection of small rules in the end more complex than assembler. I can't remember the entire sintaxis, zoo of function decorators, undefined behavior, intrinsics which are just labels over asm instructions, Code golf sintaxis...
App stores are approving an order of magnitude increase of new apps because people are now able to create them using natural language. End users are deriving great value from them. So this is settled?
I actually wrote a thesis on this in graduate school, and completely disagree with the author.
The problem with this argument isn't that natural language programming leads to vague/ambiguous code that would lead to errors. The problem is that the machine does not inform you of the ambiguity. Rational humans do just fine when they interact because they can identify these problems. Programming would work just find if context were identify and clarified while the code was being written.
If I were to tell a program to "buy political ads in Portland," yea, the point is that the program would need to know which Portland I mean. Otherwise it might accidentally think I mean Portland, OR, instead of Portland, ME:
Humans can do the same thing if they're not being careful. The point is, the vast, vast, vast majority of time, someone would just say "wait, you mean Portland, Maine, right?" and you'd say "yes" and that would be that.
Dijkstra's epigrams have not aged well. He once mocked software engineering as "how to program if you cannot"—but this too is a solved problem thanks to AI.
And yet, the specification of almost every program in existence was communicated in natural language. At least between the customer and developer.
This argument makes the implicit assumption that humans are uniquely able to convert between this "customer wants a program that solves their problem" level and compileable code. That was a reasonable thing to believe in 1978, but is not a reasonable thing to believe in 2026.
Once an employer asked me to automatize his work, so the task that he did in weeks was done in seconds. I made a gui that showed every step he did manually, so he could check and understand every step. And yet he became confused and lost track of what the program was doing. He frequently asked me the very concepts he taught me so I could do the program. I just implemented exactly his specification. I didn't created any new concept, but as soon as the task became automatized, he stopped understanding.
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.
> 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.
No, the article explicitly says that the difference is formal vs informal language.
> Programming remained the use of a formal symbolism and, as such, continued to require the care and accuracy required before.
One can define an operational semantics for (at least a subset of) the programming language (even for sloppy one, since they are still very small and restricted). One can prove the semantics preservation theorem formally, or reason somewhat in a similar way informally.
With natural language you kinda lose it, and we don't even touch the fact that models are probabilistic.
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.
The magic sauce in intelligence is context-awareness. If a prompt is somewhat general ("make me a calculator") an AI should either ask questions, or make reasonable assumptions, or both.
IME LLMs often make reasonable assumptions, but sometimes they don't and you have to backtrack and say "No, what I meant was..."
When the process works it's almost magical because the LLM successfully anticipates your needs, and implements your request in a much fuller way than you might have done yourself.
When it doesn't it makes a mess you have to clean up.
But generally I've been impressed by how well the leading LLMs will Do The Thing from a brief description, interpolating useful and correct details without being told to.
Compilers don't work like that. They're translators, not (entry level) inventors with independent agency.
Some compilers can do that, but only in a very controlled way. For example Haskell's deriving or inference of the correct method called on typeclass. Or the Prolog/Datalog/SQL - they will also fill in many details on how to arrive at an answer.
>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.
> I'm not sure what the argument is supposed to prove.
I’m guessing it’s supposed to show that if you have to have arbitrary levels of intelligence to interpret natural language, then nothing’s changed between now and 1978 when considering whether “natural language programming” is a thing. Just because the intelligence is artificial now doesn’t really change the answer.
>Just because the intelligence is artificial now doesn’t really change the answer.
Not only it changes the aswer, it's literally the whole of the question. When people talked of the posibility or imposibility of “natural language programming” they *always* meant "natural language instructions which *a machine* translates to running code".
They didn't have to spell it out, since nobody doubted a human programmer can write code when given natural language instructions - that was already a thing since ENIAC, if not since Ada Lovelace.
That's what we have now, and that's what changed between now and 1978 when considering whether “natural language programming” is a thing.
These two statements are distinct:
- You can program in natural language
- You can tell an AI what to do in natural language, and it can gather requirements, sketch up a design, write code, search the web for error messages, and iterate on the program until it works.
For certain things people care about, they’re equivalent (I tell the computer what I want and out pops a program) but for certain other things, they’re absolutely not (natural language doesn’t map deterministically into machine instructions.)
When people talked about natural language programming decades ago, they were talking about a system that compiles natural language into machine code. They weren’t talking about a system that autonomously gathers requirements, decides what frameworks to use, searches the web to look up error messages, iterates on ideas, etc… these things are so different from “natural language maps to machine code” that I don’t think we’re going to have a useful discussion if you think “I tell the computer what I want” is the only aspect of this worth looking at.
>They were talking about a system that compiles natural language into machine code. They weren’t talking about a system that autonomously gathers requirements, decides what frameworks to use, searches the web to look up error messages, iterates on ideas, etc… these things are so different from “natural language maps to machine code” that I don’t think we’re going to have a useful discussion if you think “I tell the computer what I want” is the only aspect of this worth looking at.
This confuses two things still:
People wanting to have natural language to machine code via AI, just AI that was implemented the way they thought was achievable then (symbolic AI).
People wanting to have natural language style programming language, similar to later AppleScript or some 4GL languages.
Natural language programming, or natural language processing, as it was called, was tied to the first, and the AI research of the time, from the beginning:
https://en.wikipedia.org/wiki/Natural_language_processing
So, yeah, they didn't have LLMs, but they pretty much understood such a program or "compiler" would need to understand world facts and natural language to even work.
> Natural language programming, or natural language processing, as it was called
NLP has nothing to do with programming. The Wikipedia article you linked doesn’t even mention programming once. NLP is old-school AI like you get when you try and cram all language into an ontology and try to “parse” it in an unambiguous way. It’s how Siri worked from the beginning, and it’s a complete dead-end. (I have some background here, I was an engineer on Siri for over 10 years.)
The fact that a compiler using old-school NLP would need a complete understanding of the world and all relevant facts in order to make natural language “process-able” is the reason the whole thing was a failure and why LLM’s are needed to make the idea work. You can’t just go from “parsing language” to “make me a TODO list app” without having an arbitrarily intelligent system to understand all the relevant background that such a statement implies.
When people realized human-level intelligence is necessary to make natural language programming work, is basically when the idea died. And now we have LLM’s and (what many would define as) human level intelligence, and its ability to program is just one side effect of many of it being truly artificially intelligent.
You misunderstood my comment - I meant that if instructing a programmer to program something is "natural language programming" (what AI agentic coding is), then they had "natural language programming" in 1978. I wasn't saying they had AI in 1978.
> 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!
There are a few little differences between human beings and computers that you should know about.
For example, humans are sentient, have agency and can be held accountable.
So when you give humans a bad spec, you can still get what you want, because, with some luck, you're simply delegating the task of thinking and making choices to another human, who, by the very premise, understands the language you are communicating in, and can work out your intents with you.
The whole "this meeting could've been an email" thing, you know.
That meeting could've been a pull request if whoever needed a thing to be done could figure it out on their own.
LLMs can be helpful for figuring things out, sure.
But "sudo make me a sandwich" style of vibe coding is just removing the obstacles to enshrining ambiguities and bad decisions in code.
>But "sudo make me a sandwich" style of vibe coding is just removing the obstacles to enshrining ambiguities and bad decisions in code.
I'm of the opinion that if you think it will stay this way you haven't been paying attention. "sudo find me a security flaw" already embarrasses top security researchers who have been working on the same code for decades. "sudo decompile this program/firmware/game" is doing absolute wondrous things right now even if there are still some flaws. If it can do these things better / significantly faster than humans already, and if it keeps improving at the rate it has been "sudo make me an operating system" that spits out something actually pretty good is probably within a decade.
Your two examples are taking something that's already built, and are extracting a feature (security flaw) or translating (decompiling).
The Kolmogorov complexity, at best, remains unchanged.
"sudo make an OS" is a different kind of transformation.
It's as much programming as downloading an Ubuntu image, and you don't need to wait a decade to do that.
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 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
And if the latter is guaranteed to be interpreted unambiguously...
...Congratulations!
You have invented a programming language!
But now, that requires 20x more typing and 1,000,000x more compute to compile to machine code.
Which is the point of the article.
> 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?
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).
Why didnt you vibecode the The nonfunctional requirements?
Not needed yet, we needed to capture the UX first to see if we could create what we'd want to create.
"it didn't replace programmers because we didn't ask it to" seems like a really weird argument to make.
I think the point is that it doesn't "just work" of you don't know what you are doing.
In general I got the feeling that AI saves a lot of work, avoids a lot of big category, but also introduces new but categories that you need to account for.
>Guess what wasn’t? The nonfunctional requirements.
OK, so you test it, see which nonfunctional requirements it doesn't meet, and ask the AI to change the code to include them - repeat until you're happy.
Yep and then you'll have some war stories how things break in production because they weren't initially included in the nonfunctional requirements. Have enough of these war stories and you'll basically be a software engineer. Albeit, a software engineer that has never coded before, but definitely someone who understands production issues.
Today I learned, the difference between an end user and a programmer is access to jira.
>Yep and then you'll have some war stories how things break in production because they weren't initially included in the nonfunctional requirements.
I have plenty of those in decades of human programming too, so...
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.
> they also ask questions, and if they are good, they ask the right questions, something LLMs still have a problem with.
Sure, but LLMs do ask some questions already, and there is no reason to think they can’t keep getting better at knowing the right questions to ask.
Humans also often fail to do this well, and I think we all have experience with developers who do a very poor job at understanding what is actually being asked of them.
Maybe LLMs will never become as good as an expert developer at being able to suss out what someone is actually trying to do when they make a request, but it is certain LLMs will become better at it, and there is no reason to currently believe they couldn’t eventually become as good as the best humans eventually.
They automate the guesswork about what the spec actually intended, so to say. They don't improve the quality of the guessing.
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.
"Time flies like an arrow" is a valid English sentence that one person can find numerous ways to interpret. A programming language that has the kind of ambiguous syntax that natural languages have would not be useful.
What makes agents useful is not simply that they interpret natural language, it is that they are interactive and ambiguous instructions can be corrected when the agent's output is not what the programmer intended. That is not the same as writing out a spec and giving it to a developer to implement.
And does the "agent" say when the agent's output is not what the programmer intended?
No, the programmer does. Human beings are still in the loop.
So might be corrected if the agent's output is found not what the programmer intended.
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.
> This fetishism of “determinism” seems crazy to anyone that has had to spend time really digging into modern JIT based compilation.
Copium.
lol I saw the exact same JIT non determinism argument on reddit. The thing is, if JIT cannot replace a hotspot with a 100 percent functionally identical snippet of code then the JIT is just in time wrong and will be either patched, repaired or orphaned.
So all of a sudden all focus is on the word "determinism", and before even going down this route you have to agree on what aspect of the subject are you declaring to be "deterministic?"
Its sort of like chatting with libertarians, as soon as you agree that taxation is theft and democracy is tyranny then all problems melt away!
> So all of a sudden all focus is on the word "determinism"
Yup. Pure obfuscation.
The point is reliability.
yeah I've never personally used a language that when compiled, has a runtime that has a roulettes wheel chance of going hacking lol
Then you have never used C, C++, or several other popular languages that have ambiguous semantics and undefined behavior in the standard.
Show us a C UB that went off hacking a website.
Does the AT&T long distance network outage count?
of course not lol
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.
That's not what "stochastic" means. You might want to look that up before you keep (mis)using it in conversations about actual stochastic processes.
The term 'stochastic' refers to characteristics or properties that are measured and/or understood on a statistical basis rather than on an individual basis, because they are driven or biased by random processes. What's your understanding of the term, if you're not working from a widely-accepted definition?
Two people interpreting a specification in different ways isn't stochastic because human processing is not a statistical process in any meaningful way. Or, to put it another way: given a specification, you could not reasonably enumerate all the ways two humans might interpret it, much less assign statistical likelihood to those outputs.
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.
The LLMs use compilers, so I am not seeing the challenge here. Compilers do a lot of useful and important things like type checking and agents will typically check their output by invoking a compiler, then correcting errors reported by the compiler.
If anything what agents will mean is a move toward compilers for languages with more expressive type systems that can do more static checks for semantic correctness e.g. F*, which is an extension of F# that introduces dependent types.
That's exactly what I mean, compilers are more important than ever
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.
I think you're missing my point which is more or less that compilers are these original harness and will continue to anchor human-computer interaction as they have always done.
> they shift them into yet another metasystem.
That's a funny euphemism for career change. I'll remember it.
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.
It is something completely new and we should be thinking about it as such. Analogies can help us here, and I think the analogy of "instructing a software team" is a much more useful analogy than "instructing a compiler" and the latter clouds our thinking.
> 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).
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.
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
You're welcome! I'm struggling with when and how to look at the code and what really matters now. I personally work across multiple codebases that each have teams of 5-7 developers, so someone else was always doing the work and I personally never could read or understand all the code.
What I want to preserve in the AI-code-gen age that I still can form a high-level "theory of the program" and be able to dive deep and understand parts of it, both with and without AI. I'm concerned that we're headed towards a world where it's not possible to understand or modify even the simplest programs without a swarm of agents that you direct with incantation.md files.
And if you are looking at the code, you're moving too slow.
If you are not looking at the code your mental model of the codebase will rapidly degrade. Code review serves more than one purpose.
Understanding someone else's code takes longer than writing it.
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).
Yes, definitely. And the same program can run on completely different architectures. But it has a well-defined semantics that must be preserved by the compiler or runtime.
I'm not saying it's all mathematical purity. Programming languages themselves have specs and sometimes they are ambiguous or allow undefined behavior. Compilers have bugs. But the gap between the source code and program behavior is typically extremely thin and language implementations work towards making it airtight.
>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.
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.
I agree. I work in a similar way, and it is quite like managing developers. One difference though: I have no compunction against asking them to write incredibly tedious and long end-to-end tests exercising the user journeys with playwright and an actual db and backend. That helps a lot in making it more likely that regressions will not happen.
How do you judge that the e2e test is correct? Trust it, read it, watch it? I'm watching demo videos.
All of the above, depending on how important it is. The "trust it", however, is always after an independent review by another agent.
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() }
??
Haha, well, I don't because I have no reason to assume this is in the code. In fact, I have reason to assume it is not in the code because the models aren't trained to produce this.
Could there be a less egregious version of that in the code? Sure, but then that's just a normal bug where implementation doesn't match intention, and that happens to human developers as well. I find that Opus 5.5 is so good that it writes pretty good code that follows YAGNI, KISS, DRY, and is fine with writing a lot of tests, so my sense is that the rate of normal bugs is actually lower than with human developers.
Now, if you're assuming malintent on the side of the model creators, well, that's another story. FWIW, in a commercial project, where I also work at the "engineering director level" since Opus 5.5, all non-trivial changes go through reviews by Codex and Grok (locally) and Greptile (on the PR), so there would have to be some serious level of collusion by the labs to produce your example ;)
Well, I just used a contrived example to illustrate my point.
You would be well served to review the code. I don't usually need to do much of that since I work with models edit by edit, with every single line they write approved by me.
You would be surprised at all the errors even Claude Opus 5.5 commits. Not syntax or even basic logic errors, but more insidious errors that betray a lack of being able to see the bigger picture, or serious architectural errors.
If you want example, I have them in abundance. These models still need serious supervision. Unless you are spot checking the code deeply, you won't notice.
"I work with models edit by edit" – That could be the cause of bias: Maybe because you're supervising small step iterations of the model, you notice issues that the model would have noticed itself if you had let it tackle a larger scope by itself. Worth a try in my experience. And the extra review agents make a big difference. Even if it's Opus reviewing Opus. Just by having a fresh context window, the model finds issues it created itself in another session. And with a different model, you get yet another fresh perspective. I find Codex is particularly thorough in reviews.
No, the model will not notice.
How do I know? It several times present deep architectural decisions to me, where each options may seem plausibly good. I rely on my deep architectural knowledge and experience, and knowledge of my vision for the product to steer it to the right option.
[flagged]
If you are checking every line written by an LLM , what would you estimate is the probability it would ever do this?? I look at most code still and I have a high level of trust that it would never do anything remotely similar to this.
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?
"trust" and "responsibility" mean nothing for a fully digital entity who isn't required to feed its family, looking for an eventual new job, and being under pressure for not being fired
Code review, style guides, and a large set of tools like fuzzers that try to check for bad behavior before the code makes it into production. At least that's how it is done where I work and the use of agents to write code has not obviated the need for such a process (in fact we have added agents to that large set of tools and seen improvements in code quality as a result).
> 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.
If a compiler doesn't preserve the semantics of the program, that's a bug in the compiler. Programs in GCed languages mostly don't describe the behavior of how memory is managed and that is left to the compiler and runtime.
Your two sentences contradict each other. Programming languages decide what parts of the programme behaviour they want to specify, and what they leave to the implementation.
Of course, you can redefine what 'semantics' means to say it's the kind of stuff that should be preserved in a translation. But as I said, different languages care about specifying and preserving different things.
See also how most languages (or their specs) don't particularly care about letting the user specify exact timings of operations.
I think this essay has aged pretty well and remains pretty spot on.
Some people will push back that agent development is "natural language programming" but I don't think that's right. I think in that case the agent is the one programming, and the programming still always happens in a deterministic language like Rust/Python/Typescript/etc. Maybe that'll change, but to me at least the other way would be a disaster.
The best exception I know of though, is definitely the Inform 7 language which is for writing text adventures[0]. It has a lot of fans, and I've never gone deep with it, but seems to do a pretty elegant job or marrying up natural language and programming together in a unique way.
Either way, definitely a must-check-out for any language-geeks interested in natural language programming.
[0] https://ganelson.github.io/inform-website/
Good points. I've stood by this position.
"We'll just store prompts in VC and the agent will pick those up", "Code isn't going to exist anymore", "We will just write comprehensive specs of what the software is supposed to do"
This is short-sighted IMO. (Conversely, maybe my argument is short-sighted).
This is exactly why we use code... Natural language is ambiguous, to a fault. Any statement can impact depending statements in multiple ways, which creates this huge dependency graph that has millions, billions, trillions of "plausible" specifications.
It's pretty much ALWAYS going to be easier to just use a deterministic programming language to build the actual software.
We may never need to look at it, we may never need to write it, but having a deterministic specification of what a software system does seems like a much easier jump-off point to work with agents (whether or not we interface with the code).
Feels solved to me... A simple software example that creates users, logs them in, and shows them a dashboard turns into a TON of language and ambiguity.
Must be logged in to see dashboard datapoint A. Can log in with email or username. No log in if their IP is outside of [range]. Can log out. Logging out during a dashboard update cancels the transaction. Cannot see confidential data. Unless the user is an admin. User needs a strong password. Password must contain a capital letter.
Stuff like that just seems easier to parse + modify in code (whether human OR agent). Also, debugging natural language feels super icky. Which statement was it that got the password out of the formal spec?
And my biggest argument, we already HAVE code - reinventing the wheel for something that already works feels misguided?
> This is exactly why we use code... Natural language is ambiguous, to a fault. Any statement can impact depending statements in multiple ways, which creates this huge dependency graph that has millions, billions, trillions of "plausible" specifications.
Devil's advocate here: Why is having many possible implementations a bad thing? Sure, you don't want to half-ass your specifications and fail to pin down your product properly, but if you do pin down what matters, then by definition what remains is discretionary. Formal specs (e.g. the C spec) behave the same as informal specs in this regard.
The real question is whether humans in an agentic workflow can actually identify all of what's structurally and functionally necessary for their product. Either the spec writer must be expert, or the agent must be savvy enough to identify and collaborate with the non-expert. Right now, agents like to just plough through underspecification or bad ideas so that they can deliver as quickly as possible.
You're right - having many possible implementations is NOT the problem here, if a natural language spec covers all the 'necessary' functionality of a piece of software, the implementation does not matter (whether it's implementation ID 4 or ID 27548323)
My argument is more of a forecast, and your last paragraph fits it correctly. I don't think we'll be able to maintain it once we get past a certain level of complexity. Or the maintenance / modification of that specification will be much more difficult to work with, to the point that we'll decide code is the solution.
Yeah, just because higher level programming languages (PLs) emerged doesn't mean lower-level PLs or assembly disappeared. Programming with LLMs in natural language is somewhat like programming in a higher level PL that gets translated into lower level PL, all the way down to assembly.
When it comes to precision it's easier to express instructions in formal languages and I don't see that changing anytime soon unless natural language itself changes drastically, which I highly doubt. Formal syntax, well-defined semantics, reproducibility and composability are traits that make traditional programming languages more reliable and precise than natural language for programming.
> Also, debugging natural language feels super icky. Which statement was it that got the password out of the formal spec?
Everyone's a lawyer now.
On a related note: I’d say that in 90% of all use-cases talking to LLMs to create code is the right approach.
As opposed to creating flows where LLMs do something on the fly.
Code creates determinism, LLMs don’t.
This is the bet I'm making with Croft. LLMs to figure out the messy bits but once it's figured it, software is the better tool. Let the LLM write the software.
This is what software engineers do but just more expensive and time consuming.
"The first 90% of the code accounts for the first 90% of development time; the remaining 10% accounts for the other 90%."
You can do 90% in 1% of the time. The last 10% takes 99% of the time.
right now thats my sweet spot, I want to still be able to be the llm's "dumber pair programming partner" lol
I'm not sure if you're being self depreciating or genuinely desire that, but this isn't an outcome that leads to good software engineering.
You should own and be the expert on the architecture and design of what you're building regardless of whether yourself, an LLM or another person is writing the code.
The LLM isn't "smarter" than you, it's more resourceful. It can (to varying degrees of success) translate your design into code. If you aren't still taking ownership and driving the design of that logic, the LLM isn't going to bring you success with anything other than single-use or hobby applications.
The thing is, if you’re good at designing and breaking down problems and coming up with a good system, code is not likely an hindrance.
You can take any idea and try to flesh it out with pseudo code. Once that’s done, try to convert it to real code and you’ll see that process is fairly mechanical. This is why people says that coding wasn’t an issue for ages. Coming up with the algorithm is the hard part.
People that have an issue with coding either are not familiar with the language/platform or is trying to think with real code instead of pseudocode or diagrams.
ADDENDUM
There are techniques to think with real code, moslty the Edit-Compile-Run workflow coupled with a good editor, or the REPL workflow (also helped by a good editor). Then add a good integration with a documentation system (manual pages?) and you’re golden.
But I’ve been on projects where a dev cycle relies on a 20 minutes local rebuild or one hour CI run. So it can be very hard to try to apply those workflows to legacy projects.
I find this to be intrinsically true in my experience. I was put into senior-level engineering positions very early in my career because I'm a strong problem solver and mentor. I've taken on several positions as a programmer working with a language stack I had little to no experience in without much issue.
Of course there are problems where knowing the code deeply is essential to solve the problem, but those really aren't the majority, if even less than 1% of business problems.
When it comes to what the average developer needs to understand, having a strong grasp on one functional and one procedural language can enable you to solve almost every problem in any language ecosystem, provided the correct resources. If you can do this, you can utilize an LLM for programming assistance well. If you can't, you probably should not heavily rely on one at all yet.
I somewhat doubt the "fairly mechanical" claim. I think when you actually turn it into real programming language code, that's when lots of the edge cases become apparent and then you will face a lot of new questions, that the natural language or the pseudo code didn't cover.
I think those are mostly technical issues (accidental complexity) and those are either documented or there should be someone experienced with the technology on your team (even if that experience came from trying it out).
Critical thinking is essential for nailing down your essential complexity (the core solution of the problem). You can try to define invalid and edge cases alongside the happy path in the pseudo code diagrams version, even if it's a TODO comment.
Of course instructing agent is programming; the agent is an interpreter (albeit in some cases nondeterministic, but that's true for most programming languages that have a function to get current time) of the natural language. How exactly it is interpreted is given by the weights, the context, and possibly the random seed.
But even if we write in Python like foo.bar(), the interpretation depends on what is in module foo and function bar, how they are defined contextually.
You can try to find some difference but most modern AI agents come more close to a language interpreter than not, if the actual instructions are given.
OTOH, giving instructions to people is not programming. People do not consist of binary code that is reliably executed; they are biological organisms subject to environmental pressures such as being tired. They have their own consciousness and will, and can refuse to follow the instructions. LLMs are programs; they cannot decide not to respond.
If instructing an agent is programming then your boss 10 years ago telling you what the software should do is also programming
Having software build software is programming. An agent is software, a human isn't. I can draw a UML diagram, software generates code from that, and software turns it into binary. That still counts as programming I would say, we're just changing the language. Otherwise you would have to say that writing JavaScript is not programming because it's too far removed from Assembly.
Having animals eat animals is food. An animal is food, a human isn't. I can draw up some hay, animals eat it, and another animal eats it. That still counts as food I would say, we're just changing the organism. Otherwise you would have to say that dogs aren't animals because it's too far removed from plants.
It really is the determinism aspect for me. Okay, it’s programming if you sample at temperature 0 with a fixed seed on a fully deterministic inference stack and you have made your prompts the artifact that you iterate on (repo full of natural language that “builds” into the running software it describes with the use of the LLM sampling at temperature 0)
Why is everyone so hang on determinism? Monte Carlo methods are nondeterministic but still programming. We use random generators in many programs.
> That still counts as programming I would say, we're just changing the language.
Anything can be anything it isn't once you start changing the language.
"When at first you don't succeed, redefine success."
> Having software build software is programming. An agent is software, a human isn't. I can draw a UML diagram, software generates code from that, and software turns it into binary.
It's not programming, it's cuckoldry. Articulating the perfect guy, inviting him over and watching him get to do all the stuff you used to enjoy literally makes you a manager.
That's not really what we're talking about though. Compiling verilog from simulink or whatever is totally different than an agent writing code.
If you design a custom piece of furniture, then hire someone to build it, that's totally fine! But if you then tell everyone "I constructed this cool table," well, that's just not true.
If I was brainwashed - maybe (hypnosis is sometimes called programming). But I am not, and AI agent is - it's trained to follow instructions, cannot help itself but do it.
Another difference is the binary code - I can run the same agent on a different computing substrate (e.g. different CPU), but with humans no one can do that. That has implications, we can study or modify AI agent behavior, for instance.
Humans can run on different diets
I've tried Inform 7 before for fun and one thing that struck with me is how incompetent I was with it. I was never sure if something was written right or not because of how free the syntax was. The practical effect of the English syntax was that instead of memorizing just the function an argument order, you had to memorize an arbitrary number of prepositions. And you couldn't even tell what a piece of "code" was doing just from looking at it since you need to parse the grammar with your brain first instead of just looking at the function name.
Inform 7 is a fascinating case study. There are a lot of really neat ideas in it such as “default driven development” but in the end it doesn’t succeed at being a way English majors can write interactive fiction because it takes the same discipline to write Inform 7 that it takes to write ordinary programs.
I like the idea that the code looks like English and is therefore readable, long ago I pitched a plan to make an “Inform 7 for European Air Traffic Regulations” where that readability was a big plus.
To be fair, Inform7 can't succeed, generally, because there is no market for the kind of games that you create with Inform7. Even if I was going to create a game like the kind you can make in Inform7 today from scratch while trying to keep more or less the same UI, I'd still want to add things that the emulators don't support natively, like some way to quickly tell which commands you can type.
That's not even considering the fact that in practice if you were to make a proper game like that today, you wouldn't choose text input because of mobile. You would have some sort of touch input instead.
I do want to say that I like the fact that a game made in Inform7 is a file that runs on a separate emulator, and some browser-based implementation even exist. It's kind of like Java, or kind of like a webpage.
I wish there was something like that for small games in general. An application that you can download to your computer that runs a game file sandboxed, so you can safely play random games that aren't browser games because the environment doesn't provide an API for arbitrary file access. That's pretty much what I wish Flash was, as well.
[dead]
[dead]
But Inform7 doesn't seem to be a NL programming really. I went to read the website (it's a mess btw), and my understanding is that it's built around strict rules, and patterns one must follow, i.e. it's is as formal as Python. It just takes a lot of efforts to look natural. So it's not unlike Perligata which was a joke allowing to write working Perl code in Latin. It just went much farther because it's not intended to be a joke, but the principle remains.
Yes, I think that's a pretty good description of Inform7.
Whether "natural-language-like syntax" is enough "count as natural language programming" is probably a question of definition. For Dijkstra's essay here, he doesn't offer a particular definition, but he certainly seems to be implying something much more fluid and ambiguous than Inform7 is.
I definitely didn't mean to imply Inform7 had achieved the holy-grail of natural language programming or anything.
I think Dijkra's main point he's driving at is here:
> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.
I'm inferring/assuming a bunch, but I think he's saying something along the lines of, programming is useful because it is precise, and natural language is not precise, so attempts to make programming languages more like natural language are butting up into this inherent contradiction of precision. And therefore will end up as worse programming languages (for attempting to be more naturalistic).
In the history of programming languages, I think most attempts to be "more natural language like", such as COBOL or AppleScript, do become worse for attempting to walk the tightrope between natural-language and programming. I think Inform7 is unusual in that it achieves that balance in a way that isn't just objectively terrible (you may disagree) - I think that's mostly because it offers very few programming constructs, and is a tool for writing a kind of prose (text adventure games).
Anyway, to come back around, that was my reasoning for mentioning Inform7 - I think it's an interesting deviation from other experiments in natural language programming so far.
Getting Inform7 to work well probably depended on 'text adventure'/IF culture, since the text adventures themselves rely on this kind of 'restricted natural language' interface to navigate. Conversely, IF developers built up a lot of intuition on how to make pseudo-natural-language input feel natural while keeping the restrictions obvious.
I’ve heard plenty of “tech enthusiasts” breezily talk about how close we are to natural language getting compiled down to machine code but has anyone credible got any idea if that’s even a path? Closest think I can think of is DSL type setups like a much richer version of the stuff Haskell people get excited about but that’s not close to an actual natural language "language"
Of course it's a path. Claude does that already.
Existence proof: everything Claude Code does, including talking to LLMs on GPUs via the Anthropic API, and shelling out to other tools installed on your system, could in principle be compiled into one big self-contained binary (or Turing Machine if you prefer) that is able to take natural language in and produce compiled binaries out.
If you wanted to go a bit harder you could train Claude to output machine code directly, but that's not necessary. Whether the machine code comes straight out of an LLM or out of a compiler that is fed source code that comes from an LLM is a mere implementation detail, there's not any fundamental difference.
It's more than an implementation detail. With an intermediate step of source code compiling & linking, there is a mechanical process checking for well-formedness that would otherwise be skipped. This is especially important if you're editing a large codebase, which even your agent's private-only repo would benefit from.
There are also times when you want the final product to be able to target different architectures and platforms. Generating into a higher level language allows for re-targeting the code by only changing a few compiler & linker flags or runtime/environment config. I would much rather that than hoping the LLM is feature- (and bug-)compatible between generation runs.
Claude also checks well-formedness - if you give it gibberish instructions, it will respond that it is gibberish and do nothing.
On the other hand, there exist programming languages (like Jot, a certain encoding of combinatory logic) where every binary string is a valid program.
Not without some significant changes in how we turn natural language into programs. Yes, you can use an agent to do it, but the agent is going to rely on a compiler for the same reason human programs do: to check semantic correctness. In theory you could build an agent that outputs machine code, but the results would be pretty terrible.
I am not sure we actually want natural language to be compiled directly to machine code anyway. Those rich type systems that Haskell people get excited about are actually automatic proof checkers, similar to Lean, and having an agent check its output against such type checkers greatly improves the code generated by agents. If anything, we will probably see more widespread use of the lambda cube type systems (with extensions e.g. double negative elimination) as agents become a standard programming tool; human beings tend to find such type systems very tedious and difficult to work with, but agents are good at dealing with tedious tasks.
Yes, see this X11 windows manager coded in Assembly with Claude's help,
https://www.phoronix.com/news/Frame-X11-Server-Assembly
I don't know about the "stuff Haskell people get excited about", but IMHO, Haskell is a mathematician's language and the language of mathematics isn't a natural language. Dijkstra himself was also a mathematician, and his positions regarding programming languages features like 1-based indexing [1] are already conflicting with practice, the famous case being Lua which receives mixed opinions about it. I find for instance 1-based indexing more "natural", and that's coming from someone whose second and third languages are assembly and C (the first being... Basic).
Yet the point about DSL is interesting, in particular internal/embedded DSLs [2]. I lied a little earlier, my third programming language was actually Forth. His creator said in 2001, "When you devised an application you wrote a hundred words [i.e. functions] or so that discussed the application and you used those hundred words to write a one line definition to solve the application" [3].
I've been trying to do that exactly that in other languages, make it so that the code expresses "naturally" what it does as much as possible. When you succeed, people call your code "beautiful" or "elegant" (nobody ever told me that :-) which, I think, subsumes "naturality".
This is of course harder to do in low-level languages such as the ones I mentioned (except Basic maybe) because you get caught in details such as memory management. But high-level languages are not exempt of these problems (and contrary to Forth or Lisp, their syntax is often written in stone). Then there's essential complexity [4], which can be "unnatural" no matter what, like thinking about things in a concurrent programming context, with languages that don't natively support it like they support automatic memory management (i.e. garbage collection).
The topic is dangerously close to "readability", which is known to be 80% subjective.
[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...
[2] https://en.wikipedia.org/wiki/Domain-specific_language#Domai...
[3] https://www.ultratechnology.com/1xforth.htm
[4] https://en.wikipedia.org/wiki/No_Silver_Bullet
Dijkstra's personal language design (GCL) actually used anything-based indexing -- you specify the lower bound explicitly when you declare the array, so even if indexing starting from some runtime value k (e.g. k=7, k=b.lower-bound for some existing array b, etc.) is most natural, you provide that as the lower bound. Then a(i) would be translated to e.g. a[i-k] in compilation.
IMHO instructing llms is programming - the analogy is not perfect but it is so close that it is quite useful. Programming is instructing a machine. We have now two types of programming - the traditional one that follows strict semantics and the new way of programming by prompting. The article still holds by showing the limitations of this new kind of programming.
I don't have strong opinions on when it's ok to use the work "programming" or not, but I think if you're using claude-code/pi/open-code/etc to produce something like a website or application, the "program" is the code the LLM outputs, not your prompt etc.
I don't think I'd want to call it "natural language programming" in the way Dijstra's implying here unless the prompt was the thing that was actively being executed/ran/whatever when someone loads your app or website.
I've seen some newer testing frameworks where you prompt for the outcome you want under a specific scenario. The first run is a LLM agent that figures out the steps but those steps are then used for recurring runs. If something fails, it goes back to the agent loop to see if it's an actual error.
This works well in e2e type tests where the test implementation might change but the customer experience hasn't.
So maybe there is a hybrid approach in our future.
Yeah, that's an interesting case study. It's pretty common practice to do something like llm-as-a-judge if your programming agentic systems.
I think those are different from pure "natural langyage programming" though because there's normally code you've written that's calling out to the LLM, so it's within the context of written code.
I think this, and lots of other comments are so interesting. There are a lot of different increasingly complex ways LLM outputs and coding are being tied together by people, that I hadn't really considered.
Today I learned that the CEO of my company was a programmer all along.
So product managers have been programmers this whole time after all.
>So product managers have been programmers this whole time after all.
The entire point of the article was that human language isn't suitable for instructing computers, and you somehow make the leap to "humans instructing humans must be the same thing".
Reading comprehension must be a thing of the past at this point.
I understood perfectly. My comment was meant to illustrate your exact point in reply to the comment I replied to.
Reading comprehension must be a thing of the past at this point.
Product managers did not write instructions to a machine.
They instructed an intelligent entity.
'instructing a machine' is programming - how about this?
Yes, unlike those instructing an LLM.
The lack of intelligence in the loop is the foolishness the title refers to.
See cloud products like https://www.microsoft.com/en/copilot/products/copilot-studio
Traditional coding is left for MCP tooling, and even that can be generated as well.
I read it the same way as well Natural language programming would be more akin to my prose staying on file and the computer interpreting it again every time it is executed.
That makes no difference insofar as the premise of the article is concerned.
How one defines natural language programming seems extremely relevant to the source article.
I've had the same view since coding agents appeared. LLMs are good for summarizing, thus I tend to use them to understand code. However, the more I understand a code base the more I tend to be more picky with the agent. While the less I know about the code base, the more open I am to let it do its thing.
I've realized that the agent doesn't write 'good' code, instead my vague understanding of what I expect makes me think it does. When I look at the AI code, I see that there are more nuances and decisions that needed to be taken before writing the code. One would say that a spec would suffice, but then I remember TLA+, developed by Leslie Lamport to help developers think critically about their programs/algorithms. Sitting down and formally writing what I want to do helps me better understand the problem and come up with a real -not vaguely defined- solution.
> I've realized that the agent doesn't write 'good' code
No one writes 'good' code. Everyone only writes 'good enough' code. You should always assume the existence of flaws and bugs.
You call "good" code the one that doesn't have the mistakes you know. But you'll never know everything, even if you are as smart as Dijkstra.
Lots of people started commenting recently that good code doesn't exist and everything is the same kind of shit.
First, it's bullshit, some code is better than others. Also, I wonder what caused that.
I think the difference is between communicating to a purely mechanical being versus communicating to an intelligent entity: unlike programs, which are purely formal languages, we write textbooks and papers in a mix of human language and formal language. often we introduce "just formal enough" notations. and the intelligent reader will read in-between, inter legere literally means just that: reading in between. filling the gaps, connecting the dots.
and in practice I find it _very_ effective to express key ideas with some formal language where applicable. a little ebnf here, some snippets of python or prolog there or other languages there. and I find llms wonderful at filling in the dots and, and that's the topic here, to translate our semi formal conversation into rigorous, formal language.
and I dare one step further: I also find llms useful in formulating and refining technical proposals, for human peer review and llm driven implementation, and of course these proposals mix natural language prose with semi-formal and formal detail. think PEP-12 and PEP-1 style. and these then get work packages which each loop in a spec as in sdd.
seems to work just fine so far :-)
I'm going to take the contrarian view and say that formalism without jargon, friction and gatekeeping is just natural language.
I've been going through an identity crisis for a year now as I realize more and more that nearly the entirety of what I know comes down to arcane incantations producing transpilation instead of magic. My tech career was just converting specs from clients and employers into machine code, with extra steps.
To move now at the speed of thought and let AI complete whatever tedium was preventing me from getting real work done has been a revelation.
To the point that I fantasize about the day I can leave tech behind and get back to the human experience. No longer drowning in the unending workload that demands ever-increasing productivity for the same pay, but finally able to say enough's enough and provide time/money/resources for myself and eventually the community at large outside of the hierarchical economy.
If we can't automate our livelihoods with AI, then we don't have anything.
> I'm going to take the contrarian view and say that formalism without jargon, friction and gatekeeping is just natural language
Try to define a specific item like the closest cat to you so that anyone, just from reading the definition, can recognize that cat anywhere. You could write a whole book and not be done. Or you could stamp the cat with some id (symbols) in and refer to that. As long as that id is not repeated (rule), the system is ok.
Formalism is defining stuff, and add rigid rules that are consistent with each other. Once that done, it allows anyone to reach the same thinking location as the original person. Formalism is a knowledge transfer tool.
> My tech career was just converting specs from clients and employers into machine code, with extra steps.
If all you did was that, I’m quite sad for you as yourself should have automated your job to remove that tedium.
I would describe my job as designing a system that respect all the constraints of the situation. Some of them comes from specs, some comes from the technical platform, and some are just future possible interactions. The system is what I modify, coding is just how I do it.
When I see people abandon their work to AI, the other consequence is that they abandon their control of the system as well. They can’t explain how it works, what’s its reliability, and whether it can be improved (or part of it reused in another context).
> My tech career was just converting specs from clients and employers into machine code, with extra steps.
I guess the thing about that process is, you inevitably complete an incomplete spec. There are always fine details that will never be decided until they're required to complete the implementation.
You made it further than most. At least you're realizing our identity is formed off what we know, the more we know the fewer options we have.
The expansion of knowledge is what ends societies and erodes civilization but produces religion.
Perspective of the religions is that I is the devil, the unaffiliated individual's perspective as opposed to we. All the religions teach fasting is abstaining from I want and pursuing we need.
We drive ourselves to the truth of what matters by eliminating waste as much as possible for 6 weeks
Automating things at the cost of our own air and water is slow genocide.
Then stop drinking and stop breathing.
You spend more of both air and water than a DeepSeek flash does when with an NVL72.
Source?
Is all AI DeepSeek on NVL72?
Is the next evolution of AI mania really ”achtually, humans are the pollution and must be destroyed”?
> Source?
Ask your mfing clanker. What do you think I am, grok?
For all I know, yes you are.
Grok, please provide sources for the great-grandparent’s claims.
You just got to upload your mind to the cloud brah. Then you can live rent free in the tech bros data centers.
[dead]
Well we've been doing exactly this for 200 years! IMO the use of fossil fuels for manufacturing novelty products that go straight-to-landfill, and daily suburban commuting to bullshit jobs, and diverting water to inhabit cities in inhospitable deserts, is a greater cause of our 'slow genocide' than AI will be. So why would we stop now, when we couldn't be bothered to even slow down before? (Annual carbon emissions aren't even trending downward, much less getting to net negative!)
So while I also foresee and lament humanity's self-genocide, it seems a bit hypocritical to get salty about AI "automation" while broadly accepting our industrial civilization's trajectory.
> Annual carbon emissions aren't even trending downward, much less getting to net negative!
They were trending downward in the US. AI usage in the US did change that single-handedly. I understand carbon emissions are a global problem but since they are subject to political remedies, the solution to the global problem is solving the same problem within each political jurisdiction.
Natural language is full of nuances and implicit cultural and domain specific connotations. LLMs work because they have been trained on massive corpus of materials that encode some (but not all) of those hidden meanings.
With specification driven development, the prompts need to be very detailed in order to produce exactly what is required.
Humans also work because they've been trained on a massive corpus of materials, spanning like an average 15 year period or more. And humans too need to be prompted, sometimes everyday, with meetings and whatnot to produce exactly what is required.
I used to do software dev without meetings. It worked just fine. I would send whatever I did once it was done, and get direction on where to take it next. Maybe this breaks down in companies with more than a few leaders, or where the leaders can't otherwise keep in sync.
Also gave me plenty of opportunities to go above and beyond. I miss when that felt safe.
This depends entirely on how well the requirements have been communicated, right? If you could go for long periods without meetings on large projects, it means either you had great PMs or you’re very good at collecting relevant info and planning in advance. Or, it could mean that your target was quite flexible and open to interpretation. I don’t doubt it, and I’ve known some developers who could do what you did, deliver something great without that much back and forth. I’ve also known many developers (probably most TBH) who will focus on problems the customers don’t have and endlessly go down rabbit holes that have no bottom. Heads down software engineering for big-O and data structures seems to be a lot more fun for some people than fixing weird hard to repro bugs with vague repro instructions that customers complain about. Many very good devs still need to check in and iterate and get some steering, especially if the requirements have not been well or fully explained… which in my own experience has been more or less always. ;)
Maybe my definition of meetings is different than yours. To me, meetings are voice or video calls where multiple people talk about progress and direction, raise issues to the others, etc. and the leaders can make calls across the whole team at once. Staying in constant communication doesn't count as much because it's more async and incremental.
You’re right, my definition sounds different. Your comment left me with the impression that you meant you weren’t talking to anyone. Meetings in my book are any scheduled discussions, regardless of how many people are involved. 1:1s are still meetings.
1:1 meetings are still meetings, but casual messages about progress and direction (without a scheduled time block or synchronous call or whatever ) don't count to me.
Maybe those were some very detailed requirements you were getting, the deliveries were straight-forward, or you already knew the space pretty well. Or you're the only dev there. Somehow most teams just keep tripping over each other and need near constant management to ensure they're delivering what the stakeholders expect.
They weren't particularly detailed, but I did know the space quite well. I was a heavy user of other products of that type, and knew very well what I wanted out of one.
The problem is that your case is extremely rare. Most people work on systems that they never would use themselves or even know existed if not for working on it.
Wherever I work, I try to turn the system into something I would use myself. I am not always successful in this, but it drives a lot of my UX decisions, and it seems to work fairly well.
> I used to do software dev without meetings. It worked just fine. I would send whatever I did once it was done, and get direction on where to take it next.
You didn’t collaborate with other engineers? Or what if the spec you were given was unclear in places? Forgive me, but the style you describe sounds incredibly collaborative, super transactional.
Funny story actually, there were a few other engineers but not very much collaboration. They were resistant to sharing source code or algorithm details, so I had to essentially reverse engineer how their other products worked. I was good enough at it that I came up with several features they didn't know were possible. They eventually ended up letting me go and cloned my design, which I thought was weird, but it was developed for them in the first place so not a big deal.
The lengths to which devs will go not to collaborate.
To be fair, it's a very secretive industry, and betrayals are quite common. Worse, a lot of those betrayals are done on pure impulse without even thinking through the consequences first, so you can't actually build incentives against it because they'll just be ignored.
> Humans also work because they've been trained on a massive corpus of materials,
Massive? My introduction to programming (from noob to beginner level) has been like only 10 books worth of content. Including some alternative pathways like 3D, security, system administration,... To this day, I don't think I've reached 50 books of materials. And If I counted everything it would be still small.
Human learning is very efficient (not time wise, but cost wise, and even training data wise).
You're forgetting all the schooling before that, which taught you how to read, do math, etc. And the general daily experiences of just being a human being interacting with the world. Magnitudes more data taken in than any language model.
> Magnitudes more data taken in than any language model.
Ah, yes, I can fondly recall reading and internalizing every word available on the internet when I was young...
You should check out how much raw data just your eyes process for every second they're open (although a significant amount is discarded before it gets to the vision center, but still). Then consider the other senses also constantly doing their thing.
The vast majority of people don't internalize most things. Some internalize even less. It can become a big issue with things like dissociative disorders. (I have some experience with that)
LLMs don't internalize per se (assuming something akin to conscious intent). The foundation of a model is comparable to a human's daily experiences of just being, then the fine-tuning is comparable to formal schooling, and finally the prompting is comparable to meetings for workplace tasks.
I said nothing of LLMs. I don't compare the process of LLM training to any form of human education because they are fundamentally dissimilar. LLMs are engineered mathematics and cannot self-train yet.
There are of course parallels. Anyone who's done ML should be able to see it at least. But yes, there are fundamental differences in methodology due to the mode and level of access: with a human, the only way is to go through the senses and there's no - easy - way to affect the learning substrate; with a LLM, data is directly injected into the substrate, which is also human-architected.
Organic beings have more than just the senses, they also have higher level concepts and complex internal incentives. This is more important than the senses being the only method of access, I think.
Language models currently are mutated in the direction of exactly producing the desired output data, but gradually enough that they generalize across inputs in a way that appears understanding. It is more similar to compression, though, at least before a randomizing sampling strategy is applied during decode.
Anyway, circling back to my original topic: no organic being has the capability to integrate all the data arriving from their senses! They typically get more and more selective with experience, picking out only the pieces of information that are still important. Some are more selective than they're supposed to be, by choice or not (such as with dissociative disorders). In any case, the raw quantity of data coming through the senses becomes almost entirely irrelevant.
A picture is worth a thousand words. How much video data was your brain trained on?
Only if you ignore the billion years of pretraining…
Yep, LLMs work to the degree you don’t care shout the choices made. That’s why it’s great for demos and starter templates.
But for mature software eventually every single detail matters.
After reading this essay, I wonder: what if program code was withheld from training data? Then how useful would LLMs be for programming?
> I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.
He's still quite correct. I generally see a machine as being "programmed in" whatever is tracked in source control. So as long as your git repo is tracking changes in Java, that's still programmed in Java, even if the Java was generated with the assistance of LLMs. I may consider the thesis of this article invalidated only when the majority of repos start tracking natural language rather than programming languages as the primary artifacts defining behavior of the software.
That would be one definition of "source code". But then there's also the definition by the Free Software Foundation as "the preferred form of the work to making modifications to it". As prompting LLMs becomes the preferred form of making modifications, I wonder if a lot of open-source repos will unwillingly become "closed (prompting) source" over time, with intricate legal consequences.
I still don't know if I'd agree with you. I think:
> the preferred form of the work to making modifications to it
Implies what you point to when you want to know where to make changes.
That wouldn't be a prompt - you might use a prompt to make changes, but the thing you're making changes to, certainly at present, is your java/python/rust++ /whatever codebase.
Lots of projects, even fully vibecodes ones, don't push and include prompts in their repos. But they all push the java code (sticking with java as an example for the sake of argument).
I can't imagine that working on a project where the java code is omitted, and people make changes to the software just by editing the prompts would go well. It's an interesting thought experiment, but I think you'd find it very hard to work on any kind of team where that was the practice.
> Implies what you point to when you want to know where to make changes.
Where do I point to when I want to know this? On a large and mostly LLM-generated codebase, I might dig through the code myself to find what needs to be changed where, but I would probably prefer to ask an LLM to do this.
Now if I had access to all previous prompts that were used in generating the codebase, it might very well be the case that I would prefer to work by changing those prompts and generating the whole thing again. In that case, the LLMs would basically turn into a compiler and the prompts would indeed become the new "source code". This is clearly not (yet?) a common approach to software development, but I wonder if it may become. Or should.
If one uses LLMs to generate the code, and others need LLMs to read the code, isn't this awkwardly close to someone publishing only compiled binaries and others then having to reverse-engineer these binaries in order to know where and how to patch them? Maybe the handicap is less grave, as the difference in strength of LLMs understanding code vs writing them isn't as huge as of decompilers decompiling vs compilers compiling code - but I think this difference still exists. It's still an advantage to have knowledge of the "secret" prompts that were used in generating the code.
True, and as such it needs to be considered like any other code output from a one-off code generator, with at least minor added risks from non-determinism and, in the case of LLM-as-a-service, potential lack of model availability in the future.
This means maintainability is as important as it is for hand-written code. Which varies, of course: there are plenty of valid use cases for one-off throwaway code. Just don’t assume checking in slop is suddenly cost-free “because AI”.
Natural language as code has existed for thousands of years. Today we call it legalese.
It's excruciating to write, excruciating to read, and even legit geniuses with decades of hard won experience still leave room for essentially infinite interpretation. laws and contracts are all still swiss cheese and can be made to demand or prohibit whatever the party with the most money or other influence wants.
If law was code, there would be no need for judges to make decisions. Instead, a "judge" would be someone making a mechanical derivation of the judgement given the situation and the law.
The law is rather a complex set of guidelines which need to leave some space for interpretation, so that additional relevant information for the situation at hand can affect the decision.
Law is literally code, and xml in the sense that it attempts to define itself as well as it's payload, and everything you said was exactly the point.
What is a sandwich?
> Law is literally code
Only the legislated part of law is codified. In our American common law system, case law is, by definition, uncodified. So what judges are doing, is taking the codified legislation, and applying case law decisions in layers on top, to reach a final decision.
What Dijkstra said still holds true, and the essence is consistent with Brooks' discussion on essential complexity vs accidental complexity. I do think one thing has changed, though: when someone asks AI to implement XXX with very vague English, the implicit ask is picking the best[1] ever solution that someone else has done to solve XXX. For instance, if I ask AI to extract the Japanese subtitle of Shirojima show and convert it to an epub with all the nantural and cultural explanations, I was assuming that AI will fill in the blanks and do a good job and AI did. This won't help expert, but does it matter? Being good enough can be good enough to take away many people's jobs.
[1] For many people, the result is actually the mean not the best, but it's another topic.
Todays natural language program won't work tomorrow due to unstable nature of natural language.
Apart of natural evolution of meanings, look at Orwellian limitations some (cloud) models impose on is that our natural language program become illegal. Due to topic or combination of words the program needs to be flagged and soon likely reported to three leter agency.
Next, RMS would ask: can you make your own natural language program compiler from scratch? I know we have (very expensive) local models, but wait until GPUs get a propper online subscriptions to work and surveillance taps.
Dijkstra elegantly explains why AI systems are effective at mathematics and programming but much less effective when writing prose or other realms where what is good is nebulously defined:
> "The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid."
LLM interfaces on everything these days equate to touch screen on cars. It is definitely a useful tool, but generally speaking, that's not how you'd talk to your computer.
NL programming is foolish to me not on technical grounds but on practical ones. It is most valuable when the business wants to understand how an already working thing does its job.
I have observed several samples where the business, when provided with a natural language configuration opportunity, will wind up staring blankly at the textarea until the original developer gives them a complete starting point.
I don't think "natural" language makes much of a difference unless you are already skilled in the art of developing useful engineering specifications. I often have to babysit the business through very basic boolean algebra concerns despite everyone having 3+ decades experience dealing with this stuff. Making everyone speak python could only make this worse, not better.
I use HN to keep myself warmed up on natural language expression. The difference between developers who post here prolifically and those who barely write one email a month is fairly shocking in my experience. If you intend to use a specific instrument to accomplish a complex task, you need to practice it constantly. Ideally every single day. There is no substitute for this. There never will be.
> I have observed several samples where the business, when provided with a natural language configuration opportunity, will wind up staring blankly at the textarea until the original developer gives them a complete starting point.
A lot of people lack “system thinking” when they can break down something into a set of elements and describe the relation between them. Once that done though , they can understand a part and manipulate it.
For some “system thinking” is innate. It can also be learned. But it’s a required quality in engineering where you need to create a solution where there was none.
Possibly relevant:
The experiment in designing a language that resembled natural languages (English and Japanese) was not successful. -[1]- William R. Cook, AppleScript, HOPL IV
Now our new LLMs are different, because they don't use "language the resembled natural languages", but actual natural language. But the lesson is instructive nevertheless, because it gives us some empirical evidence to compare to Dijkstra's theoretical arguments.
And this is that natural language is at best a two-edged sword. Yes, there are benefits, but there are also huge drawbacks. And one problem is that the benefits are front-loaded and the drawbacks are long-term problems.
To me, one thing we are missing is that what LLMs do for us actually has 2 parts.
1. It allows us to use natural language, allowing us to be fuzzy.
2. It allows us to specify what we want at a much, much higher level than usual.
With our LLMs, these two are intrinsically linked. I think the whole would be much, much more valuable if we could separate them.
[1] https://dl.acm.org/doi/10.1145/1238844.1238845
The most obvious reason natural language is a poor choice for programming is ambiguity.
Time flies like an arrow.
I saw the parade coming through the window.
For small programs that basically duplicate something else with a few tweaks, sure, natural language can be fine. "The same thing as A, but with a red border, and add a new button to do X." Beyond that things start to get tricky.
Interactive programming has far more value than natural language programming, and agents also give you that. An ambiguous natural language spec. that leads to the wrong result is less problematic when you can interactively correct the problem; "No, that button should have been on the left hand side." It is the new version of REPL.
>We would need all the intellect in the world to get the interface narrow enough to be usable,
It seems Dijkstra is describing potential calability of LLM model trained on published collective human knowledge enabled by the Internet
>and, in view of the history of mankind, it may not be overly pessimistic to guess that to do the job well enough would require again a few thousand years
Since the article was written in 1978 (about 50 years ago) and from the time the computing resources of CPU and RAM has increased exponentially until the LLM first appeared in 2020s, it seems the thousand of years prediction is merely several decades accelerated by the rapid advances of computer and communication systems technology spearheaded by companies like Nvidia.
There’s em dashes in that 1978 article.
The typed original [1] has double hyphens that have been converted to dashes. His typewriter (Hermes Ambassador) was fixed pitch.
[1] https://www.cs.utexas.edu/~EWD/ewd06xx/EWD667.PDF
Oh look at the last paragraph on the first page. Manually justified:
How does one even achieve that with a manual typewriter?It's coincidence in this case. Proportional typewriters were made but this wasn't one of them.
Wasnt the original famously in written with Fountain pen? And the typed out version reproduced much later?
He typed them until 1979 when his typewriter stopped working correctly.
Well - in this case the EWD in TFA - has a footer that says.
And so seem to be the case with most of the other EWDs I looked at as well.That's the HTML version, which Dijkstra did not himself produce. People took the handwritten and typed EWDs and transcribed them for the web. If you look at the PDF scan of the source document for this one it was not transcribed by Tristram Brelstaff, it was typed by Dijkstra.
Luca Cardelli created the handwritten typeface Dijkstra font in the late 1980s, to mimic the distinctive and precise handwriting of his colleague Edsger W. Dijkstra.
It shipped as a free PostScript font with NeWS:
https://www.donhopkins.com/home/NeWS/fonts/Dijkstra.ps
https://lucacardelli.name/indexartifacts.html
(You have to click on the "Fonts" tab, there's no direct link to it.)
Dijkstra [.ttf (2013 updated version by Reuben Thomas)] [.zip (old PC)] [.hqx (old Mac)] [Preview.pdf]
A beautiful handwriting font of unknown origin, first popularized by E.W.Dijkstra. Excellent for slides that appear to be carefully written, and for short, deep technical notes.
https://lucacardelli.name/Artifacts/Fonts/Pc/dijkstra.ttf
https://lucacardelli.name/Artifacts/Fonts/Pc/Dijkstra.zip
https://lucacardelli.name/Artifacts/Fonts/Mac/Dijkstra.sea.h...
https://lucacardelli.name/Artifacts/Fonts/Dijkstra.pdf
His namesake algo was also written entirely in his head in about 20 minutes at a coffee shop! https://harlepengren.com/dijkstras-algorithm-20-minutes/
I'm not native speaker but the TOC smells llm to me
Yeah looks like it. Was just trying to search up a writeup of it, was pretty sure I remembered reading that a while ago.
It can only mean one thing.
Get out the Binford 6000, it's Tool Time?
It's not just em dashes, it's 1: typewriter em dashes aka `--` and 2: usage of them in pairs, like parenthesis, that is completely different from how LLMs use them.
Proof that Djikstra was an AI model!
Literally stop the presses
Unreadable.
From a pragmatic perspective, I'm with Djikstra for a very specific reason.
Clearly it is possible to "program" in natural language. I have one- and few-shotted a number of apps that meet my requirements.
Generally as the number and complexity of requirements grows it becomes harder to parse them if they are in a poorly structured natural language format.
I can't think of a time that I have provided specifications in natural language with sufficient rigor that if I was to run the prompt ten times, the ten generated programs would look identical or provide exactly the same outputs for the same inputs under all situations.
Whenever I find that I need the rigor such that the code could be considered to be a cache, not an authoritative artifact, I find domain specific languages to help me to ensure the comprehensiveness of my requirements around the dimensions that I care about.
I also find such structure to aide collaboration with other humans trying to understand or extend such specifications.
So I think for code to become ephemeral, for substantial pieces of software that require the documentation of many complicated requirements, writing such specifications in natural language is not the best interface and would require substantial support from LLMs to project them in ways (flow charts, UX demos, etc) that humans could reliably understand and mutate them without introducing regressions.
But we'll see. Last year I still thought git was an appropriate version control system to use!
This feels so incredibly relevant for today. This also makes me think about the cognitive delegation problem - structured interfaces in machines and structured methodologies in mathematics helped humans build structured thoughts to express abstract intuition. With machines starting to speak natural language, it's probably not too far fetched to say that humans will eventually stop organising their thoughts, which will turn their thoughts into a kind of brain fog.
Isn't philosophy the best example that you can organize your thoughts in natural language? Of course, there is the tradition of analytical philosophy. However, the vast majority of philosophy was and is written not in a formal language.
Philosophy, analytical or not, is actually math underneath. You use facts to derive other facts, typically about existence. It has a mathematical base. Reason why most ancient philosophers were mathematicians.
When comparing it to math, this always felt to me like a clear limitation in philosophy, though. Just look at how philosophers try to argue about "logic", compared to mathematics' elegant descriptions.
How do philosophers argue about logic?
This article shows every now and then, and it's a must read. Indeed the natural language programming requires massive clusters of gpus just to make a half baked crud app
>And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.
That could just as easily be written today
Fun fact: there are over 600 definitions of the word "run" and over 400 for "set". But yeah, English is really precise enough for programming.
How many times have we seen that there's been a spec for something and the programmers write something that is exactly like the spec said but was completely wrong?
> (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.)
It is perhaps for the best that Djikstra did not live long enough to witness this problem become orders of magnitude worse.
Programming in natural language still doesn't work, Btw! whenever you're using a Ml model to either autocomplete code or as an agent, you're not really programming in natural language but "delegating" in natural language!
The old skeptics weren’t wrong about the foolishness of natural language as a programming language, it's just that they assumed the only possible intermediary way to "write" code was something compiler-like! they never really thought about a future where ai would become good enough to translate natural language instructions into runnable code
Yeah - in my own personal experience building AI products this still holds true. And you can see it in the way they behave themselves, they don't really write prompts for themselves to use in the future (say CLAUDE.md) when they need the output to be deterministic. They write code for it, then write tests around that code, then fix the bugs in that code.
Yes it all started with "natural language", but even AI has an understanding that you need more structure than natural language when you want deterministic results.
My take is that this is largely right. To be specific though, I feel the future is natural language commands that will be translated into a proper language through llm systems.
In this way, the generated output, whether used as a proper program or just some scripts to do small activities, they can be audited later, reused, and tested even if a client created the request in plain language.
We would then mostly be translating bugs from english to the underlying language and bugs would mostly be people speaking ambiguously or just misspeaking
The human equivalent of LLM could be to build a wiki / semantic graph of all algorithms, tutorials, framework docs, stdlib docs and attach a make file at the end each node.
I've been stating it elsewhere, attention has made English into a context aware sensitive programming language by resolving ambiguities through anaphora and coreference resolution. Inform7 did limited anaphora resolution - it - but LLMs are able to resolve "move that file to this folder".
> Remark. As a result of the educational trend away from intellectual discipline, the last decades have shown in the Western world a sharp decline of people's mastery of their own language: many people that by the standards of a previous generation should know better, are no longer able to use their native tongue effectively, even for purposes for which it is pretty adequate. (You have only to look at the indeed alarming amount of on close reading meaningless verbiage in scientific articles, technical reports, government publications etc.) This phenomenon —known as "The New Illiteracy"— should discourage those believers in natural language programming that lack the technical insight needed to predict its failure. (End of remark.)
Tell me about it! This has only gotten worse in the meantime.
> From one gut feeling I derive much consolation: I suspect that machines to be programmed in our native tongues —be it Dutch, English, American, French, German, or Swahili— are as damned difficult to make as they would be to use.
Sadly, this is no longer true. The floodgates are open. And as it turns out, many people get really angry if you curtail their ability to talk nonsense, even if the result it supposed to be software.
His point is moot. His argument considers that natural language would be the direct expression of the program. It's not. It's an abstraction layer, that is then converted in formal language. He could have foreseen that, given he takes explicitly the example of machine code and high-level languages. High-level languages do not replace machine code, they translate into it. Just like natural language programming translates into high-level language.
True, in part.
Consider the role of a Business Analyst, in corporate environments. He is the person that talks to stakeholders and users and translates their "natural language" wishes into piles of semi-formal language (UML anyone?). Later on this will become fully formal language.
But I think Dijkstra point is more that we can't fully automate this process and let the machines do the formalization thingy. I used to believe that but I've seen LLMs doing things that really, really surprised me.
In the end I still hold hope in the old saying: "make a something idiot-proof and someone will just make a better idiot". We see LLMs doing magic if they're used by people that know what LLMs are doing. I never saw LLMs doing magic in the hands of idiots.
What do you commit? As long as you commit high level code to your repo, you are still programming in that language. You don't commit machine code because you know it will be always the same after compiling. And it also doesn't matter that you are using very high level tools and basically don't ever look at or even understand your programs any more.
I don't think reproducibility is relevant, here. Otherwise, even your compiler example doesn't stand. No, machine code is not always the same after compiling high-level language. First, it depends on compiler. Clang and GCC won't produce the same output. Then it depends on the version of your compiler. GCC-9 and GCC-11 won't produce the same output. It obviously depends on the architecture too (arm vs x86), but even then, it depends on details about current configuration of the system you're building it on (CPU flags, hardening, etc). And then of course, there may be things randomized on purpose at each build, like randomized memory addresses to make the binary less exploitable.
Yeah I should have been more precise. What I was suggesting is that the behavior of the machine code will be always the same after compiling (assuming no compiler bugs).
Anyway, my work process is as follows: I have the agent write the code, and describe it's purpose etc. via comments so another session can later pick it up easily without me having to explain everything again. That's what I commit. Sometimes I even look at the code :)
What else could I commit? At the current state of the art, I could commit the whole natural language session that lead to the code, instead of the code. When I later check this out in a fresh environment (without the artifacts the LLM putted out), I'd just load the most recent version of the conversation as an initial prompt. Or I could want to check out the conversation at a point two months ago and rebuild the program from there.
Would that produce a program with exactly the same behavior? I don't know. But if it doesn't, the essay's argument is not moot. Not yet ...
Interestingly, it _is_ possible to get the exact same output from the exact same input with LLMs. For example, with llama.cpp/llama-server, you can set the temperature to 0, define a seed for the randomizer, turn off caching so it doesn't mess with the inference, and you would get the exact same result every time. But it's largely an academic distinction, because 1/ change a letter in your prompt, and it's over… and you're certainly going to want to change your prompt at some point, and 2/ model publishers have recommendation about the temperature setting, usually between 0.7 and 1, so your reproducible results… might be terrible at solving actual problems.
That being say, I really like the idea of committing our prompts. I can see a possible future in which that would be our work: write precise specs so that you can generate the program again with an other model, in an other programming language, and get the same behavior. Which sounds a hell lot like… a RFC. :)
We may be the culprit here, by the way. Maybe the only thing missing is us taking "prompt engineering" more seriously. It would be specification writing, really, or protocol design. I think it might already be possible, from an experience I had. I made Codex write a POSIX vi implementation from POSIX ex/vi specs. It took it a week-end, but I now have a POSIX vi, with only added on top multilevel undo/redo and syntax coloration, and without the baggage and instability of nvi2, I'm an happy man. I've been using it for more than a month and still have to find a fault to its POSIX implementation (and there are _a lot_ of details in POSIX vi specs). I think models are already there, when it comes to implemented behavior predictability, it's just us who are not precise enough in our specifications.
I built a music player by talking to Claude Code in Japanese, and I can barely remember a time when words failed and I had to fall back to code. For example, I asked it to "keep the sidebar's shape, but add margin on the top, left and bottom so it looks like it's floating a bit — you know what I mean?" and it got it right on the first try.
I am surprised that cs.utexas.edu uses a TLS certificate chain who's root is eMudhra's "emSign Root TLS CA - G1".
US institutions are on eMudhra certificates through inCommon, yeah.
AFAIU this particular chain is not compromised.
I untrusted all of their certificates after their (disgraceful) press release (https://news.ycombinator.com/item?id=50195110).
[flagged]
[dead]
"...some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate 'the ease of programming' with the ease of making undetected mistakes."
What a spot-on sentence.
All I gotta see is “utexas.edu” and “(197X)” and I know it’ll be a banger that’s still relevant today.
Inform7 disagrees; altough you can use Inform6 which is like a really simple OOP language to create text adventures.
I appreciate inform7 is quite human-readable, but it's not free form.
> The virtue of formal texts is that their manipulations, in order to be legitimate, need to satisfy only a few simple rules; they are, when you come to think of it, an amazingly effective tool for ruling out all sorts of nonsense that, when we use our native tongues, are almost impossible to avoid.
Hence, when communication via formal text results in nonsense, it is very clear that the originator of that nonsense is you. With LLM-generated code the nonsense may be much less obvious and when it does surface, you can feel like it's not your fault at all. You are a genius and the LLM fucked it up. No wonder all kinds of "developers" want their code generated by LLMs and don't even look at it anymore. It's the ultimate responsibility laundering.
We are now totally there: Programming With Natural Language.
I could only describe the "look and feel" of the ESP32-algorithm driving a sewing machine: "Snappy but not jerky, linear at low speeds, but accelerates fast".
Antigravity made it perfect but incomprehensible for a hewman.
Fundamentally, the job of a programmer is to precisely describe the fuzzy definitions given by the user. Natural language makes it easier to be fuzzy.
I find c++ very unnatural, since it's a giant collection of small rules in the end more complex than assembler. I can't remember the entire sintaxis, zoo of function decorators, undefined behavior, intrinsics which are just labels over asm instructions, Code golf sintaxis...
A student one told me he wad struggling to get his head around C++. I advised him to stop, since success would leave his head in an unusable shape.
App stores are approving an order of magnitude increase of new apps because people are now able to create them using natural language. End users are deriving great value from them. So this is settled?
The first sentence is easily verifiable, but the second carries the burden of proof.
Nature mints new fools every single day and they all know better than to be informed by past mistakes or — god forbid — anyone using their brains.
Programming happens in code. Software development happens in natural language.
Dichotomy solved, let’s go get lunch! ;-)
A really interesting read in the current era.
I actually wrote a thesis on this in graduate school, and completely disagree with the author.
The problem with this argument isn't that natural language programming leads to vague/ambiguous code that would lead to errors. The problem is that the machine does not inform you of the ambiguity. Rational humans do just fine when they interact because they can identify these problems. Programming would work just find if context were identify and clarified while the code was being written.
If I were to tell a program to "buy political ads in Portland," yea, the point is that the program would need to know which Portland I mean. Otherwise it might accidentally think I mean Portland, OR, instead of Portland, ME:
https://www.yahoo.com/news/politics/articles/25-000-mistake-...
Humans can do the same thing if they're not being careful. The point is, the vast, vast, vast majority of time, someone would just say "wait, you mean Portland, Maine, right?" and you'd say "yes" and that would be that.
Dijkstra's epigrams have not aged well. He once mocked software engineering as "how to program if you cannot"—but this too is a solved problem thanks to AI.
We should have listened.
Another article on this topic https://alexalejandre.com/programming/no-end-of-programming-...
And yet, the specification of almost every program in existence was communicated in natural language. At least between the customer and developer.
This argument makes the implicit assumption that humans are uniquely able to convert between this "customer wants a program that solves their problem" level and compileable code. That was a reasonable thing to believe in 1978, but is not a reasonable thing to believe in 2026.
Once an employer asked me to automatize his work, so the task that he did in weeks was done in seconds. I made a gui that showed every step he did manually, so he could check and understand every step. And yet he became confused and lost track of what the program was doing. He frequently asked me the very concepts he taught me so I could do the program. I just implemented exactly his specification. I didn't created any new concept, but as soon as the task became automatized, he stopped understanding.
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[dead]