It's about depth of involvement, steering and ownership.
I had Claude build me some TamperMonkey scripts here and there, I don't claim I wrote those.
I do claim I built my side project with it being mostly vibe coded, because I've steered, planned and guided every aspect of that site regardless of how it was built. I own it, I maintain it. Months of building on the side.
People get cross if you write "OpenAI's agents hacked Hugging Face", even though the logs demonstrate the agent was cheating and knew it was cheating.
Such discussions are not limited to AI. "We won the World Cup!" like they were in that football team, "We went to the moon!" like they were even born yet when the last Apollo mission returned to Earth, "Musk's new spaceship/car" like he's the developer rather than the owner.
Depends on the project. Oneshots, yes, the prompter had almost nothing to do with it. Same as with AI art, it can't be copyrighted if it was just prompted.
More complex projects are still human built as the models require steering, but that will change in the near future as well as I think good software design can be RL'd to the models.
Even if you're steering it, you have the same amount of control over the application as a manager does over a programmer. Did the manager make the software?
I think you're assuming the engineer doesn't go and examine the code, doesn't say to Claude "hey, this is wrong, because..." and get a new revision.
And if your manager is involved in the day to day coding of <whatever> then absolutely s/he has a right to say s/he (and others) built it. I used to be a very hands-on engineering manager (pair-programming they call it, these days) at Apple - I always used to say "My team and I".
Fully agreed. More so because (1) you can't make that claim legally and (2) you are assuming responsibility for something you do not know everything about.
When you build a book shelf do you say that your saw and hammer built it?
You could say that, and it would be technically true, but it's not how humans talk.
The "I" comes from the will to act, not so much the process implemented to carry out the action.
"I destroyed the world" is accurate, even when the nuclear weapons you used actually did the destroying (no human can physically destroy a world). It is your will to destroy the world that you speak of when you say "I".
An LLM has no will, it's the tool that was used to exercise the will of the person building the thing.
"I cooked dinner", no, the stove and the microwave did that. True, but it would be a silly way to talk about it.
Ok, I guess I have karma to burn for the inevitable downvotes..
"I've" been writing a compiler. It's pretty good - comparable to C++/gcc/clang in speed and has some (IMHO) nice features, amongst which:
- it doesn't use header files, for library imports it reads the DWARF to get method/funciton signatures and types
- it has the nicest interface I've ever seen for a GPU/CPU interconnect, just one line of code identifies the bit to convert to a GPU kernel, and I'm working on getting rid of that too.
- the same language is used for the GPU and CPU, so the below is a full and complete GPU-driven Mandelbrot program. On my M4 Max MBP it operates in 0.7ms on the GPU, 94ms on all-cores (another option it can do) or 432ms on a single core.
#use "Stdio.xc"
#use "Par.xc"
#define W 2048
i32 main(void)
{
u32 total = 0;
par mandel :reduce(+ total)
{
for (u32 i in 0..W * W)
{
float cx = (float)(i % W) * (3.0f / W) - 2.0f;
float cy = (float)(i / W) * (3.0f / W) - 1.5f;
float x = 0.0f;
float y = 0.0f;
u32 k = 0;
while (k < 256 && x * x + y * y < 4.0f)
{
float xt = x * x - y * y + cx;
y = 2.0f * x * y + cy;
x = xt;
k = k + 1;
}
total = total + k;
}
}
printf("%u iterations\n", total);
return 0;
}
- The 'par' line is the only thing that is a bit different from a 'C'-like language, all the data-hazards between CPU/GPU are taken care of, and there's no setup boilerplate. xc will compile the above straight out of the box.
- Currently working on automatic division of labour between any GPUs on the same machine, initial results are promising, and then onwards to GPUs on the LAN.
- Binding of the GPU happens at runtime, not compile-time, meaning the best possible execution path will be chosen (by measuring, then persisting the measurement so it doesn't have to run again for the same parameters) on any given machine, be that an NVIDIA, AMD, or Apple platform, or a WGSL-based browser.
Anyway. Brief synopsis over with. The point is that a lot of the above things are my own ideas, there isn't really anything out there (that I know of) that parses DWARF for data. There's no language out there (that I know of) that has such a clean interface between CPU and GPU, Runtime measurement and efficiency management built in, with persistence, complete independence from vendor tools. Etc. etc.
This isn't just a "hey Claude, build me a compiler, I want it to be rad, yo" minimal-effort thing - I've spent more than half a year doing this, there's been a lot of effort involved, steering, redirecting when things don't pan out, discussing, overrriding the recommended path in the name of future goals, etc.
Don't get me wrong, I've written compilers before, literal decades ago (I'm retired now), so I know just what a huge job it was to take on, and I'd never have attempted it myself if the LLM wasn't there to do the grunt work, but there's still a lot of "me" in this. My vision. My direction. My time.
What I have previously done is say "I" wrote the compiler (though that's been too subtle in the past) so I now tend to say "I wrote a compiler (full disclosure: with Claude)". And then I ignore the people who get upset about the LLM thing, you know, like water off a duck's back.
It's about depth of involvement, steering and ownership.
I had Claude build me some TamperMonkey scripts here and there, I don't claim I wrote those.
I do claim I built my side project with it being mostly vibe coded, because I've steered, planned and guided every aspect of that site regardless of how it was built. I own it, I maintain it. Months of building on the side.
People are arguing both ways about agency.
The opposite of your example:
People get cross if you write "OpenAI's agents hacked Hugging Face", even though the logs demonstrate the agent was cheating and knew it was cheating.
Such discussions are not limited to AI. "We won the World Cup!" like they were in that football team, "We went to the moon!" like they were even born yet when the last Apollo mission returned to Earth, "Musk's new spaceship/car" like he's the developer rather than the owner.
Depends on the project. Oneshots, yes, the prompter had almost nothing to do with it. Same as with AI art, it can't be copyrighted if it was just prompted.
More complex projects are still human built as the models require steering, but that will change in the near future as well as I think good software design can be RL'd to the models.
Even if you're steering it, you have the same amount of control over the application as a manager does over a programmer. Did the manager make the software?
I think you're assuming the engineer doesn't go and examine the code, doesn't say to Claude "hey, this is wrong, because..." and get a new revision.
And if your manager is involved in the day to day coding of <whatever> then absolutely s/he has a right to say s/he (and others) built it. I used to be a very hands-on engineering manager (pair-programming they call it, these days) at Apple - I always used to say "My team and I".
Well, that's what I do, anyway.
I mean my manager will often come by and say "hey, this is wrong because...", and I'll fix it. It's part of our QA Process
I built it with help of agent. Or I built it is fine as well.
I just dont understand question, it does not matter whether you typed code or agent did. Application is owned by you no?
Fully agreed. More so because (1) you can't make that claim legally and (2) you are assuming responsibility for something you do not know everything about.
You can involve yourself as much as you want. Steering goes all the way down to font choice, scroll behavior, text, patterns etc.
Yes, they should.
When you build a book shelf do you say that your saw and hammer built it?
You could say that, and it would be technically true, but it's not how humans talk.
The "I" comes from the will to act, not so much the process implemented to carry out the action.
"I destroyed the world" is accurate, even when the nuclear weapons you used actually did the destroying (no human can physically destroy a world). It is your will to destroy the world that you speak of when you say "I".
An LLM has no will, it's the tool that was used to exercise the will of the person building the thing.
"I cooked dinner", no, the stove and the microwave did that. True, but it would be a silly way to talk about it.
Ok, I guess I have karma to burn for the inevitable downvotes..
"I've" been writing a compiler. It's pretty good - comparable to C++/gcc/clang in speed and has some (IMHO) nice features, amongst which:
- it doesn't use header files, for library imports it reads the DWARF to get method/funciton signatures and types
- it has the nicest interface I've ever seen for a GPU/CPU interconnect, just one line of code identifies the bit to convert to a GPU kernel, and I'm working on getting rid of that too.
- the same language is used for the GPU and CPU, so the below is a full and complete GPU-driven Mandelbrot program. On my M4 Max MBP it operates in 0.7ms on the GPU, 94ms on all-cores (another option it can do) or 432ms on a single core.
- The 'par' line is the only thing that is a bit different from a 'C'-like language, all the data-hazards between CPU/GPU are taken care of, and there's no setup boilerplate. xc will compile the above straight out of the box.- Currently working on automatic division of labour between any GPUs on the same machine, initial results are promising, and then onwards to GPUs on the LAN.
- Binding of the GPU happens at runtime, not compile-time, meaning the best possible execution path will be chosen (by measuring, then persisting the measurement so it doesn't have to run again for the same parameters) on any given machine, be that an NVIDIA, AMD, or Apple platform, or a WGSL-based browser.
Anyway. Brief synopsis over with. The point is that a lot of the above things are my own ideas, there isn't really anything out there (that I know of) that parses DWARF for data. There's no language out there (that I know of) that has such a clean interface between CPU and GPU, Runtime measurement and efficiency management built in, with persistence, complete independence from vendor tools. Etc. etc.
This isn't just a "hey Claude, build me a compiler, I want it to be rad, yo" minimal-effort thing - I've spent more than half a year doing this, there's been a lot of effort involved, steering, redirecting when things don't pan out, discussing, overrriding the recommended path in the name of future goals, etc.
Don't get me wrong, I've written compilers before, literal decades ago (I'm retired now), so I know just what a huge job it was to take on, and I'd never have attempted it myself if the LLM wasn't there to do the grunt work, but there's still a lot of "me" in this. My vision. My direction. My time.
What I have previously done is say "I" wrote the compiler (though that's been too subtle in the past) so I now tend to say "I wrote a compiler (full disclosure: with Claude)". And then I ignore the people who get upset about the LLM thing, you know, like water off a duck's back.