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?

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.

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.

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.

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.

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.

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

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"