Very well said. I don’t like seeing hackernews submissions that are LLM generated.
The joy of hackernews was seeing applied human ingenuity, most of these weren’t successful products anyway. Just like I don’t watch computer chess games, we should have an easy way to distinguish AI generated software, art etc and then I can happily avoid them.
This goes straight to the compiler and whether that precludes original craft. But I think it would be more relevant to discuss the use of open source packages.
Because I absolutely feel I made entire SaaS products, cool ones, by hand and they sat on a multitude of packages and infra I but glued together.
For frontend, I tailored templates, and instead put energy and time into making modern frontend toolchains and Django backends work together. This was satisfying to understand and build.
Being at ease with the minute details of Django or latest flags of esbuild felt like knowing the various modes of my Dewalt or Dewalt-colored power tools.
Building with AI is not a passive activity, and doing so well and efficiently, there is a ton to master and it evolved a great deal in the past six months.
So leveraging the tools using custom skills, custom CLIs, etc this is very important and very valuable thing to do. I would classify it as a serious contemporary computer science skill that should be taught in addition to the fundamentals.
Presume now, you're making and leveraging all of the modern bells and whistles of Claude Code and Codex. That is, you're reading the release notes and you have personal tooling so you can switch between them easily.
You can build incredible things with sustainable release workflows and reasonable security and possibly more than what a solo dev's "production quality" of yore.
I know this because I had Fable look at an entirely "hand crafted" SaaS I built over two years and it found about a page of bullets just in p0-p1 that I had not caught in my artisanal best effort. They were real issues, maybe unlikely but still things that I would have fixed if I had known.
But what can not be replaced is *taste*.
You can build all day and night and if it ain't good people won't use it. If you can't describe it in a way that makes sense to people they won't care.
If you build something people don't want you've not really made anything more than we did before we had AI as a tool.
I do think it can still achieve the same level of satisfaction if it is built well. Because it actually does take a lot of skill and knowledge to make something well using agentic programming. This is regardless of whether people want it.
I'm trying to get it back. I went through a period of 2 months or so where I didn't want to do anything not even watch TV except drink. So I've been sober for a couple weeks now, think I'm starting to get it back. But I'm still lazy af right now. I miss making hardware, I design/make my own cameras and little self navigating robots. I did finally fix my camera after it rolled across the floor of my car during a tight turn and something inside it broke/wouldn't turn on. Idk... I bought so many old vintage c-mount lenses and would take each one out, produce a video, and then I lost interest doing that... so now I have a bin of random vintage c-mount lenses and a desk trinket (camera). The positive though is I got two SWE jobs out of these hardware projects. But yeah hope I get it back.
I usually do instantly lose respect when I hear some project is vibe coded... I get that's how it is now but yeah. To me when you say "I made this" but it's actually claude code that shat out the code well... ultimately though it's about money and freedom. You can do whatever you want to do, I need to get my own freedom then do what I enjoy.
I think don't be too hard on yourself. If you haven't already, it may be worth considering whether ADHD or something else might be playing a role. We aren't machines, we're messy bundles of biology and understanding our own particular messy bundle can go a long way towards getting it rolling in the right
direction.
> And when I do have Claude create something for me, I just can't say that I made it. Other people can, but I just can't.
This is basically me. I still love having Claude build things for me, a lot of it is just things only I will ever use, but it fulfills my needs, and that's worth it for me.
I use it two ways I guess: to get unstuck while coding something myself, and to automate building side-projects I have no time for but that linger in my head for years.
> What's the real difference in that gray area? I'm not sure. I think it hinges on something that has to do with making versus asking to be made, even if that line isn't particularly clear.
For me the difference is in the extent that I can reason about how changes in the input affect the observable behavior of the output. When the executable the compiler outputs doesn’t behave in the way I intended, then in 99.99% of cases this is completely on me, and, importantly, I could have predicted it from the source code. Conversely, I can analyze any such misbehavior by reasoning on the source code. This doesn’t hold to any remotely comparable extent for the relation between vibecoded programs and the prompts used to create them.
Sounds very much like agency over the process versus agency over the outcome.
Some are ok with deciding if and when the process should be started and whether the outcome is good and bad. But often they lack the judgment to truly decide what is good and what is bad. They trust the makers to provide equally good options in terms of lower concerns (that matters to the makers) and only make the judgment according to some other concerns.
The main difference when using a compiler is that the compiler will (99.999...%) produce correct binary code for my programs and will fail loudly if it cannot. But the compiler is not concerned about correctness of the algorithm written in the programming language. Responsibilities are clearly outlined and the compiler does the job perfectly, while I try to do mine as well. So when I do a good job, I don't have to worry about the compiler part and I can assume the result will be good as well.
LLM usage has no such clear line. Assuming the user can judge whether the outcome is good or bad according to the prompt, the LLM tool is not reliable enough to produce a good result for everything that was not specified in the prompt. Which is different when collaborating with humans. If you say to a professional artist "I want a batman drawing", you needn't check for missing toes and the numbers of arms.
> Sounds very much like agency over the process versus agency over the outcome.
I don’t think that is right. It’s about controlling the outcome in a predictable manner. It’s about reasoning with precision about how your instructions translate to the outcome. It’s not about the process in between, but about how the two ends of the process (input and output) relate to each other.
I don’t want to judge the output unrelated to the input. Instead I want to be able to judge whether a given input will produce the desired output. I don’t want to roll a dice.
I know many people agree but I can’t really follow this sentiment. I can still take pride in something I “made” with an LLM even if I did not write a single line of code for it. I wouldn’t show it around and proclaim what a great programmer I am, because I did not program it, but coding was never the main goal, it was always the means to create the finished end product. When I plan a remake of my garden and then hire a professional landscaping company to build it, I can still sit on my patio in the sunset with a cold beer and be proud of my new cozy environment.
I feed the same way about software. My vibe coded guitar tab editor has features that no other software has that I needed and it’s solving a real problem I had. I would never have created it without AI, because I simply don’t have the time besides my job, family and other hobbies (like really practicing playing guitar). So fine, tell me I shouldn’t be proud of it, but don’t tell me I did not “make” it because it simply would not exist if I hadn’t created it.
To me there is a difference that lies in the words. E.g. `making` and `producing` both result in the creation of something, but `making` has a more active part while `producing` has a more supervisory part.
This became more relevant to me when I began meeting producers as a software engineer in game development.
To me, the idea is that you have something in your head and you want to "project" it into reality. I suppose the difference between makers and producers then is that makers happen to enjoy the labor part of that projection, while producers don't particularly care about it (nor want to care).
I found _many_ of my side projects just evaporated. Total disinterest. But some were now front and center. I think the distinction was some of them were for learning or technically complex accomplishments, and some were genuinely things I wanted to have/use. That second category is getting ground down by LLMs now, and I enjoy that. The first category has only a few very slow/analog learning projects left.
This is relatable. I find myself using LLMs more in cases where I don't care about learning and have made multiple tools to fir my workflow (Swift apps, etc. without ever touching Swift code). When it comes to things I do know about or want to learn about, I'm avoidant towards them because I know I can do better even if slower; but the procrastination for these has definitely turned into disinterest.
I'm the opposite. Between work and family, I don't get a lot of time to hole up in a cave with an IDE for fun. Prior to LLMs, it was a struggle to get much of anything done. So, I rarely tried. But, now I can get ideas fleshed out and even get code down in the small breaks I get to myself. Now I'm making progress where I wasn't before.
Sometimes I'm not interested in the inner workings of a technology, I just want a one-off tool. Ex: No interest in web tech. But, vibe-coded a tool to scrape and cross-reference a couple of online reports. Now I have the info I need for other projects.
Sometimes I know exactly what I want and it's quicker to hand-hold the AI through making it for me. Ex: Put together yet another SIMD math lib recently. SIMD intrisics are an obnoxious API. But, a non-SIMD implementation is easy to verify and many SIMD implementations are easy to validate vs. the non-SIMD reference. It's just a huge amount of obtuse code.
Sometimes I don't know exactly what I want and it's great to have a always-online partner to bounce questions off of, do rapid-prototyping for me, do code reviews for me. AIs aren't perfect. But, being instant, patient and often right makes them a huge improvement over online forums.
Exactly the opposite for me. I've gotten into a whirlwind of productivity, working through my lifetime backlog of "somebody out to do thing X" — now I'm doing ALL of them (all open source naturally), plus parametric 3d printing, hardware projects and more.
i guess there's different point of views here and it depends a lot on what you're trying to do.
As a swe i've always enjoyed the process of designing solutions to problems: design a great architecture, find the right abstractions that make everything fit naturally, write good clean code, etc ... that's what i enjoy doing.
Now there's the part where i've had these ideas for years that i've always though that i'd be cool to work on. But basically it would have required a 10 person team for months, out of reach. Now i have Claude, Codex and Grok and i've already built many projects.
The code isn't pretty, i didn't enjoy it as much as i would have if it were done manually, but i did something i never could have done otherwise.
There's some fun in the process though. I feel like a team manager and i occasionally step in to push for some architectural changes or code rewrites because things become too brittle because of not good enough architecture.
At least personally, parts of the differences for me are that the same instructions to a different CNC machine should produce the same product and that the machinist, presumably, created the instructions themselves.
Instead of saying "create instructions for CNC to make me a _thing_, then instruct the CNC machine to actually create the _thing_" they went and created the instructions themselves.
To some degree, some folks esp. for "lights out" machining are just pushing buttons and loading/unloading pallets of stock/parts, but usually the job description for that is "machine operator".
A machinist is expected to understand feeds and speeds and how they interact with toolpaths and materials and tooling.
The big question of course will be how things fall out with the on-coming generation of 5-axis machines which are intended to be AI-driven:
We continue to grapple with AI and how it's impacting our lives by trying to find comfort in comparisons to the past, or to other things that we do. But the reality is, there's never been anything quite like this before, and it's forcing us to redefine how we value work, art, craftsmanship, and output. Sometimes, those redefinitions are extremely uncomfortable.
How does this even contribute to the content posted?
The only thing being "redefined" is corporate agendas to push the bar of "good enough" lower to the point where it lies below cheap, and equals wasteful.
I agree with the article. I've never understood the notion of some LLM people saying you shouldn't care about the end result, and you should do it for its sake. It made me feel like a narcissist and that I was programming for showmanship, but I think making is inherent to (most) people's satisfaction and it's hard to tell something was made by you when all you did was prompting.
Maybe a hot take, but I do think, that even from seasoned developers, the idea they've been doing the 'logical' part so long they'd have it done anyway without AI and it'd only take more time is delusional, when, from personal experience, even when I code something I 'know' and I've 'done', I have to remember stuff, google what isn't ingrained in my brain, and so on.
I don't know if the author would consider this a part of making, but a single thing you build is, obviously, a mix of things you've built. I no longer sense this minor feeling of 'making' when I'm doing something. To make a logic that's part of a bigger system and see it running, thinking how it's gonna be once it's all done... I no longer feel that.
>It's not just the loss of the craft and the problem-solving challenge and whatever else. It's the loss of making.
It's the loss of understanding. When you make something, you gain a deeper appreciation for the nuance of all that is required to breath life into it. When you outsource understanding to another (agent, contractor, w/e), you're losing the nuanced understanding of the creation.
>After all, you create the prompts, don't you? You said you were proud of doing things. Isn't that doing a thing?
This feels like the difference between putting together an ikea futon and building a hand-hewn table from logs. The fidelity of your understanding is different depending on how deeply you're engaging. But not felling and drying your own timber doesn't mean you can never make something from dimensional lumber.
I'd take the author's word "making" to mean something more like "having enough understanding of the implementation of the task, that you could recreate the output without recourse to the same set of tools".
Tested against their examples:
>I had a new front deck put in [by a contractor]
As a consequence of this addition, did you learn enough about decks so that you could you reproduce this feat if no contractor were available? If no, you didn't make the deck. If yes, you were probably watching/helping the whole time, and you can claim (at least partial) makesmanship.
> any more than using a hammer to drive nails does.
If you didn't have access to the hammer, could you still accomplish the task of attaching two boards together with a nail? Likely yes, use a rock. It's harder, but the understanding of driving the nail is transferable to other implements.
> What if I had an AI-powered hammer and asked it to hit a nail for me? What's the difference? But at that point, I can't say that I hammered it.
This one contradicted his compiler example. He says that he did write the Fibonacci program, even if the AI-powered compiler translated it to assembly. So by similar reasoning, you can claim you hammered a nail with an AI hammer, so long as you understood the aspects of hammering which the AI took care for you to such a degree that you could reproduce the effects even in the absence of the AI hammer.
The crux of the tension is around "what did you learn from the implementation of this task". If you learned enough to reproduce the objective without the assistance of AI (perhaps much slower), then you can claim the high fidelity understanding that came from making. If you didn't internalize anything, and the AI/contractor managed complexity on your behalf, then the output was commissioned, not made.
I think where people get worked up about this, is that it's not easy to tell what understanding other folks are taking away from their AI usage. It does seem like a bifurcating event where some people are going to net gain understanding of their world due to these new tools, while others will net lose understanding.
Very well said. I don’t like seeing hackernews submissions that are LLM generated.
The joy of hackernews was seeing applied human ingenuity, most of these weren’t successful products anyway. Just like I don’t watch computer chess games, we should have an easy way to distinguish AI generated software, art etc and then I can happily avoid them.
This goes straight to the compiler and whether that precludes original craft. But I think it would be more relevant to discuss the use of open source packages.
Because I absolutely feel I made entire SaaS products, cool ones, by hand and they sat on a multitude of packages and infra I but glued together.
For frontend, I tailored templates, and instead put energy and time into making modern frontend toolchains and Django backends work together. This was satisfying to understand and build.
Being at ease with the minute details of Django or latest flags of esbuild felt like knowing the various modes of my Dewalt or Dewalt-colored power tools.
Building with AI is not a passive activity, and doing so well and efficiently, there is a ton to master and it evolved a great deal in the past six months.
So leveraging the tools using custom skills, custom CLIs, etc this is very important and very valuable thing to do. I would classify it as a serious contemporary computer science skill that should be taught in addition to the fundamentals.
Presume now, you're making and leveraging all of the modern bells and whistles of Claude Code and Codex. That is, you're reading the release notes and you have personal tooling so you can switch between them easily.
You can build incredible things with sustainable release workflows and reasonable security and possibly more than what a solo dev's "production quality" of yore.
I know this because I had Fable look at an entirely "hand crafted" SaaS I built over two years and it found about a page of bullets just in p0-p1 that I had not caught in my artisanal best effort. They were real issues, maybe unlikely but still things that I would have fixed if I had known.
But what can not be replaced is *taste*.
You can build all day and night and if it ain't good people won't use it. If you can't describe it in a way that makes sense to people they won't care.
If you build something people don't want you've not really made anything more than we did before we had AI as a tool.
I do think it can still achieve the same level of satisfaction if it is built well. Because it actually does take a lot of skill and knowledge to make something well using agentic programming. This is regardless of whether people want it.
ps Go Beavers.
I'm trying to get it back. I went through a period of 2 months or so where I didn't want to do anything not even watch TV except drink. So I've been sober for a couple weeks now, think I'm starting to get it back. But I'm still lazy af right now. I miss making hardware, I design/make my own cameras and little self navigating robots. I did finally fix my camera after it rolled across the floor of my car during a tight turn and something inside it broke/wouldn't turn on. Idk... I bought so many old vintage c-mount lenses and would take each one out, produce a video, and then I lost interest doing that... so now I have a bin of random vintage c-mount lenses and a desk trinket (camera). The positive though is I got two SWE jobs out of these hardware projects. But yeah hope I get it back.
I usually do instantly lose respect when I hear some project is vibe coded... I get that's how it is now but yeah. To me when you say "I made this" but it's actually claude code that shat out the code well... ultimately though it's about money and freedom. You can do whatever you want to do, I need to get my own freedom then do what I enjoy.
I think don't be too hard on yourself. If you haven't already, it may be worth considering whether ADHD or something else might be playing a role. We aren't machines, we're messy bundles of biology and understanding our own particular messy bundle can go a long way towards getting it rolling in the right direction.
I struggle to even remember the course grained details of things I've had AI do recently.
Conversely, there are 100k+ LoC codebases from years ago that I can still generally walk through in my mind's eye
> And when I do have Claude create something for me, I just can't say that I made it. Other people can, but I just can't.
This is basically me. I still love having Claude build things for me, a lot of it is just things only I will ever use, but it fulfills my needs, and that's worth it for me.
I use it two ways I guess: to get unstuck while coding something myself, and to automate building side-projects I have no time for but that linger in my head for years.
> What's the real difference in that gray area? I'm not sure. I think it hinges on something that has to do with making versus asking to be made, even if that line isn't particularly clear.
For me the difference is in the extent that I can reason about how changes in the input affect the observable behavior of the output. When the executable the compiler outputs doesn’t behave in the way I intended, then in 99.99% of cases this is completely on me, and, importantly, I could have predicted it from the source code. Conversely, I can analyze any such misbehavior by reasoning on the source code. This doesn’t hold to any remotely comparable extent for the relation between vibecoded programs and the prompts used to create them.
This seems like a very clear way of thinking about it.
In making something, you develop a tangible understanding of and opinions for how and why your creation is how it is.
I have a lot of vibecoded projects. I feel "ownership" in varying degrees proportional to the amount of care and depth I put into them.
Sounds very much like agency over the process versus agency over the outcome.
Some are ok with deciding if and when the process should be started and whether the outcome is good and bad. But often they lack the judgment to truly decide what is good and what is bad. They trust the makers to provide equally good options in terms of lower concerns (that matters to the makers) and only make the judgment according to some other concerns.
The main difference when using a compiler is that the compiler will (99.999...%) produce correct binary code for my programs and will fail loudly if it cannot. But the compiler is not concerned about correctness of the algorithm written in the programming language. Responsibilities are clearly outlined and the compiler does the job perfectly, while I try to do mine as well. So when I do a good job, I don't have to worry about the compiler part and I can assume the result will be good as well.
LLM usage has no such clear line. Assuming the user can judge whether the outcome is good or bad according to the prompt, the LLM tool is not reliable enough to produce a good result for everything that was not specified in the prompt. Which is different when collaborating with humans. If you say to a professional artist "I want a batman drawing", you needn't check for missing toes and the numbers of arms.
> Sounds very much like agency over the process versus agency over the outcome.
I don’t think that is right. It’s about controlling the outcome in a predictable manner. It’s about reasoning with precision about how your instructions translate to the outcome. It’s not about the process in between, but about how the two ends of the process (input and output) relate to each other.
I don’t want to judge the output unrelated to the input. Instead I want to be able to judge whether a given input will produce the desired output. I don’t want to roll a dice.
I know many people agree but I can’t really follow this sentiment. I can still take pride in something I “made” with an LLM even if I did not write a single line of code for it. I wouldn’t show it around and proclaim what a great programmer I am, because I did not program it, but coding was never the main goal, it was always the means to create the finished end product. When I plan a remake of my garden and then hire a professional landscaping company to build it, I can still sit on my patio in the sunset with a cold beer and be proud of my new cozy environment. I feed the same way about software. My vibe coded guitar tab editor has features that no other software has that I needed and it’s solving a real problem I had. I would never have created it without AI, because I simply don’t have the time besides my job, family and other hobbies (like really practicing playing guitar). So fine, tell me I shouldn’t be proud of it, but don’t tell me I did not “make” it because it simply would not exist if I hadn’t created it.
To me there is a difference that lies in the words. E.g. `making` and `producing` both result in the creation of something, but `making` has a more active part while `producing` has a more supervisory part.
This became more relevant to me when I began meeting producers as a software engineer in game development.
To me, the idea is that you have something in your head and you want to "project" it into reality. I suppose the difference between makers and producers then is that makers happen to enjoy the labor part of that projection, while producers don't particularly care about it (nor want to care).
This, I’ve completely lost interest in side projects outside of work since the emergence of LLMs. It does nothing for me any more
I found _many_ of my side projects just evaporated. Total disinterest. But some were now front and center. I think the distinction was some of them were for learning or technically complex accomplishments, and some were genuinely things I wanted to have/use. That second category is getting ground down by LLMs now, and I enjoy that. The first category has only a few very slow/analog learning projects left.
This is relatable. I find myself using LLMs more in cases where I don't care about learning and have made multiple tools to fir my workflow (Swift apps, etc. without ever touching Swift code). When it comes to things I do know about or want to learn about, I'm avoidant towards them because I know I can do better even if slower; but the procrastination for these has definitely turned into disinterest.
I'm the opposite. Between work and family, I don't get a lot of time to hole up in a cave with an IDE for fun. Prior to LLMs, it was a struggle to get much of anything done. So, I rarely tried. But, now I can get ideas fleshed out and even get code down in the small breaks I get to myself. Now I'm making progress where I wasn't before.
Sometimes I'm not interested in the inner workings of a technology, I just want a one-off tool. Ex: No interest in web tech. But, vibe-coded a tool to scrape and cross-reference a couple of online reports. Now I have the info I need for other projects.
Sometimes I know exactly what I want and it's quicker to hand-hold the AI through making it for me. Ex: Put together yet another SIMD math lib recently. SIMD intrisics are an obnoxious API. But, a non-SIMD implementation is easy to verify and many SIMD implementations are easy to validate vs. the non-SIMD reference. It's just a huge amount of obtuse code.
Sometimes I don't know exactly what I want and it's great to have a always-online partner to bounce questions off of, do rapid-prototyping for me, do code reviews for me. AIs aren't perfect. But, being instant, patient and often right makes them a huge improvement over online forums.
Exactly the opposite for me. I've gotten into a whirlwind of productivity, working through my lifetime backlog of "somebody out to do thing X" — now I'm doing ALL of them (all open source naturally), plus parametric 3d printing, hardware projects and more.
I have been using vi/vim for 30 years and I had no idea about using ^K-M to insert an em-dash.
i guess there's different point of views here and it depends a lot on what you're trying to do.
As a swe i've always enjoyed the process of designing solutions to problems: design a great architecture, find the right abstractions that make everything fit naturally, write good clean code, etc ... that's what i enjoy doing.
Now there's the part where i've had these ideas for years that i've always though that i'd be cool to work on. But basically it would have required a 10 person team for months, out of reach. Now i have Claude, Codex and Grok and i've already built many projects.
The code isn't pretty, i didn't enjoy it as much as i would have if it were done manually, but i did something i never could have done otherwise.
There's some fun in the process though. I feel like a team manager and i occasionally step in to push for some architectural changes or code rewrites because things become too brittle because of not good enough architecture.
Does a machinist who uses CNC qualify as a machinist?
Is his required knowledge of metals, assembly complexity, tolerances, just waved away because he doesn't turn the dials or change the tools any more?
At least personally, parts of the differences for me are that the same instructions to a different CNC machine should produce the same product and that the machinist, presumably, created the instructions themselves.
Instead of saying "create instructions for CNC to make me a _thing_, then instruct the CNC machine to actually create the _thing_" they went and created the instructions themselves.
yeah I think he's not an 'artisan' anymore at least not in an applied way. They're more of a technician at that point.
Depends.
To some degree, some folks esp. for "lights out" machining are just pushing buttons and loading/unloading pallets of stock/parts, but usually the job description for that is "machine operator".
A machinist is expected to understand feeds and speeds and how they interact with toolpaths and materials and tooling.
The big question of course will be how things fall out with the on-coming generation of 5-axis machines which are intended to be AI-driven:
https://toolguyd.com/new-ai-powered-desktop-cnc-machines-202...
We continue to grapple with AI and how it's impacting our lives by trying to find comfort in comparisons to the past, or to other things that we do. But the reality is, there's never been anything quite like this before, and it's forcing us to redefine how we value work, art, craftsmanship, and output. Sometimes, those redefinitions are extremely uncomfortable.
How does this even contribute to the content posted?
The only thing being "redefined" is corporate agendas to push the bar of "good enough" lower to the point where it lies below cheap, and equals wasteful.
I agree with the article. I've never understood the notion of some LLM people saying you shouldn't care about the end result, and you should do it for its sake. It made me feel like a narcissist and that I was programming for showmanship, but I think making is inherent to (most) people's satisfaction and it's hard to tell something was made by you when all you did was prompting.
Maybe a hot take, but I do think, that even from seasoned developers, the idea they've been doing the 'logical' part so long they'd have it done anyway without AI and it'd only take more time is delusional, when, from personal experience, even when I code something I 'know' and I've 'done', I have to remember stuff, google what isn't ingrained in my brain, and so on.
I don't know if the author would consider this a part of making, but a single thing you build is, obviously, a mix of things you've built. I no longer sense this minor feeling of 'making' when I'm doing something. To make a logic that's part of a bigger system and see it running, thinking how it's gonna be once it's all done... I no longer feel that.
>It's not just the loss of the craft and the problem-solving challenge and whatever else. It's the loss of making.
It's the loss of understanding. When you make something, you gain a deeper appreciation for the nuance of all that is required to breath life into it. When you outsource understanding to another (agent, contractor, w/e), you're losing the nuanced understanding of the creation.
>After all, you create the prompts, don't you? You said you were proud of doing things. Isn't that doing a thing?
This feels like the difference between putting together an ikea futon and building a hand-hewn table from logs. The fidelity of your understanding is different depending on how deeply you're engaging. But not felling and drying your own timber doesn't mean you can never make something from dimensional lumber.
I'd take the author's word "making" to mean something more like "having enough understanding of the implementation of the task, that you could recreate the output without recourse to the same set of tools".
Tested against their examples:
>I had a new front deck put in [by a contractor]
As a consequence of this addition, did you learn enough about decks so that you could you reproduce this feat if no contractor were available? If no, you didn't make the deck. If yes, you were probably watching/helping the whole time, and you can claim (at least partial) makesmanship.
> any more than using a hammer to drive nails does.
If you didn't have access to the hammer, could you still accomplish the task of attaching two boards together with a nail? Likely yes, use a rock. It's harder, but the understanding of driving the nail is transferable to other implements.
> What if I had an AI-powered hammer and asked it to hit a nail for me? What's the difference? But at that point, I can't say that I hammered it.
This one contradicted his compiler example. He says that he did write the Fibonacci program, even if the AI-powered compiler translated it to assembly. So by similar reasoning, you can claim you hammered a nail with an AI hammer, so long as you understood the aspects of hammering which the AI took care for you to such a degree that you could reproduce the effects even in the absence of the AI hammer.
The crux of the tension is around "what did you learn from the implementation of this task". If you learned enough to reproduce the objective without the assistance of AI (perhaps much slower), then you can claim the high fidelity understanding that came from making. If you didn't internalize anything, and the AI/contractor managed complexity on your behalf, then the output was commissioned, not made.
I think where people get worked up about this, is that it's not easy to tell what understanding other folks are taking away from their AI usage. It does seem like a bifurcating event where some people are going to net gain understanding of their world due to these new tools, while others will net lose understanding.
I’m not clicking the link to an adult website. Surely this violate some kind of content guidelines.