Hacker News new | past | comments | ask | show | jobs | submit
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.

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.