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.
> don’t tell me I did not “make” it because it simply would not exist if I hadn’t created it.
So like when I went to a restaurant last week and "made" a cheeseburger with no lettuce and extra onions, because it wouldn't exist if I hadn't created it.
To me, making something can mean you did the physical work of its creation even if there's no particular creative expression, like "I made a peanut butter and jelly sandwich."
It can also apply to tasks where you've offloaded a bunch of work that once would've been done by hand, like "I made this bench using a circular saw."
Where things get hairy even with physical objects is processes like CNC or 3D printers. If you download "Articulated dragon.stl" from a website and press the print button, did you make that? Personally, no. But if you designed your own flexy dragon and printed it, then yes. If you set up a relief carving on a CNC machine or do a perfectly fit inlay, are you making that? Operating these still takes quite a bit of knowledge and skill, but different knowledge and skill from hand woodworking. What if the tools improve and become very easy to operate?
I don't think there's a hard line you can draw. But if there is, it's somewhere between "did everything by hand with no assistance from recently invented tools because those are cheating" and "ordered a sandwich and waited for the finished result to show up."
This is why I like to draw a distinction between design, fabrication, and assembly. "Make" is too generic a word to convey what role you actually had in the creation of something, if you're actually trying to be precise. You can fabricate something with CNC tooling that someone else designed, and that can be its own quite substantial challenge, but it's a different challenge than that of the design. And you can assemble your own bookcase from the flatpack Ikea shipped you, but that's different than fabricating the flatpack in the first place.
You know Gaudí? He was a great architect, and made great constructions visited by millions, like Casa Batlló, Casa Milà, or la Sagrada Familia.
To be fair he didn't place a single stone, and la Sagrada Familia was finished long after his death.
So yes, I believe you can make products using LLMs.
If there is a line, it's definitely between "I designed the architecture, and decided on what each class should do, before letting AI do a single line" and "I told AI to clone twitter as is".
Although the latter could be akin to kids colouring books. "I made AI clone twitter, but painted it red and called it rettiw." As long as there was some decision or a modicum of effort it's "ok". We can let them have their victories and try again.
The restaurant comparison doesn't really hold up. The parent didn't go choose from a menu of new apps that they wanted AI to create. They discovered a problem or a feature that doesn't exist on other platforms and they employed tools to create that. Does a product manager not get to claim they "made" something because they plan it out and employ others to actually build the finished product?
Both of the examples the parent gave include some kind of planning and ideating to get to a final product, regardless of the fact that they employed tools to do a bulk of the coding work.
How do people imagine the process of creating software with AI? Tell it “I need an app where I can send images to friends” and accept the first result?
In your analogy, what I’m talking about is more like talking to a chef with the idea of a novel recipe and describing the ingredients and how you would like it to taste (of course also accepting suggestions).
I would take more pride in that meal than in a standard burger I completely cooked myself - maybe because I know I am able to prepare a great tasting burger and already did so many times. OTOH if this would be the first burger I made in my life I would be immensely proud of it.
When Claude Code/Codex first came about I'll admit it depressed me a bit, but I ended up realizing that the "code" part wasn't the part that I actually enjoyed about software engineering.
Instead, what I've been doing for my personal projects has been about designing algorithms with TLA+. I write that by hand, model check and sometimes even prove the properties I think are interesting or useful, and then tell Claude to implement it based on the spec. Usually I still need to correct the generated code but it's a lot less.
Certainly in these cases, I take pride in what I did, because ultimately the "Invisible Hand" always means I'm outsourcing some of the work of a project no matter how involved I want to be. If I build a deck outside, I'm not forging the nails myself, I'm not growing and chopping down the trees for lumber, I'm not designing my own power tools, etc. There's always a level of outsourcing of the work that I don't find interesting or that I don't know how to do, or don't have the resources to do myself.
With software, the parts that I end up feeling proudest of, and this predates widespread use of LLMs, are the algorithms and tricks I come up with to build something. When I figure out a way to avoid a lock, or figure out a way to use less memory, or figure out a way to increase throughput, I'm less concerned with the actual "code", and much more concerned about the "how".
I completely agree with you, because I usually think the same way and I'm more concerned with the result than the path taken to achieve it. But you shouldn't forget that there are definitely people who work the exact opposite way. They don't care at all about having something functional in their hands at the end, because they just enjoy the process of building. And as soon as it's finished, they tear it all down anyway just to start over again with a different approach.
I don't think the "would not exist if I hadn't created it" argument really works. If I delegate a project to someone else, and they do the project, does that mean I did it? In my mind, I could comfortably say I managed it, or I designed some parts of it, but I really couldn't take the credit for actually doing it. You wanted it to be done, so you asked someone to do it.
If anything, I would say your conclusion should be flipped: you didn't really do the "making," but you can still be proud of what you _did_ do: provide direction and a vision for a solution to a problem.
What about a director of a movie. They aren't responsible for the creative performances but they are certainly given a heap of credit for having made the movie.
I ask 10 actors for 10 scenes and I combine them into a movie I wanted.
I ask 10 agents for 10 functions and I combine them into a program I wanted.
What's the difference and why is the guy who used agents not credited the same way as a director? Maybe all that's missing is a long list of credits for everyone involved -- so transparency in who did what?
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).
But that’s just arguing about the meaning of the word “make” now.
The real discussion does not seem to be about words though but about value. If you find vibe-coded software worthless, you value the process and work that went into it more than the finished end product. I can fully understand this. But it’s just not the way I feel about it.
An LLM doesn't do anything on its own. One needs to make the choice to build something, make choices about how it's built, and make decisions on how it should work. The LLM makes the output of those decisions, but in the end it's just one of the tools that was used to make a part of the system that was built.
If all you care about is the end product and not how it's made, then you never become a better person. Your capacity for thinking and solving problems will never grow. You will never be an expert. Experts care about the process.
Of course, you may not care, and that's fine. It's important that people not be delusional about this though. A person with no medical knowledge and an AI will never be as good as someone with prodigious medical knowledge and an AI. The same is true for any profession, whether programming, music, writing, etc.
Of course. But I have been programming for over 30 years and I know that I cannot be an expert for everything.
Besides that, maybe my capacity for thinking won’t grow anymore. But my capacity for solving problems just exploded in the last few years thanks to AI.
In your examples, you didn’t “make” anything. The person whose work trained the LLM made the work. The landscaper made the lawn. I don’t know how it’s possible to take pride in doing nothing.
I can hire a maid to make my bed for me and tell her how exactly to fluff my pillows and duvet but I would take no pride in that.
That point was specifically addressed in the article.
Given that a compiler doesn't include a statistical model likely to create one's written Rust code, the compiled bytecode is quite clearly an expression of said writing.
Let’s not argue about the meaning of “making”, but that’s a very limited view of how value is created. So in your view the producer or even the director of a movie cannot take pride in it because the actors are the ones doing the work?
A large part of how actors act is specific cues given to them by the director, which is pretty clearly work by the director. A director also gives specific instructions for a lot of other things that have a noticeable impact on the resulting value of the movie.
That's different from telling a maid to generally clean your home. If you gave a maid specific instructions on how to clean and how to move things around in a way that made a noticeable impact on how clean your house ended up being, you could be proud of the managerial work you're doing. But no one does that, because people pay money to not have to work.
Likewise, if you just told an LLM to let it rip on a general task then you're not doing much work, but if you were managing the LLM to do specific things then you are doing significant work.
you can take pride in it, definitely added value
and also acknowledge that an actor turned director (to keep the metaphor going) may have different feelings about the process even if they are happy with the end result
similarly a coder turned manager or director may have some internal struggle with not actually doing the coding anymore -- similar to how one might feel having made a product or feature entirely with AI coding
Article does take a stance on the term "making" vs "having a hand in creation" fwiw. I guess the latter doesn't have a great term yet which is why an argument over the term making is sincere
Back when I was an OSU student I taught myself a lot about practical systems programming, and I was consulting Beej's Guide to Network Programming daily. I kept lamenting to myself that I wished the expensive university was proving as useful as this guy's free website.
Awesome that it has come full circle, great hire by someone.
I have a slightly different approach. I've done this as both a profession and a hobby for around 18 years now, and even these days i spend quite a bit of time "making" things i take pride in. Be it decisions (decision fatigue is a battle), code written, architectural improvements, etc. I don't generally feel lacking in this area.
Where i've felt lacking for the last ~5 years though is output. Specifically blocked by having the energy to create all these damn ideas.
I find LLMs neat, albeit their own type of exhausting, as they open up a lot of possibilities for things i want. Ie software i've wanted but have never cared to find the time for or didn't have the time for.
LLMs feel like a software equivalent to a 3D Printer. I don't have to carve it out of wood now. But also like a 3D printer there are some tasks that LLMs are just horrible for. So it's a niche, a skill even, to find software you want that also are a good for for unsupervised development. It's also of course massively more risky than a 3D printed doohickey depending on its internet access/etc.
With that said i still don't really take pride in something vibe coded. I just take enjoyment out of using a thing that i've wanted but never had time for.
> 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.
But does this mean that a 99.99% reliable LLM would turn us back into the mode of us building it again? I would not say so.
I think for tasks that are about decisions, having the LLM make decisions is what makes it feel like the LLM did something for me.
Consider mowing the lawn. Imagine I had a lawnmower robot that does the mowing all on its own. Despite perfect accuracy, I didn't mow the lawn; it did. If I sit on that lawnmower the whole time and start driving it instead of letting it go on its own, then I mowed the lawn. Even if I stand there and control it with a joystick, I still mowed the lawn. Ownership comes from the decisions about where to mow.
If the outcome is equivalent regardless which choices the LLM made, then these LLM decisions weren’t material for the outcome, and it would be fine for me. If the decisions don’t materially change the result, then it means that I can still reason about the output that will be produced. If, on the other hand, the decisions materially change the output, then this also breaks the ability for the prompter to predict what will be produced.
This is analogous to the compiler example: It generally doesn’t matter which exact variation of machine instructions the compiler chooses to generate from the source code. It doesn’t significantly impact the ability to predict the resulting program’s behavior in detail based on the source code.
This predictability relation is what allows the creator to reason about the creation, to reason about which exact change to apply to the input to effect a precise modification in the output.
In that sense, the robot lawnmower is like a compiler, if it yields the state of lawn that I specified. I largely don’t care if it first moved left or right, the same as I largely don’t care if a compiler translates a multiplication by a power of two with a shift instruction or a multiplication instruction.
However, we use LLMs precisely for their heuristics, for their property to actually make material choices. Therefore LLMs inherently conflict with the ability to reason about which exact input will yield which desired output.
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.
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.
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.
oh yeah I definitely have some flavor of ADHD, I'm not medicated so I just use music (looping a song or album over and over). Thankfully I have a chill job now where I don't have to get much work done, kind of coasting lately.
Currently trying to figure out the right kind of caffeine intake, seems hot chocolate might be my jam vs. coffee. I'm lucky we have a gym at work so I work out first 30 minutes of the day helps and do walks.
I have to grind on the side though to get out as I have $100K in debt. That six fig day job still means I'm check to check.
Hugely generous in all the work you put into the public domain and I've been reading your guides for years.
BTW I also started in computing in 1978 on a DEC 10 Mainframe (in Assembler and then C) and Lunar Lander was my first game but played on a DECwriter (basically a line printer with a keyboard).
One area that I find really compelling and useful now is controlling hardware that I've struggled to use in the past, like the BlackMagic ATEM video switcher/controller. They are very powerful and can turn your space into an incredible video studio. The software that ships with them is probably appropriate for experienced video techs. The last time I setup a studio to run a webinar with one it took me a couple of days to get it working how I needed.
Yes, I love tinkering with hardware so there is that and I did enjoy figuring it out.
Today I had a webinar that needed to be setup quickly and thought it would just be a raw Zoom feed. Instead, within an hour, I had a full video switching system with embedded graphics, feeds from a laptop configured with live content, multiple cameras, etc and a custom html page specific just to todays webinar to drive it all.
I've used a number of 3rd party apps for the ATEM series. They all have to boil the ocean.
This kind of personalized project tech is the perfect software hole for llm's to fill.
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.
It's the complete opposite for me, my interest in side projects has exploded.
It was never about writing every line by hand, it was about solving a problem and making my life better. LLMs let me do that at a speed never seen before.
I was and am and avid Home Assistant fan but the number of automations/scripts I now have is higher by a magnitude than ever before. Few things would reach the level where it made sense to spend my time writing and debugging a workflow but now I can speak my automations into existence.
Yesterday I got a candle warmer, I wanted to set it up so when I turned it on it started a timer to turn off and I wanted a push notification to see if I wanted to extend the timer when it was close to finishing. All things I knew were possible but HA YAML is miserable (all YAML is) and the UI is not much better (it's a hard problem, I get it). I prompted Claude and had a working implementation in <10min. Additionally it asked if I wanted to auto-turn off if I left the house (yes!) and if it should auto-start the timer if ever detected the candle warmer was on without a timer set (power loss, HA restart, manual interaction with warmer).
My HA automations have never been more bulletproof and if they do something wrong it's as simple as telling Claude Code and having it fix the problem. For example, my motion activated lights (motion sensor -> HA -> smart switch) were working great but I realize that while in the shower my main bathroom lights would sometimes turn off. 1 prompt later and Claude grouped up my motion sensor in the shower to the one in the bathroom so if motion on either was detected the lights would stay on but the shower light would only turn on if its motion detector detected motion.
HA is only one small part of my LLM usage but it's representative of my overall point.
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.
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.
Interesting - I'm just the opposite. I had 100 side projects rattling around in my skull for years but had no desire to spend even more time on the computer after all the time at work on one, even though all of them from a technical perspective were well within my skillset. So now I can actually get them out of my head and basically for free with almost no effort. Maybe the way we view side projects is different - if you were doing a side project just for the love of the game, then yes I can see LLM outputs not scratching that itch. But if you are doing the side project because of some tangible benefit of it, then LLMs are great.
We're in a big interconnected social system. If you're landing changes, it's dependent on the internal tooling, internal documentation, and the broader social system that you're a part of. Attachment to individual outcomes is the problem. The productivity comes from the integration.
Maybe the sense of alienation people are experiencing right now is because code is the one concrete thing they drive which is "independent" from this social matrix. Most of the real value I've ever delivered doing this SWE thing wasn't through code, it was through understanding the system, recognizing issues, and working with leadership on addressing them
I mean its not the same at all. There is a very satisfying and gratifying experience from writing software yourself, AI hardly comes close.
When writing the code and having to understand, I feel real connections being made in my brain and a deeper understanding of the language, domain area, and logical concepts. AI is simply not the same level of mental engagement and exertion.
But clearly for work/business requirements using AI is a no brainer for efficiency and speed(which are key concerns for a business). This is under the assumption that a professional is able to review and guide the agentic tooling for a proper output.
In order to truly be a professional in terms of software engineering, you need to write a significant amount of programs manually for some time. I don't think that people with 0 prior experience with programming will be effective if handed AI.
I use AI for programs for work, and have written manual programs in the past. I want to go back to writing things manually(as to not atrophy important brain regions) so will probably do some personal projects in this manner.
But I don't see a point in writing a book with AI, writing an email with AI, composing a message with AI. Because using AI is leveraging a predictive machine to expand on intent, and the intent in communicating is best done yourself.
In my opinion sending AI content as posts, messages, or correspondence is poor application of AI at best, downright disrespectful at worst.
> 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.
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.
>Convert this C program into x86_64 assembly for Linux.
I made this argument yesterday that this is the real breakthrough for coding. Languages, syntax, frameworks, etc. no longer matters. ASM, Fortran, even punch cards are back on the menu if you're bold enough to prompt for it.
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.
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.
Firstly, this is the best TLDR I've read in a while and it convinced me to read the whole thing.
> TLDR: I gain a lot of fulfillment by making things. I don't consider things built by others at my request to be made by me, and are therefore much less fulfilling. And then I feel sad. This article starts strong and then heads off into the weeds.
Secondly, maybe this conversations boils into: what level of abstraction are we comfortable working at?
I mean that to the tune of "To bake an apple pie, you must first create the universe".
Few people will create the universe (please introduce yourself, if you are one); some will buy the apples and the crust and put them together; some will make the crust from scratch; some will grow the apples from seed; some will follow a recipe; some will buy a frozen pie; some will simply buy the pie.
I think we can all agree that buying the pie is not baking it. But what about the others? To me, there's an argument that all of them are "baking the pie", just taking place at different levels of abstraction. And I think you can take pride in any of them, and hopefully more pride in whether the pie is delicious and well-shared.
>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 entirely agree with this take. I've used LLMs for "making purposes" in two fundamental scenarios so far: to write code in languages I'm not 100% familiar with, and to help with circuit design.
In the code scenario, I most likely won't go over the final result: for various reasons, I often lack the interest and drive to understand the nuts and bolts of it. So I'll just try to assess whether it's sufficiently good for my goals, and then move on.
But in the circuit design scenario, I only use it as a "technical expert" to bounce ideas back and forth with, and to explore concepts I don't fully grasp. I use it as a sort of ELI5 machine, and never ever ask it to do something for me - just to explain.
The fundamental difference in outcome is that I remember next to nothing about the code, and have no feeling of "ownership" over it, nor do I feel proud or care about it at all.
Conversely, I am incredibly proud of the PCBs and circuits I design, even if technically some parts of it came straight out of AI recommendations. I really feel like I did the job, and AI was just a helper tool to get the tough concepts untangled quicker in my head.
Ultimately I think if you delegate 100% of the work to AI, and don't care enough to use its output to at least learn something, it's only natural that you'll never feel any connection to it, let alone any sense of ownership over its output. Being the prompt author is simply not enough. That's why I think you hit the nail on the head there: deeply understanding the output is the key, I just couldn't put my finger on it before, and now I can. Thanks for that.
> 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.
Alongside understanding, you also loose taste and perception. You can still say whether some things is good or bad, especially if you interact with it, but you can no longer articulate why. And with perception loss, you can no longer preempt a bad situation as you lose your awareness of things.
So for you a car may be a vehicle that you drive around. But for a mechanics it's a much complex system. When something doesn't work, you will lack the vocabulary to express what's wrong. And even when everything works, you may not be able to explain how.
The thing is, LLM are very buggy translators. Agents in software development help because they provide a way for LLMs to verify their output. But correctness is very hard to express. OK for a simpler task, but not really for a complex systems. Just like fluency in a foreign language is not about knowing the rules of grammar and a lots of words, but also knowing the idioms and other figure of speech.
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.
There was this persistent meme in bodybuilding discussions - I don't know if it's still a thing - to say about steroids "well they're just a shortcut". The justification that it just got you faster to where you could have gotten slower naturally was used by former steroid users to justify themselves, as an accusation of cheating, as an accusation of laziness, and as hope for dreamers who go to the gym but do not see those extreme results. In reality, steroids do allow some to achieve a body that would not be possible under a natural/genetic with any amount of time due to how anabolism and catabolism balance and scale.
I think there's a lot of parallel with experienced programmers using LLMs and that idea about steroids that it just gets you there faster. I'm pretty sure I could eventually program most of the things I've used AI to write, and what it produces at the top end I/you can't really prove that I wouldn't have thought of it. But is that really true?
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:
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.
I think you nailed it. If the CNC machine makes your widget, then you made it. If it didn't make you the widget correctly, then you made a paperweight, and you're not a machinist, you're somebody making paperweights.
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.
> don’t tell me I did not “make” it because it simply would not exist if I hadn’t created it.
So like when I went to a restaurant last week and "made" a cheeseburger with no lettuce and extra onions, because it wouldn't exist if I hadn't created it.
To me, making something can mean you did the physical work of its creation even if there's no particular creative expression, like "I made a peanut butter and jelly sandwich."
It can also apply to tasks where you've offloaded a bunch of work that once would've been done by hand, like "I made this bench using a circular saw."
Where things get hairy even with physical objects is processes like CNC or 3D printers. If you download "Articulated dragon.stl" from a website and press the print button, did you make that? Personally, no. But if you designed your own flexy dragon and printed it, then yes. If you set up a relief carving on a CNC machine or do a perfectly fit inlay, are you making that? Operating these still takes quite a bit of knowledge and skill, but different knowledge and skill from hand woodworking. What if the tools improve and become very easy to operate?
I don't think there's a hard line you can draw. But if there is, it's somewhere between "did everything by hand with no assistance from recently invented tools because those are cheating" and "ordered a sandwich and waited for the finished result to show up."
This is why I like to draw a distinction between design, fabrication, and assembly. "Make" is too generic a word to convey what role you actually had in the creation of something, if you're actually trying to be precise. You can fabricate something with CNC tooling that someone else designed, and that can be its own quite substantial challenge, but it's a different challenge than that of the design. And you can assemble your own bookcase from the flatpack Ikea shipped you, but that's different than fabricating the flatpack in the first place.
You know Gaudí? He was a great architect, and made great constructions visited by millions, like Casa Batlló, Casa Milà, or la Sagrada Familia.
To be fair he didn't place a single stone, and la Sagrada Familia was finished long after his death.
So yes, I believe you can make products using LLMs.
If there is a line, it's definitely between "I designed the architecture, and decided on what each class should do, before letting AI do a single line" and "I told AI to clone twitter as is".
Although the latter could be akin to kids colouring books. "I made AI clone twitter, but painted it red and called it rettiw." As long as there was some decision or a modicum of effort it's "ok". We can let them have their victories and try again.
The restaurant comparison doesn't really hold up. The parent didn't go choose from a menu of new apps that they wanted AI to create. They discovered a problem or a feature that doesn't exist on other platforms and they employed tools to create that. Does a product manager not get to claim they "made" something because they plan it out and employ others to actually build the finished product?
Both of the examples the parent gave include some kind of planning and ideating to get to a final product, regardless of the fact that they employed tools to do a bulk of the coding work.
How do people imagine the process of creating software with AI? Tell it “I need an app where I can send images to friends” and accept the first result?
In your analogy, what I’m talking about is more like talking to a chef with the idea of a novel recipe and describing the ingredients and how you would like it to taste (of course also accepting suggestions).
I would take more pride in that meal than in a standard burger I completely cooked myself - maybe because I know I am able to prepare a great tasting burger and already did so many times. OTOH if this would be the first burger I made in my life I would be immensely proud of it.
When Claude Code/Codex first came about I'll admit it depressed me a bit, but I ended up realizing that the "code" part wasn't the part that I actually enjoyed about software engineering.
Instead, what I've been doing for my personal projects has been about designing algorithms with TLA+. I write that by hand, model check and sometimes even prove the properties I think are interesting or useful, and then tell Claude to implement it based on the spec. Usually I still need to correct the generated code but it's a lot less.
Certainly in these cases, I take pride in what I did, because ultimately the "Invisible Hand" always means I'm outsourcing some of the work of a project no matter how involved I want to be. If I build a deck outside, I'm not forging the nails myself, I'm not growing and chopping down the trees for lumber, I'm not designing my own power tools, etc. There's always a level of outsourcing of the work that I don't find interesting or that I don't know how to do, or don't have the resources to do myself.
With software, the parts that I end up feeling proudest of, and this predates widespread use of LLMs, are the algorithms and tricks I come up with to build something. When I figure out a way to avoid a lock, or figure out a way to use less memory, or figure out a way to increase throughput, I'm less concerned with the actual "code", and much more concerned about the "how".
I completely agree with you, because I usually think the same way and I'm more concerned with the result than the path taken to achieve it. But you shouldn't forget that there are definitely people who work the exact opposite way. They don't care at all about having something functional in their hands at the end, because they just enjoy the process of building. And as soon as it's finished, they tear it all down anyway just to start over again with a different approach.
I don't think the "would not exist if I hadn't created it" argument really works. If I delegate a project to someone else, and they do the project, does that mean I did it? In my mind, I could comfortably say I managed it, or I designed some parts of it, but I really couldn't take the credit for actually doing it. You wanted it to be done, so you asked someone to do it.
If anything, I would say your conclusion should be flipped: you didn't really do the "making," but you can still be proud of what you _did_ do: provide direction and a vision for a solution to a problem.
You're honest, but you'd make a terrible CEO in this day and age.
Those two qualities tend to go hand in hand
What about a director of a movie. They aren't responsible for the creative performances but they are certainly given a heap of credit for having made the movie.
I ask 10 actors for 10 scenes and I combine them into a movie I wanted.
I ask 10 agents for 10 functions and I combine them into a program I wanted.
What's the difference and why is the guy who used agents not credited the same way as a director? Maybe all that's missing is a long list of credits for everyone involved -- so transparency in who did what?
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).
But that’s just arguing about the meaning of the word “make” now. The real discussion does not seem to be about words though but about value. If you find vibe-coded software worthless, you value the process and work that went into it more than the finished end product. I can fully understand this. But it’s just not the way I feel about it.
> I can still take pride in something I “made” with an LLM
You didn't make it
An LLM doesn't do anything on its own. One needs to make the choice to build something, make choices about how it's built, and make decisions on how it should work. The LLM makes the output of those decisions, but in the end it's just one of the tools that was used to make a part of the system that was built.
Many people have a disillusion that an LLM is something more than a tool.
Seems pretty simple in your analogy.
You can be proud of having commissioned a thing… be it landscaping or software… just not for making anything you didn’t.
And of course there are shades of grey in between, depending on how critical you were to the doing.
If all you care about is the end product and not how it's made, then you never become a better person. Your capacity for thinking and solving problems will never grow. You will never be an expert. Experts care about the process.
Of course, you may not care, and that's fine. It's important that people not be delusional about this though. A person with no medical knowledge and an AI will never be as good as someone with prodigious medical knowledge and an AI. The same is true for any profession, whether programming, music, writing, etc.
Of course. But I have been programming for over 30 years and I know that I cannot be an expert for everything. Besides that, maybe my capacity for thinking won’t grow anymore. But my capacity for solving problems just exploded in the last few years thanks to AI.
In your examples, you didn’t “make” anything. The person whose work trained the LLM made the work. The landscaper made the lawn. I don’t know how it’s possible to take pride in doing nothing.
I can hire a maid to make my bed for me and tell her how exactly to fluff my pillows and duvet but I would take no pride in that.
Your compiler created the bytecode that the CPU runs. How can you take pride in writing your Rust code?
That point was specifically addressed in the article.
Given that a compiler doesn't include a statistical model likely to create one's written Rust code, the compiled bytecode is quite clearly an expression of said writing.
How can you take pride in writing a novel when it’s Notepad and Windows that is translating keystrokes to letters?
> I don’t know how it’s possible to take pride in doing nothing.
Aw, now I feel sad for you. It's definitely possible, and I do it every weekend.
I wish I could know that feeling
Let’s not argue about the meaning of “making”, but that’s a very limited view of how value is created. So in your view the producer or even the director of a movie cannot take pride in it because the actors are the ones doing the work?
A large part of how actors act is specific cues given to them by the director, which is pretty clearly work by the director. A director also gives specific instructions for a lot of other things that have a noticeable impact on the resulting value of the movie.
That's different from telling a maid to generally clean your home. If you gave a maid specific instructions on how to clean and how to move things around in a way that made a noticeable impact on how clean your house ended up being, you could be proud of the managerial work you're doing. But no one does that, because people pay money to not have to work.
Likewise, if you just told an LLM to let it rip on a general task then you're not doing much work, but if you were managing the LLM to do specific things then you are doing significant work.
you can take pride in it, definitely added value and also acknowledge that an actor turned director (to keep the metaphor going) may have different feelings about the process even if they are happy with the end result similarly a coder turned manager or director may have some internal struggle with not actually doing the coding anymore -- similar to how one might feel having made a product or feature entirely with AI coding
Article does take a stance on the term "making" vs "having a hand in creation" fwiw. I guess the latter doesn't have a great term yet which is why an argument over the term making is sincere
Whoa, I had no idea Beej is teaching at OSU!
Back when I was an OSU student I taught myself a lot about practical systems programming, and I was consulting Beej's Guide to Network Programming daily. I kept lamenting to myself that I wished the expensive university was proving as useful as this guy's free website.
Awesome that it has come full circle, great hire by someone.
I have a slightly different approach. I've done this as both a profession and a hobby for around 18 years now, and even these days i spend quite a bit of time "making" things i take pride in. Be it decisions (decision fatigue is a battle), code written, architectural improvements, etc. I don't generally feel lacking in this area.
Where i've felt lacking for the last ~5 years though is output. Specifically blocked by having the energy to create all these damn ideas.
I find LLMs neat, albeit their own type of exhausting, as they open up a lot of possibilities for things i want. Ie software i've wanted but have never cared to find the time for or didn't have the time for.
LLMs feel like a software equivalent to a 3D Printer. I don't have to carve it out of wood now. But also like a 3D printer there are some tasks that LLMs are just horrible for. So it's a niche, a skill even, to find software you want that also are a good for for unsupervised development. It's also of course massively more risky than a 3D printed doohickey depending on its internet access/etc.
With that said i still don't really take pride in something vibe coded. I just take enjoyment out of using a thing that i've wanted but never had time for.
> 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.
But does this mean that a 99.99% reliable LLM would turn us back into the mode of us building it again? I would not say so.
I think for tasks that are about decisions, having the LLM make decisions is what makes it feel like the LLM did something for me.
Consider mowing the lawn. Imagine I had a lawnmower robot that does the mowing all on its own. Despite perfect accuracy, I didn't mow the lawn; it did. If I sit on that lawnmower the whole time and start driving it instead of letting it go on its own, then I mowed the lawn. Even if I stand there and control it with a joystick, I still mowed the lawn. Ownership comes from the decisions about where to mow.
If the outcome is equivalent regardless which choices the LLM made, then these LLM decisions weren’t material for the outcome, and it would be fine for me. If the decisions don’t materially change the result, then it means that I can still reason about the output that will be produced. If, on the other hand, the decisions materially change the output, then this also breaks the ability for the prompter to predict what will be produced.
This is analogous to the compiler example: It generally doesn’t matter which exact variation of machine instructions the compiler chooses to generate from the source code. It doesn’t significantly impact the ability to predict the resulting program’s behavior in detail based on the source code.
This predictability relation is what allows the creator to reason about the creation, to reason about which exact change to apply to the input to effect a precise modification in the output.
In that sense, the robot lawnmower is like a compiler, if it yields the state of lawn that I specified. I largely don’t care if it first moved left or right, the same as I largely don’t care if a compiler translates a multiplication by a power of two with a shift instruction or a multiplication instruction.
However, we use LLMs precisely for their heuristics, for their property to actually make material choices. Therefore LLMs inherently conflict with the ability to reason about which exact input will yield which desired output.
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.
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.
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.
oh yeah I definitely have some flavor of ADHD, I'm not medicated so I just use music (looping a song or album over and over). Thankfully I have a chill job now where I don't have to get much work done, kind of coasting lately.
Currently trying to figure out the right kind of caffeine intake, seems hot chocolate might be my jam vs. coffee. I'm lucky we have a gym at work so I work out first 30 minutes of the day helps and do walks.
I have to grind on the side though to get out as I have $100K in debt. That six fig day job still means I'm check to check.
Your literally a legend IMHO.
Hugely generous in all the work you put into the public domain and I've been reading your guides for years.
BTW I also started in computing in 1978 on a DEC 10 Mainframe (in Assembler and then C) and Lunar Lander was my first game but played on a DECwriter (basically a line printer with a keyboard).
I'm still as passionate about IT as I was then!
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
One area that I find really compelling and useful now is controlling hardware that I've struggled to use in the past, like the BlackMagic ATEM video switcher/controller. They are very powerful and can turn your space into an incredible video studio. The software that ships with them is probably appropriate for experienced video techs. The last time I setup a studio to run a webinar with one it took me a couple of days to get it working how I needed. Yes, I love tinkering with hardware so there is that and I did enjoy figuring it out. Today I had a webinar that needed to be setup quickly and thought it would just be a raw Zoom feed. Instead, within an hour, I had a full video switching system with embedded graphics, feeds from a laptop configured with live content, multiple cameras, etc and a custom html page specific just to todays webinar to drive it all. I've used a number of 3rd party apps for the ATEM series. They all have to boil the ocean. This kind of personalized project tech is the perfect software hole for llm's to fill.
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'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.
It's the complete opposite for me, my interest in side projects has exploded.
It was never about writing every line by hand, it was about solving a problem and making my life better. LLMs let me do that at a speed never seen before.
I was and am and avid Home Assistant fan but the number of automations/scripts I now have is higher by a magnitude than ever before. Few things would reach the level where it made sense to spend my time writing and debugging a workflow but now I can speak my automations into existence.
Yesterday I got a candle warmer, I wanted to set it up so when I turned it on it started a timer to turn off and I wanted a push notification to see if I wanted to extend the timer when it was close to finishing. All things I knew were possible but HA YAML is miserable (all YAML is) and the UI is not much better (it's a hard problem, I get it). I prompted Claude and had a working implementation in <10min. Additionally it asked if I wanted to auto-turn off if I left the house (yes!) and if it should auto-start the timer if ever detected the candle warmer was on without a timer set (power loss, HA restart, manual interaction with warmer).
My HA automations have never been more bulletproof and if they do something wrong it's as simple as telling Claude Code and having it fix the problem. For example, my motion activated lights (motion sensor -> HA -> smart switch) were working great but I realize that while in the shower my main bathroom lights would sometimes turn off. 1 prompt later and Claude grouped up my motion sensor in the shower to the one in the bathroom so if motion on either was detected the lights would stay on but the shower light would only turn on if its motion detector detected motion.
HA is only one small part of my LLM usage but it's representative of my overall point.
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.
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.
Interesting - I'm just the opposite. I had 100 side projects rattling around in my skull for years but had no desire to spend even more time on the computer after all the time at work on one, even though all of them from a technical perspective were well within my skillset. So now I can actually get them out of my head and basically for free with almost no effort. Maybe the way we view side projects is different - if you were doing a side project just for the love of the game, then yes I can see LLM outputs not scratching that itch. But if you are doing the side project because of some tangible benefit of it, then LLMs are great.
We're in a big interconnected social system. If you're landing changes, it's dependent on the internal tooling, internal documentation, and the broader social system that you're a part of. Attachment to individual outcomes is the problem. The productivity comes from the integration.
Maybe the sense of alienation people are experiencing right now is because code is the one concrete thing they drive which is "independent" from this social matrix. Most of the real value I've ever delivered doing this SWE thing wasn't through code, it was through understanding the system, recognizing issues, and working with leadership on addressing them
I mean its not the same at all. There is a very satisfying and gratifying experience from writing software yourself, AI hardly comes close. When writing the code and having to understand, I feel real connections being made in my brain and a deeper understanding of the language, domain area, and logical concepts. AI is simply not the same level of mental engagement and exertion.
But clearly for work/business requirements using AI is a no brainer for efficiency and speed(which are key concerns for a business). This is under the assumption that a professional is able to review and guide the agentic tooling for a proper output. In order to truly be a professional in terms of software engineering, you need to write a significant amount of programs manually for some time. I don't think that people with 0 prior experience with programming will be effective if handed AI. I use AI for programs for work, and have written manual programs in the past. I want to go back to writing things manually(as to not atrophy important brain regions) so will probably do some personal projects in this manner.
But I don't see a point in writing a book with AI, writing an email with AI, composing a message with AI. Because using AI is leveraging a predictive machine to expand on intent, and the intent in communicating is best done yourself. In my opinion sending AI content as posts, messages, or correspondence is poor application of AI at best, downright disrespectful at worst.
I have been using vi/vim for 30 years and I had no idea about using ^K-M to insert an em-dash.
> 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.
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.
>Convert this C program into x86_64 assembly for Linux.
I made this argument yesterday that this is the real breakthrough for coding. Languages, syntax, frameworks, etc. no longer matters. ASM, Fortran, even punch cards are back on the menu if you're bold enough to prompt for it.
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.
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.
Firstly, this is the best TLDR I've read in a while and it convinced me to read the whole thing.
> TLDR: I gain a lot of fulfillment by making things. I don't consider things built by others at my request to be made by me, and are therefore much less fulfilling. And then I feel sad. This article starts strong and then heads off into the weeds.
Secondly, maybe this conversations boils into: what level of abstraction are we comfortable working at?
I mean that to the tune of "To bake an apple pie, you must first create the universe".
Few people will create the universe (please introduce yourself, if you are one); some will buy the apples and the crust and put them together; some will make the crust from scratch; some will grow the apples from seed; some will follow a recipe; some will buy a frozen pie; some will simply buy the pie.
I think we can all agree that buying the pie is not baking it. But what about the others? To me, there's an argument that all of them are "baking the pie", just taking place at different levels of abstraction. And I think you can take pride in any of them, and hopefully more pride in whether the pie is delicious and well-shared.
>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 entirely agree with this take. I've used LLMs for "making purposes" in two fundamental scenarios so far: to write code in languages I'm not 100% familiar with, and to help with circuit design.
In the code scenario, I most likely won't go over the final result: for various reasons, I often lack the interest and drive to understand the nuts and bolts of it. So I'll just try to assess whether it's sufficiently good for my goals, and then move on.
But in the circuit design scenario, I only use it as a "technical expert" to bounce ideas back and forth with, and to explore concepts I don't fully grasp. I use it as a sort of ELI5 machine, and never ever ask it to do something for me - just to explain.
The fundamental difference in outcome is that I remember next to nothing about the code, and have no feeling of "ownership" over it, nor do I feel proud or care about it at all.
Conversely, I am incredibly proud of the PCBs and circuits I design, even if technically some parts of it came straight out of AI recommendations. I really feel like I did the job, and AI was just a helper tool to get the tough concepts untangled quicker in my head.
Ultimately I think if you delegate 100% of the work to AI, and don't care enough to use its output to at least learn something, it's only natural that you'll never feel any connection to it, let alone any sense of ownership over its output. Being the prompt author is simply not enough. That's why I think you hit the nail on the head there: deeply understanding the output is the key, I just couldn't put my finger on it before, and now I can. Thanks for that.
> 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.
Alongside understanding, you also loose taste and perception. You can still say whether some things is good or bad, especially if you interact with it, but you can no longer articulate why. And with perception loss, you can no longer preempt a bad situation as you lose your awareness of things.
So for you a car may be a vehicle that you drive around. But for a mechanics it's a much complex system. When something doesn't work, you will lack the vocabulary to express what's wrong. And even when everything works, you may not be able to explain how.
The thing is, LLM are very buggy translators. Agents in software development help because they provide a way for LLMs to verify their output. But correctness is very hard to express. OK for a simpler task, but not really for a complex systems. Just like fluency in a foreign language is not about knowing the rules of grammar and a lots of words, but also knowing the idioms and other figure of speech.
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.
There was this persistent meme in bodybuilding discussions - I don't know if it's still a thing - to say about steroids "well they're just a shortcut". The justification that it just got you faster to where you could have gotten slower naturally was used by former steroid users to justify themselves, as an accusation of cheating, as an accusation of laziness, and as hope for dreamers who go to the gym but do not see those extreme results. In reality, steroids do allow some to achieve a body that would not be possible under a natural/genetic with any amount of time due to how anabolism and catabolism balance and scale.
I think there's a lot of parallel with experienced programmers using LLMs and that idea about steroids that it just gets you there faster. I'm pretty sure I could eventually program most of the things I've used AI to write, and what it produces at the top end I/you can't really prove that I wouldn't have thought of it. But is that really true?
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?
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...
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.
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.
> Does a machinist who uses CNC qualify as a machinist?
Yes. The CNC doesn't act on its own.
If I ask the CNC "make me a widget", am I a machinist?
I think you nailed it. If the CNC machine makes your widget, then you made it. If it didn't make you the widget correctly, then you made a paperweight, and you're not a machinist, you're somebody making paperweights.