[obirunda]

LLMs do not revoke ambiguity from the English language.. Look, if you prefer to use this as part of your workflow and you understand the language and paradigms being chosen by the LLM on your behalf, and can manage to produce extensible code with it, then that's a matter of preference and if you find yourself more productive that way, all power to you.

But when you say English as a programming language, you're implying that we have bypassed its ambiguity. If this was actually possible, we would have an English compiler, and before you suggest LLMs are compilers, they require context. Yes, you can produce code from English but it's entirely non-deterministic, and they also fool you into thinking because they can reproduce in-training material, they will be just as competent at something actually novel.

Your point about waiting on an engineer for a PR is actually moot. What is the goal? Ship a prototype? Build maintainable software? If it's the latter, agents may cost less but they don't remove your personal cognitive load. Because you can't actually let the agent develop truly unattended, you still have to review, validate and approve. And if it's hot garbage you need to spin it all over and hope it works.

So even if you are saving on a single engineer's cost, you have to count your personal cost of baby sitting this "agent". Assuming that you are designing the entire stack this can go better, but if you "forget the code even exits" and let the model also architect your stack for you then you are likely just wasting token money on proof-of-concepts rather than creating a real product.

I also find interesting that so many cult followers love to dismiss other humans in favor of this technology as if it already provides all the attributes that humans possess. As far as I'm concerned cognitive load can still only be truly decreased by having an engineer who understands your product and can champion it foward. Understanding the goal and the mission in real meaningful ways.

[handfuloflight]

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]

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?