4 ms·

If we can't reproduce the work or it doesn't work or it's not actually doing anything of value it's less like "handmade furniture Vs Ikea" and more like "handma

If we can't reproduce the work or it doesn't work or it's not actually doing anything of value it's less like "handmade furniture Vs Ikea" and more like "handmade furniture Vs a bundle of sticks". I don't know what it is but something is clearly wrong that people are upset about the people involved not really understanding the things they're building when they have fulfilled "the brief" using LLMs. Sometimes it feels silly like going through the motions of typing code is somehow helpful. But I think there is some line where people are justified in being concerned when a business or a paper doesn't actually understand what they're ostensibly "owning" or improving as a product/paper.

ChrisMarshallNY 6d ago
True, but we don't expect programmers to be able to be given a printout of machine language instructions from their shipped binary, and explain it. At one time, in my career, that was actually expected. Times, they are a changin'...
- Tanjreeve 6d ago
  When we moved to higher level languages we still had the expectation that software would work and/or be able to be improved. If it actively doesn't work or noone can use research because the originator can't explain it then we're going backwards and wasting money/time. "Times they are a changing" just seems like more of the premature backslapping over a tool that allows us to rig up software to go in a direction quicker. At the end of the pipe someone has to pay for it or use the research and they don't care if it's an LLM or not same as they don't care if it was written in an IDE or not. And that works both ways.
  - ChrisMarshallNY 6d ago
    My point still stands. At one time, every programmer was supposed to be able to analyze a crash dump. I think it's been a long time, since your average coder has been able to do that, and that's a good thing. The reason is that the tools became good enough, and reliable enough, to trust. We are still expected to stand behind the results of our work. It's just that we have learned to trust the tools we use, enough to do so. We will reach that point with AI tools, sooner or later (maybe sooner). Accountability will still rest on all-too-human shoulders, but the tools and the scope of our work will change.

ChrisMarshallNY 6d ago

True, but we don't expect programmers to be able to be given a printout of machine language instructions from their shipped binary, and explain it. At one time, in my career, that was actually expected. Times, they are a changin'...

Tanjreeve 6d ago
When we moved to higher level languages we still had the expectation that software would work and/or be able to be improved. If it actively doesn't work or noone can use research because the originator can't explain it then we're going backwards and wasting money/time. "Times they are a changing" just seems like more of the premature backslapping over a tool that allows us to rig up software to go in a direction quicker. At the end of the pipe someone has to pay for it or use the research and they don't care if it's an LLM or not same as they don't care if it was written in an IDE or not. And that works both ways.
- ChrisMarshallNY 6d ago
  My point still stands. At one time, every programmer was supposed to be able to analyze a crash dump. I think it's been a long time, since your average coder has been able to do that, and that's a good thing. The reason is that the tools became good enough, and reliable enough, to trust. We are still expected to stand behind the results of our work. It's just that we have learned to trust the tools we use, enough to do so. We will reach that point with AI tools, sooner or later (maybe sooner). Accountability will still rest on all-too-human shoulders, but the tools and the scope of our work will change.