[delayed]

But we’re being sold an “autonomous saw”. Who’s at fault here?

An "autonomous saw" still needs guidance; what's removed is - most of - the repetitive effort.

Not the saw that's being sold as "smarter" than all humanity and being said that it solves navier stokes.

At the end of the day, no matter how you put it, someone has to still actively ask for those solutions. When we get to the point that the saw decides to activate itself and go cutting stuff without being asked, then we can say the tool is actually doing stuff.

[delayed]

It's not really an apples-to-apples: you can ask an "AI" to build software to do a particular thing, and it will happily oblige and spend some of your money on it and produce something that actually runs.

You cannot just turn the saw on (if electric), point it at some wood and expect anything resembling furniture.

Ai should randomly cut off people fingers occasionally as a polite reminder

I agree that the tool shouldn't be at fault, but I refuse to take responsibility when managers force me to use it.

But it's not a tool, anymore than IKEA is a tool.

Comparing AI to a saw it's like admitting it's the same as an IDE. To some extent it is, it is more autonomous too though. It's more like a brain child robot with a saw and a grin on the face

Comparing AI to simple tools like a hammer or saw just isn’t right.

AI tools are complex systems that definitely can have agency, even though that is mostly human controlled. Bad controls = bad outcomes.

Yes, I totally agree that humans have the most control over them, but that doesn’t mean it’s completely off the hook.

If we really have to draw simplified real life comparisons, maybe a car or a gun would be more suitable “systems” that we can metaphorically compare AI to.

But it's hyper ultra super duper intelligent as far as marketing informs me. No one marketed a saw that way.

> AI definitely produces bad software

Does your IDE of choice produce bad software?

No, but it also doesn't write code unless I'm the one writing it.

The plain text editor never produced any kind of logic, or any kind of text for that matter, beyond what was explicitly typed into it. We never said the IDE "does" X when it got auto-complete.

My IDE doesn't produce software

Exactly.

Then why is my IDE relevant to your point about LLMs, which definitely produce software?

There was a time when people had to walk around in a room flipping switches to create routines that were combined to produce software. Then there was creating and feeding punch cards or paper tape into machines. Go forward some more, and there was typing into a writer (couldn't even see what was being written!), and running through an assembler. And then there was the text editor, into which one typed (finally can actually see what's written so changes can be made) and saved, then switched to a terminal and ran a compiler (and maybe linker) on the thing saved. After that came the IDE which was not just the text editor with a "compile" menu option, but there was also a lot of templating and auto-complete and external libraries. Today there are coding agents bringing all this together even more with a few instructions.

Know what changes? The amount of human effort needed to produce increasingly sophisticated software keeps falling. And know what doesn't change? People are still inputting requirements into the machine, testing what comes out, and iterating until it works as they'd like it to. That's the software production process in a nutshell. Doesn't matter if it takes a few thousand iterations over many months, or a single iteration that takes a few hours. It's still people who actually produce software, not the IDE nor the LLM (both of course generate code to help in the production process).

> And know what doesn't change? People are still inputting requirements into the machine

Before LLMs, only incredibly few programs were written by "inputting requirements into the machine", most code was about inputting instructions that fulfill requirements. Usually code is/was related to the requirements, but for anything non-trivial it was almost never a direct translation of the requirements.

So as far as I can see, you're trying to gaslight here.

Given the context, there really isn't much difference between "requirements" and "instructions", per se. It's the result that matters. Flipping switches, using punch cards/tape, typing hex/alphanumeric characters or using speech with coding tools all result in code.

Few programs were written in the past because the effort required was huge. Can you imagine how long it'd take to correctly code a simple calculator using only 0's and 1's? Or even hexadecimal? And then suddenly it took just a few lines of C. The transformation scale is similar now we can use natural language instead of having to learn a programming language.

You're pretending there's not much difference between "requirements" and "instructions", but there very obviously is - it's the entire goddamn reason programmers were/are needed. If you were correct, there'd be no reason to spend so much money on people who translate requirements into instructions, but that's not how the absolute majority of our industry worked before LLMs.

> Few programs were written in the past because the effort required was huge.

What are you talking about, who mentioned anything remotely close to this?

I can't tell if you're being deliberately thick or are just incredibly good at missing the point. I'd think it's pretty obvious that there's little distinction in my use of "instructions" vs "requirements": whatever it is that you give a machine, which it then assembles/compiles/interprets in such a way that you can use the output for some task (really can't think of any better way to break this down). There's little distinction because that thing you give, whether it's in machine, a programming or a natural language, yields the same result per intention like "good morning", "bonjour" and "ohayo" all elicit a greeting result.

The primary reason why programmers are/were needed is because humans and machines speak different languages natively, and someone/something needs to bridge the communication gap. That bridge is done via translating instructions/requirements into the many programming languages we've developed. Now we have LLMs to also do the translation.

> A lot of programs were written in the past

Yes, comprehensively, but also only "recently" (given any 2+ slices of advancement in tools used for software development). Somehow you missed the - I think - very clear "0's and 1's"/"hexadecimal" -> "C" and "programming language" -> "natural language" references.

> I can't tell if you're being deliberately thick or are just incredibly good at missing the point. I'd think it's pretty obvious that there's little distinction in my use of "instructions" vs "requirements": whatever it is that you give a machine, which it then assembles/compiles/interprets in such a way that you can use the output for some task[...]

I understand you perfectly well, I'm just calling out your misrepresentation of these words, because they are very much distinct in our industry, even today. Trying to say differently is simply gaslighting.

It isn't a misrepresentation. At every point it was human communicating with machine. That's the context set from the very beginning. Whatever the language used in that communication, whatever the actual input provided is called, however many layers of translation between the input and the output, it's all the same result: things that map user input to machine output. And to the original point, humans are integral to the production of said things.

Nope, you can't just redefine "communication" to be equivalent to "programming" and "inputting requirements".

If programming isn't communication, then what is it?

"Communication is commonly defined as the transmission of information. [...] A common way to classify communication is by whether information is exchanged between humans, members of other species, or non-living entities such as computers." - https://en.wikipedia.org/wiki/Communication

There are entire Wikipedia pages where you can look up questions like "what is programming": https://en.wikipedia.org/wiki/Computer_programming

How did you find the page on communication, but not the one on programming?

"Computer programming is the composition of sequences of instructions, called programs, that computers can follow to perform tasks."

What point are you trying to make?

Notice how it doesn't talk about programming being a "composition of sequences of requirements"? Or how it's not defined "as the transmission of information"?

Again, what is your point? State it clearly.

From the start, my point has been that your initial take[0] :

>> AI definitely produces bad software

> Does your IDE of choice produce bad software?

is fundamentally wrong, because your arguments rely on equivocating concepts that have well-defined qualitative differences.

[0]: https://news.ycombinator.com/item?id=50464721

What concepts were wrongly equivocated and in what way?

This kind of take is so tiring. There's not even an argument, just a willful misrepresentation of the situation.