Comment by rvz

I think the "nerds (like me)" part of your observation is something that a lot of AI-enthusiast nerds seriously underestimate. For as long as there's been personal computing, there's been a narrative that everyone would be a programmer if we just made it easier for everyone to program, and we've seen attempt after attempt after attempt to introduce new technologies that will surely, surely, be the key to unlocking this. What we don't seem to consider is the vast circumstantial evidence that the vast majority of users are simply not interested in creating tools, automations, widgets, etc., and never will be.

For my part, I am not only a nerd, I am literally an Emacs-using nerd, and I am not interested in using LLMs to create a plethora of bespoke applications that are subtle tweaks on existing tools. I haven't ruled out using AI to assist in helping me with a program that I've been wanting to write for years, but a lot of what's blocking me on that is figuring out design aspects that an LLM wouldn't be able to help me with in the first place. (I'm also concerned about "vibe-coding" programs that I don't 100% understand, at least if they're programs that I might ever want to release into the world.)

> But I find it a little extreme to say "it's faster to build your own than to install an existing alternative".

Installing an existing alternative might be easy ... once you found the one which best (i.e. mostly) matches your requirements. The time consuming task IMO is the time needed to find and then choose between half a dozen (or so) alternatives which all might do the job ... until you installed them, tested them, and found that they are insufficient for the job you expect them to do.

Also, as someone who has developed an ever growing suite of bespoke tools for my personal workflows using Codex/Gemini CLI over the last year, something I don’t see mentioned as often is the “mental overhead” of self-designed apps.

Even if the coding process itself is “effortless” and the agent just churns away to implement whatever I ask for on a dime, it can become exhausting thinking through all my needs/wants, tradeoffs, API shape etc. Despite not needing to write a line of code myself or read more than excerpts in the chat it can turn into a slog after the honeymoon period passes and it starts to feel like unpaid work.

I’ve had moments where I’m relieved to discover a popular open source tool that works out-of-the-box as an alternative to my own so I can offload that organizational overhead and decision fatigue to someone else. While benefiting from all their features/enhancements I didn’t have to design or maintain myself over time.

As an example, I had been building a TUI/web app to download and organize ebooks from various sources like Project Gutenberg or Anna’s Archive with a central meta search, and manage my personal library. It solved the immediate problem at the time but I kept needing to add missing features, plug holes in the various search integrations, UI refinements, etc and it never quite worked exactly as I wanted so kept having to work on it and became less and less fun as time went on.

Then I discovered Calibre Web Automated + Shelfmark on GitHub that did 99% of what I needed plus a lot more and overall had a level of polish and reliability my tool never reached. Now I just pull a Docker container every so often for updates and made a few tweaks to syncing but overall spend vastly more time on actually reading/organizing/growing my library vs. increasingly tedious vibe coding sessions and it feels so much more enjoyable.

I still have plenty of self-designed tools and continue making new ones but now tend to reach for an existing, off-the-shelf option first whenever possible for anything more complex than a one-off script. That way I can benefit from a community collectively contributing to improve and maintain the project over time without needing to become an unpaid Product Manager, Lead Designer, Senior Developer and QA Manager for everything I use.

I hope the current period of exuberance around LLM development doesn’t lead to everyone becoming stuck in individual silos duplicating work that in the past could have been directed to an OSS project where that time investment could be shared with everyone else and benefit from way more eyes catching bugs and smoothing off rough edges.