Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Eternal Promise: A History of Attempts to Eliminate Programmers

ivanturkovic.com

Post reply on HN
Print view View original

21–30 of 246 posts

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#21

Post by t_mahmood »

bananaflag wrote: post #3

Yeah 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…

A manager is not going to handle all the nitty gritty details, that an engineer knows, fine say, they can ask a LLM to make a web portal.

Does he know about SQL injection? XSS?

Maybe he knows slightly about security stuffs and asks the LLM to make a secure site with all the protection needed. But how the manager knows it works at all? If you figure out there's a issue with your critical part of the software, after your users data are stolen, how bad the fallback is going to be?

How good a tool is also depends on who's using it. Managers are not engineers obviously unless he was an engineer before becoming a manager, but you are saying engineers are not needed. So, where's the engineer manager is going to come from? I'm sure we're not growing them in some engineering trees

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#22

Post by aleph_minus_one »

danhau wrote: post #11
bananaflag wrote: post #3

Yeah 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…

Programmers have enjoyed an occupation with solid stability and growing opportunities. AI challenging this virtually over night is a tough pill to swallow. Naturally, many subscribe to the hope that it will fail. How far AI will succeed in replacing programmers remains to be seen. Personally I think many jobs will disappear, especially in the largest domains (web). But I think this will only be a fraction and not a m…

> Programmers have enjoyed an occupation with solid stability and growing opportunities.

This is not the case:

- Before the 90s, programming was rather a job for people who were insanely passionate about technology, and working as a programmer was not that well-regarded (so no "growing opportunities").

- After the burst of the first dotcom bubble, a lot of programmers were unemployed.

- Every older programmer can tell you how fast the skills that they have can become and became irrelevant.

Over the last decade, the stability and opportunities for programmers was more like a series of boom-bust cycles.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#23

Post by skydhash »

bananaflag wrote: post #17
quotemstr wrote: post #15

Earlier quoted context omitted.

The thing about talking to computers is less the formality and more the specificity. People don't know what they want. To use an LLM effectively, you need to think about what you want with enough clarity to ask for it and check that you're getting it. That LLMs accept your wishes in the form of natural language instead of something with a LALR(1) grammar doesn't magically obviate the need for specificity and clarity…

Agree that one needs clarity, but how does that differ from my example with the manager and the engineer? The manager also (ideally) learns in time that, when they are more clear, the engineer does the work better.

TLDR: Clarity in software engineering means detailing all the constraints, which no user (apart from lawyers and engineers) usually do, as the real world has constraints that software does not.

The hardware offers so little guarantees that the whole OS job is to offer that. All layers are formal, but usefulness doesn't comes from that. Usefulness comes from a consistent models that embodies a domain. So you have the hardware that has capabilities but no model. Then you add the OS's kernel that will impose a model on the hardware, then you have the system libraries that will further restrict it to a certain domains. Then you have the general libraries that are more useful because they present another perspective. And then you have the application that use this last model according to a certain need.

A good example is that you go from the sound card to the sound subsystem, the the alsa libraries, to pipewire, to an audio player or a media framework like the one in the browser. This particular tower has dozens of engineers that has contributed to it, and most developers only deal with the last layers, but the lesson is that the perspective of a user differs from the building blocks that we have in hand. Software engineering is to reconcile the twos.

So people may know how the things should look or behave on their hand, but they have no idea on what the building blocks on the other hand. It's all abstract. The only thing real is the hardware and the energy powering it. Everything else needs to be specified with code. And in that world that forms the middle layer, there's a lot of rules to follow to make something good, but laws that prevent something bad are little. It's not like physical engineering where there are things you just cannot do.

Just like on a canvas you can draw anything as long as it's inside the boundary of the canvas, you can do anything in software as long as it's inside the boundary of the hardware. OS in personal computers adds a little more restrictions, but it's not a lot. It's basically fantasia in there.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#24

Post by ldng »

Havoc wrote: post #5
cjfd wrote: post #2

The 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.

It is democratising from the perspective of non-programmers- they can now make their own tools. What you say about big tech is true at same time though. I worry about what happens when China takes the lead and no longer feels the need to do open models. First hints already showing - advance access to ds4 only for Chinese hardware makers

Terrible argument. They always could learn and DIY.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#25

Post by LiamPowell »

ryanjshaw wrote: post #14
Roark66 wrote: post #8

Earlier quoted context omitted.

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…

Yup. I’m not expert so maybe I’m completely off base, but if I were OpenAI or Anthropic I’d likely just hire 1000 highly skilled engineers across multiple disciplines, tell them to build something in their domain of expertise, then critique the model’s output, iteratively work on guardrails for a month or two until the model one-shots the problem, and package that into the new release.

That's exactly what they are doing via dataannotation.tech and other services.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#26

Post by symfrog »

ryanjshaw wrote: post #4

Until 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…

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 are either building systems that are not critical (e.g. 80% is correct enough), or they do not have the experience to be able to detect how LLM generated code would fail in production beyond the 'happy path'.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#27

Post by empath75 »

symfrog wrote: post #26
ryanjshaw wrote: post #4

Until 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…

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.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#28

Post by jleyank »

Developers 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.

Re: The Eternal Promise: A History of Attempts to Eliminate Programmers

#30

Post by empath75 »

bananaflag wrote: post #3

Yeah 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…

I spent the last two weeks at work building a whole system to deploy automated claude code agents in response to events and even before i finished it was already doing useful work and now it is automatically handling jira tickets and making PRs.
Post reply on HN