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?
"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?