7 ms·

You keep sidestepping the core issue with LLMs. If all that you are really doing is writing your code in English and asking the LLM to re-write it for you in y

You keep sidestepping the core issue with LLMs. If all that you are really doing is writing your code in English and asking the LLM to re-write it for you in your language of choice (probably JS), then end of discussion. But your tone really implies you're a big fan of the vibes of automation this gives. Your repeated accusations of "conflating" are a transparent attempt to deflect from the hollowness of your own arguments. You keep yapping about me conflating things. It's ironic because you are the one committing this error by treating the process of software engineering as a set of neatly separable, independent tasks. You've built your entire argument on a fragile, false dichotomy between "strategic" and "mechanical" work. This is a fantasy. The "mechanical" act of implementation is not divorced from the "strategic" act of architecture. The architectural insights you claim to get from "running code and testing behavior" are a direct result of the specific implementation choices that were made. You don't get to wave a natural language wand, generate a black box of code, and then pretend you have the same deep understanding as someone who has grappled with the trade-offs at every level of the stack. Implementation informs architecture, and vice versa. By offloading the implementation, you are severing a critical feedback loop and are left with a shallow, surface-level understanding of your own product. Your food processors and compiler analogy—are fundamentally flawed because they compare deterministic tools to a non-deterministic one. A compiler or food processor doesn't get "creative." An LLM does. Building production systems on this foundation isn't "transformative"; it's reckless. You've avoided every direct question about your actual workflow because there is clearly no rigor there. You're not optimizing for results; you're optimizing for the feeling of speed while sacrificing the deep, hard-won knowledge that actually produces robust, maintainable software. You're not building, you're just generating.

deleted 1y ago
[deleted]
handfuloflight 1y ago
You completely ignored my conflation argument because you can't defend it, then accused me of "deflecting", that's textbook projection. You're the one deflecting by strawmanning me into defending "deterministic LLMs" when I never made that claim. My compiler analogy wasn't about determinism: it was about abstraction levels. You're desperately trying to make this about LLM reliability when my point was about focusing cognitive energy where it matters most. Classic misdirection. You can't defend your "keystroke mechanics = architectural wisdom" position, so you're creating fake arguments to attack instead. Enjoy your "deep, hard-won knowledge" from typing semicolons while I build actual systems.
- obirunda 1y ago
  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 1y ago
    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.

deleted 1y ago

[deleted]

handfuloflight 1y ago

You completely ignored my conflation argument because you can't defend it, then accused me of "deflecting", that's textbook projection. You're the one deflecting by strawmanning me into defending "deterministic LLMs" when I never made that claim. My compiler analogy wasn't about determinism: it was about abstraction levels. You're desperately trying to make this about LLM reliability when my point was about focusing cognitive energy where it matters most. Classic misdirection. You can't defend your "keystroke mechanics = architectural wisdom" position, so you're creating fake arguments to attack instead. Enjoy your "deep, hard-won knowledge" from typing semicolons while I build actual systems.

obirunda 1y ago
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 1y ago
  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.