4 ms·

That's just it. you didn't "build so much", you didn't build anything. You asked someone (or something) to build it for you. How can people look at LLM-generat

by pferde 15d ago

That's just it. you didn't "build so much", you didn't build anything. You asked someone (or something) to build it for you. How can people look at LLM-generated code and think "this is mine, I made this" is beyond me.

FuckButtons 15d ago
I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.
- Terr_ 15d ago
  I think the difference involves how many layers of stuff someone claims is "theirs" and whether that claim of credit and expertise is valid. Imagine a coworker writes some decent C code, but then at a meeting they start taking credit for the bytecode and the default optimizations done by the compiler. That's analogous to people who write LLM prompts and then claim the same level of authorship over the code which was all generated and edited on an indirect level.
- pferde 15d ago
  If you ask LLM to code something for you, and you then work on the code, then yes, there is partial ownership. Just like if you had asked another, maybe junior, developer to write a piece of code, and then you helped them make it better.
huurtehoog 15d ago
Agree wholeheartedly. I'd like to add: we can't know a priori what will be needed to be known and what can safely remain behind an abstraction you just use. That is revealed when our mental models grind against reality. Avoiding that friction at all costs is a problem because it will happen and you'll be unprepared when it becomes unavoidable. Trusting some abstractions that have earned it but not all is how we deal with it. Limit your focus, and adapt. If you just trust all abstractions thrown in front of you until something breaks irreparably, you will be (person or organization) between a rock and a hard place and without any knowledge or skill on how to get out of that predicament. That to me is the biggest risk in accepting the fallacy of general automation.

by pferde 15d ago

FuckButtons 15d ago

I’m in two minds about this, in some sense they did and it’s the same way in which the C code I write is mine, but the assembly underneath is an artifact of my intent, but I owe the compiler authors for it. On the other hand the cognitive distance between my C and the assembly is likely lower, but that’s because I’ve spent time staring at what was generated in order to figure out why my code was misbehaving. Which is itself not that dissimilar to figuring out how to get better at writing code with llms.

Terr_ 15d ago
I think the difference involves how many layers of stuff someone claims is "theirs" and whether that claim of credit and expertise is valid. Imagine a coworker writes some decent C code, but then at a meeting they start taking credit for the bytecode and the default optimizations done by the compiler. That's analogous to people who write LLM prompts and then claim the same level of authorship over the code which was all generated and edited on an indirect level.
pferde 15d ago
If you ask LLM to code something for you, and you then work on the code, then yes, there is partial ownership. Just like if you had asked another, maybe junior, developer to write a piece of code, and then you helped them make it better.

huurtehoog 15d ago

Agree wholeheartedly. I'd like to add: we can't know a priori what will be needed to be known and what can safely remain behind an abstraction you just use. That is revealed when our mental models grind against reality. Avoiding that friction at all costs is a problem because it will happen and you'll be unprepared when it becomes unavoidable. Trusting some abstractions that have earned it but not all is how we deal with it. Limit your focus, and adapt. If you just trust all abstractions thrown in front of you until something breaks irreparably, you will be (person or organization) between a rock and a hard place and without any knowledge or skill on how to get out of that predicament. That to me is the biggest risk in accepting the fallacy of general automation.