History reviews is not a great way to approach ground breaking tech
You are not going to stop people from reading into history, ever. If anything, people need to learn more about what happened in the past.
The Eternal Promise: A History of Attempts to Eliminate Programmers
41–50 of 246 posts
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#42Earlier quoted context omitted.
The closer you get to releasing software, the less useful LLMs become. They tend to go into loops of 'Fixed it!' without having fixed anything. In my opinion, attempting to hold the hand of the LLM via prompts in English for the 'last mile' to production ready code runs into the fundamental problem of ambiguity of natural languages. From my experience, those developers that believe LLMs are good enough for production…
This is not my experience with claude code. It does forget big picture things but if you scope your changes well it’s fine.
Yes, but knowing how to scope your changes requires a lot of expertise.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#43Earlier quoted context omitted.
AI is useful when paired with an experienced programmer. Experienced through old-school (pre-LLM) practice. I don't clearly see a good endgame for this.
Endgame is to produce AI which will not need any supervision by the time the current generation of experienced developers will retire or even sooner. I don’t know if it will happen but many bet on this and models are still improving, flattening is not yet seen.
This implies programming is done and there will be no other advancements.
And flattening is being seen, no? Recent advancements are mostly from RL’ing, which has limitations (and tradeoffs) too. Are there more tricks after that?
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#44The article talks about 'software development will be democratized' but the current LLM hype is quite the opposite. The LLMs are owned by large companies and are quite impossible to train by any individual, if only because of energy costs. The situation where I am typing my code on my linux machine is much more democratic.
Right, people misuse this term "democratized" all the time. Because it sounds nice. But it's incorrect. Democracy is about governance, not access. A "democratized" LLM would be one in which its users collectively made decisions about how it was managed. Or if the companies that owned LLMs were ran democratically.
>Democracy is about governance, not access.
It can be about both meanings. The additional meanings of democratize to describe "more accessible" are documented in Oxford and Merriam-Webster dictionaries:
https://www.encyclopedia.com/humanities/dictionaries-thesaur...
https://www.merriam-webster.com/dictionary/democratic#:~:tex...
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#45Yeah but this time it's for real. All the other attempts failed because they were just mindless conversions of formal languages to formal languages. Basically glorified compilers. Either the formal language wasn't capable enough to express all situations, or it was capable and thus it was as complex as the one thing it was designed to replace. AI is different. You tell it in natural language, which can be ambiguous a…
> And it can fill in the missing details and disambiguate the others.
Are you suggesting “And Claude, make no mistakes” works?
Because otherwise you need an expert operating the thing. Yes, it can answer questions, but you need to know what exactly to ask.
> This has been known to be possible for decades, as (simplifying a bit) the (non-technical) manager can order the engineer in natural, ambiguous language what to do and they will do it
I have yet to see vibe coding work like this. Even expert devs with LLMs get incorrect output. Anytime you have to correct your prompt, that’s why your argument fails.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#46Yeah but this time it's for real. All the other attempts failed because they were just mindless conversions of formal languages to formal languages. Basically glorified compilers. Either the formal language wasn't capable enough to express all situations, or it was capable and thus it was as complex as the one thing it was designed to replace. AI is different. You tell it in natural language, which can be ambiguous a…
> All the other attempts failed because they were just mindless conversions of formal languages to formal languages.
This is just categorically false.
No-code tools didn't fail because they were "mindless conversions of formal languages to formal languages". They failed because the people who were supposed to benefit the most (non-developers) neither had the time nor desire to build stuff in the first place.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#47Wow it mentions practically every flavour of the month technology that was supposed to make it drag and drop to make useful programs
I recall Power builder in particular it was the rage.
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#48Developers are “unwanted overhead” until the customer money threatens to walk out the door. They’re going to damage their future products and probably reduce their customer base (fewer consumers) and then sit there looking like gaffed fish when the budget ink turns red. “Who would have thought…” Don’t facilitate losing your job.
Funny part is we've already had this exact thing happen with outsourcing. It sure looked like a bargain until you got to such pesky details as correctness and maintainability.
I am starting to think it is a part of the management cycle. They new batch feels confident they can do X so they have to re-learn, while inflicting ridiculous amount of pain the process.
Two years ago, one former exec at my place was perfectly happy to throw resources ( his word ) from India at a problem, while unwilling to pay the vendor for the same thing. I voiced my objection once, but after it was dismissed I just watched the thing blow up.
I am not saying current situation is the same. It is not. But, it is the same hubris, which means miscalculations will happen ( like with Dorsey's Block mass firing ).
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#49Until a year ago I believed as the author did. Then LLMs got to the point where they sit in meetings like I do, make notes like I do, have a memory like I do, and their context window is expanding. Only issue I saw after a month of building something complex from scratch with Opus 4.6 is poor adherence to high-level design principles and consistency. This can be solved with expert guardrails, I believe. It won’t be l…
After 2 years of using all of these tools (Claude C, Gemini cli, opencode with all models available) I can tell you it is a huge enabler, but you have to provide these "expert guardrails" by monitoring every single deliverable. For someone who is able to design an end to end system by themselves these tools offer a big time saving, but they come with dangers too. Yesterday I had a mid dev in my team proudly present a…
Any comments on how the copyright issues are handled in corporate settings? I mean both in terms of staying clear of lawsuit+ ensuring what we produce remains safe from copying
Re: The Eternal Promise: A History of Attempts to Eliminate Programmers
#50Yeah but this time it's for real. All the other attempts failed because they were just mindless conversions of formal languages to formal languages. Basically glorified compilers. Either the formal language wasn't capable enough to express all situations, or it was capable and thus it was as complex as the one thing it was designed to replace. AI is different. You tell it in natural language, which can be ambiguous a…
> And it can fill in the missing details and disambiguate the others. Are you suggesting “And Claude, make no mistakes” works? Because otherwise you need an expert operating the thing. Yes, it can answer questions, but you need to know what exactly to ask. > This has been known to be possible for decades, as (simplifying a bit) the (non-technical) manager can order the engineer in natural, ambiguous language what to…
I truly believe that people that see entire, non-trivial applications being bult without serious human intervention have not in fact worked on non-trivial applications.
And while these tools can be invaluable in some cases, I still don't know how we get from "Hazy requirements where the user doesn't know what they even want" to "Production-ready apps built at the finger-tips of the PM".
Another really important detail people keep missing is that we have to make thousands of micro-decisions along the way to build up a cohesive experience to the user. LLM's haven't really shown they're great at not building assumptions into code. In fact, they're really bad at it.
Lastly, do people not realize how easy it to so convince an LLM of something that isn't true or vice versa? i love these tools but even I find myself trying to steer it into the direction that makes sense to me, not the direction that makes sense generally.