4 ms·

You're mischaracterizing my position from the start. I never claimed LLMs "revoke ambiguity from the English language." I said I'm doing everything a programme

You're mischaracterizing my position from the start. I never claimed LLMs "revoke ambiguity from the English language." I said I'm doing everything a programmer does except writing syntax. So your argument about English being "ambiguous" misses the point. ⍵[⍋⍵]}⍨?10⍴100 is extremely precise to an APL programmer but completely ambiguous to everyone else. Meanwhile "generate 10 random integers from 1 to 100 and sort them in ascending order" is unambiguous to both humans and LLMs. The precision comes from clear specification, not syntax. You're conflating oversight with "babysitting." When you review and validate code, that's normal engineering process whether it comes from humans or AI. If anything, managing human developers involves actual babysitting: handling office politics, mood swings, sick days, ego management, motivation issues, and interpersonal conflicts. CTOs or managers spend significant time on the human element that has nothing to do with code quality. You're calling technical review "babysitting" while ignoring that managing humans involves literal people management. You've created a false choice between "prototype" and "production software" as if natural language programming can only produce one or the other. The architectural thinking isn't missing, it's just expressed in natural language rather than syntax. System design, scalability patterns, and business requirements understanding are all still required. Your assumption that "cognitive load can only be decreased by an engineer who understands your product" ignores that someone can understand their own product better than contractors. You're acting like the goal is to "dismiss humans" when it's about finding more efficient ways to build software, I'd gladly hire other natural language developers with proper vetting, and I actually have plans to do so. And to be sure, I would rather hire the natural language developer who also knows syntax over one who doesn't, all else being equal. Emphasis on all else being equal. The core issue is you're defending traditional methods on principle rather than engaging with whether the outcomes can actually be achieved differently.

obirunda 1y ago
The point I'm driving at is why? Why program in English if you have to go through similar rigour. If you're not actually handing off the actual engineering, you're putting the solution and having it translate to your language of preference whilst telling everyone how much more productive you are for effectively offloading the trivial part of the process. I'm not arguing that you can't get code from well defined, pedantically written requirements or pseudo code. All I'm saying is that that is less than what is claimed by ai maximalists. Also, if that's all that you're doing with your "agents" just write the code on not deal with the pitfalls?
- handfuloflight 1y ago
  Yes, I maintain the same engineering rigor: but that rigor now goes toward solving the actual problem instead of wrestling with syntax, debugging semicolons, or managing language specific quirks. My cognitive load shifts from "how do I implement this?" to "what exactly do I want to build?" That's not a trivial difference, it's transformative. You're calling implementation "trivial" while simultaneously arguing I should keep doing it manually. If it's trivial, why waste time on it? If it's not trivial, then automating it is obviously valuable. You can't have it both ways. The speed difference isn't just about typing faster, it's about iteration speed. I can test ideas, refine approaches, and pivot architectural decisions in minutes and hours instead of days or weeks. When you're thinking through complex system design, that rapid feedback loop changes everything about how you solve problems. This is like asking "why use a compiler when you could write assembly?" Higher-level abstractions aren't about reducing rigor, they're about focusing that rigor where it actually matters: on the problem domain, not the implementation mechanics. You're defending a process based on principle rather than outcomes. I'm optimizing for results.
  - obirunda 1y ago
    It's not the same. Compilers compile to equivalent assembly, LLMs aren't in the same family of outcomes. If you are arguing for some sort of euphoria of getting lines of code from your presumably rigorous requirements much faster, carry on. This goes both ways though, if you are claiming to be extremely rigorous in your process, I find it curious that you are wrestling with language syntax. Are you unfamiliar with the language you're developing with? If you know the language and have gone as far as having defined the problem and solution in testable terms, the implementation should indeed be trivial. The choice of writing the code and gaining a deeper understanding of the implementation where you stand to gain from owning this part of the process come with the price of a higher time spent in the codebase, versus offloading it to the model which can be quicker, but it comes with the drawback that you will be less familiar with your own project. The question ofhow do I implement this? Is an engineering question, not a please implement this solution I wrote in English. You may feel like the implementation mechanics are divorced from the problem domain but I find that to hardly be the case, most projects I've worked on the implementation often informed the requirements and vice versa. Abstractions are usually adopted when they are equivalent to the process they are abstracting. You may see capability, and indeed models are capable, but they aren't yet as reliable as the thing you allege them to be abstracting. I think the new workflows feel faster, and may indeed be on several instances, but there is no free lunch.

obirunda 1y ago

The point I'm driving at is why? Why program in English if you have to go through similar rigour. If you're not actually handing off the actual engineering, you're putting the solution and having it translate to your language of preference whilst telling everyone how much more productive you are for effectively offloading the trivial part of the process. I'm not arguing that you can't get code from well defined, pedantically written requirements or pseudo code. All I'm saying is that that is less than what is claimed by ai maximalists. Also, if that's all that you're doing with your "agents" just write the code on not deal with the pitfalls?

handfuloflight 1y ago
Yes, I maintain the same engineering rigor: but that rigor now goes toward solving the actual problem instead of wrestling with syntax, debugging semicolons, or managing language specific quirks. My cognitive load shifts from "how do I implement this?" to "what exactly do I want to build?" That's not a trivial difference, it's transformative. You're calling implementation "trivial" while simultaneously arguing I should keep doing it manually. If it's trivial, why waste time on it? If it's not trivial, then automating it is obviously valuable. You can't have it both ways. The speed difference isn't just about typing faster, it's about iteration speed. I can test ideas, refine approaches, and pivot architectural decisions in minutes and hours instead of days or weeks. When you're thinking through complex system design, that rapid feedback loop changes everything about how you solve problems. This is like asking "why use a compiler when you could write assembly?" Higher-level abstractions aren't about reducing rigor, they're about focusing that rigor where it actually matters: on the problem domain, not the implementation mechanics. You're defending a process based on principle rather than outcomes. I'm optimizing for results.
- obirunda 1y ago
  It's not the same. Compilers compile to equivalent assembly, LLMs aren't in the same family of outcomes. If you are arguing for some sort of euphoria of getting lines of code from your presumably rigorous requirements much faster, carry on. This goes both ways though, if you are claiming to be extremely rigorous in your process, I find it curious that you are wrestling with language syntax. Are you unfamiliar with the language you're developing with? If you know the language and have gone as far as having defined the problem and solution in testable terms, the implementation should indeed be trivial. The choice of writing the code and gaining a deeper understanding of the implementation where you stand to gain from owning this part of the process come with the price of a higher time spent in the codebase, versus offloading it to the model which can be quicker, but it comes with the drawback that you will be less familiar with your own project. The question ofhow do I implement this? Is an engineering question, not a please implement this solution I wrote in English. You may feel like the implementation mechanics are divorced from the problem domain but I find that to hardly be the case, most projects I've worked on the implementation often informed the requirements and vice versa. Abstractions are usually adopted when they are equivalent to the process they are abstracting. You may see capability, and indeed models are capable, but they aren't yet as reliable as the thing you allege them to be abstracting. I think the new workflows feel faster, and may indeed be on several instances, but there is no free lunch.