Your grandparents lived in an era where it was common for men to build their own homes.
Your parents lived in an era where it was inconceivable for a piece of furniture to not come fully assembled in their per-fabricated home.
We now live in an era where homes are made in mass scale and we assemble our own furniture. Did I make an IKEA table? I don't know. I paid for it, drove it home, and assembled the machined parts and added the same size Allen key to my collection. It's certainly not a table without my contribution. But I couldn't have built it myself from scratch.
I now tell the computer with the magic words please and thank you because I skimmed a research paper saying it'll be more cooperative in completing my tasks.
Did I make a game in unity where I just mishmoshed the preassembled assets together? I don't know. The only difference between IKEA furniture and my game is the permutations of my asset combinations, really.
Also in vibed projects that I put my time on. It is also true that it's been a long time without going back to a class or system I coded by hand just to "admire it" and get that feeling of, "omg, this class is fire!"
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.
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.
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.
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 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.
Conversely, there are 100k+ LoC codebases from years ago that I can still generally walk through in my mind's eye
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!
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.
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
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 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.
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.
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.
> 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 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.
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.
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?