[obirunda]

Here is the thing. Your initial claim was that English is the programming language. By virtue of making that claim you are claiming LLM has deterministic reliability equivalent to programming language -> compiler. This is simply not true.

If you're considering the LLM translation to be equivalent to the compiler abstraction, I'm sorry I'm not drinking that Kool aid with you.

You conceded above that LLMs aren't deterministic, yet you proceeded to call them an abstraction (conflating). If the output is not 100% equivalent, it's not an abstraction.

In C, you aren't required to inspect the assembly generated by the C compiler. It's guaranteed to be equivalent. In this case, you really need not write/debug assembly, you can use the language and tools to arrive at the same outcome.

Your entire argument is based on the premise that we have a new layer of abstraction that accomplishes the same. Not only it does not, but when it fails, it does so often in unexpected ways. But hey, if you're ready to call this an abstraction that frees up your cognitive load, continue to sip that Kool aid.

[handfuloflight]

You're still avoiding the conflation argument because you can't defend it. You conflated "architectural feedback from running code" with "architectural feedback from typing syntax." These are fundamentally different cognitive processes.

When I refer to English as a programming language, I mean using English to express programming logic and requirements while automating the syntax translation. I'm not claiming we've eliminated the need for actual code, but that we can express the what and why in natural language while handling the how of implementation mechanically.

Your "100% equivalent" standard misses the point entirely. Abstractions work by letting you operate at a higher conceptual level. Assembly programmers could have made the same arguments about C: "you don't really understand what's happening at the hardware level!" Web developers could face the same critique about frameworks: "you don't really understand the DOM manipulation!" Are you writing assembly, then? Are your handcoding your DOM manipulation in your prancing purity? Or using 1998 web tech?

The value of any abstraction is whether it enables better problem-solving by removing unnecessary cognitive overhead. The architectural insights you value don't come from the physical act of typing brackets, semicolons, and variable declarations; they come from understanding system behavior, performance characteristics, and design tradeoffs, all of which remain fully present in my workflow.

You're defending the mechanical act of keystroke-by-keystroke code construction as if it's inseparable from the intelligence of system design. It's not.

You've confused form with function. The syntax is just the representation of logic, not the logic itself. You can understand a complex algorithm from pseudocode without knowing any particular language's syntax. You can analyze system architecture from high-level diagrams without seeing code. You can identify performance bottlenecks by profiling behavior, not by staring at semicolons. You've elevated the delivery mechanism above the actual thinking.

[obirunda]

First of all. I never said that typing brackets and semicolons is what I'm arguing the benefits will come from. That's a very reductionist view of the process.

You have really strawmanned that and positioned my point as stemming from this concept of typing language specific code as being sacrosanct in some way. I'm defending that, because it's not my argument.

I'm arguing that you are being dishonest when you claim to be using English as the programming language in a way that actually expedites the process. I'm saying this is your evidence-free opinion.

I'm also confused by what your involvement is in the implementation and the extent of your specifications. When you write your specifications in English is all pseudo-code? Or are you leaving a lot for the LLM to deduce and implement?

By definition, if you are allowing some level of autonomy and "creative decision making" to the model, you are using it as an abstraction. But this is a dangerous choice, because you cannot guarantee it's reliably abstracting, especially if it's the latter. If it's the former, then I don't see the benefit of writing requirements so detailed as to pseudo-code level to have it write in compilable code for you just so you don't have to type brackets and semicolons.

LLMs aren't good enough yet to deliver reliable code in a project where you can actually consider that portion fully abstracted. You need to code review and test anything that comes out of it. If you're also considering the tests as being abstracted by LLMs then you have a proper feedback loop of slop.

Also, I'm not suggesting that it's impossible for you to understand, conceptually what you're trying to accomplish without writing the code yourself. That's ludicrous, I'm strictly calling B.S, when you are claiming to be using English as a programming language as if that has been abstracted. Whatever your "workflow" is, you're fooling yourself into thinking you have arrived at some productivity nirvana and are just accumulating technical debt for the future you.