4 ms·

One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most peo

by simonw 3mo ago

One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I think LLMs have changed that equation in a way that makes the original dream much more feasible. Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn't bother. Now I treat that as a zero time investment challenge: tell Codex or Claude Code to checkout and build X and then come back ten minutes later and see how it got on. I'm not habitually modifying the software I use yet, but I can see a path to that which didn't exist a year or so ago.

imrehg 3mo ago
I have sent countless small bug fixes even before, to tools that I use that I could dig into when something was off... No big heavy lifting, but plenty of "tinker on your tools" stuff. And I don't think what I did was that special, so maybe the experiences are different? The current LLM-driven stuff seems to break down the expectations, and now there are a lot of places which just ignore anything I send in (the same tinkers as before), generally, for a while. Though there are some tools that picked up the pace and actually react faster (so YMMV here too). But there are few things more frustrating as being half-way. Case to point is LM Studio. It's closed source, has bugs (duh!), and there's at least a GitHub issue tracker to report the bugs -- but then by and large nothing happens to those reported things. It's almost worse than not having an issue tracker (then I could justify never to really touch LM Studio again, this way I keep hoping against hope that reports will turn into fixes and thus I keep using and keep reporting...)
- ravenstine 3mo ago
  That's my biggest gripe with open source software. It's not really the open source part that's bad, but when projects turn into major projects with a substantial user base, I think the owners have an obligation not to delude their users into thinking they have more say than they actually do. Plenty of big projects leave their issue trackers public and have docs that encourage community contribution, yet effectively ignore user submissions unless perhaps someone with a name raises an issue. I completely agree that allowing users to waste their time believing their issue or pull request can make a difference is actually worse than not allowing public submissions in the first place. I'm not sure why I seem to be in the minority on this. Maybe I've just had bad luck in that most of the issues and PRs I've submitted to open source have been ignored. Hell, I'd prefer a "thanks but no thanks" or even "fuck you" over radio silence. The typical response to this frustration of mine is "just fork the code, bro", which is absurd because forking should be a last resort for software that thrives from having a community.
  - zephen 3mo ago
    > which is absurd because forking should be a last resort for software that thrives from having a community. This is true, of course, but having a community is completely orthogonal to whether software is open or closed source.
    - bonoboTP 3mo ago
      The two are correlated which does encourage that mistaken view. Github culture generally blends these two, having an open issue tracker, pull requests etc. as well as the code right there, often with a free license. But you can very much allow bug reports and feature requests in public while developing proprietary software and you can also very much work on a project alone or with a small group without being open to random patches, contributions or requests and be open source / FLOSS. The key definitional question is the license, not any of the cultural stuff.
      - zephen 3mo ago
        Plenty of proprietary packages had robust communities well before anything like github existed. In fact, github is arguably a poor substitute for a community. Look at how communities such as the ones around the linux kernel or cPython communicate. It sure as shit isn't through issues or pull requests. Or rather, perhaps, the limited technical communication that an issue tracker is good for is not a valid large community consensus building mechanism. > The key definitional question is the license, not any of the cultural stuff. For direct modification, certainly. For customization, maybe. For ignored issues like the parent to my original comment was bemoaning? Maybe LLMs are good enough that we are almost ready to say "Make me a custom version of Photoshop" and then it doesn't matter.
        bonoboTP 3mo ago
        Yes. I've actually added some features to Blender like this, related to some highly specific use case. Just clone the source point an agent at it, say what you'd want (you have to be able to formulate this in a halfway coherent way), and it succeeded. Now, I haven't thought much about what it would mean to maintain this, but I think if I need this ever again, I can point an AI to it again and say "do the equivalent change now to the latest version". For occasional use this is fine.
- fleventynine 3mo ago
  The solution for this is to pay open source maintainers for their attention. If I want them to review and merge my bugfix I should attach $1000 to the PR.
  - jbritton 3mo ago
    Maybe a donate link attached too. The dollars tied to a PR could help set priority of fixes.
  - mbreese 3mo ago
    This is actually not a bad idea for funding open source software. It used to be that you’d have an author who coded a project and then could fix the occasional bug or two quickly. Now, we have larger projects where it is rare for one people to have a complete understanding, and the main value is a person to reviewing patches and bugs to make sure the changes align with the larger goals/path for the project. There is little incentive for a maintainer to do this, aside from wanting to limit forks. Paying for that review might be the way to keep this whole model sustainable.
    - katbyte 3mo ago
      Opportunity for gh “Here is my pr I attach x$ payable when it is merged” and allow me to add $ to other prs. I have been waiting year + for multiple feature in some projects that have open prs and for one I would easily bid 100-200$
      - nightshift1 3mo ago
        [dead]
  - theshrike79 3mo ago
    Maybe instead of the emoji buttons Github should let people attach money to the issue. If that gets fixed, the project gets the money.
2190asfg 3mo ago
[flagged]
- not-kinsale-joe 3mo ago
  What do you mean by this?
  - simonw 3mo ago
    I think they're suggesting that because I blog about AI I get free tokens and don't have a conception of how much they cost? I currently spend $100/month on OpenAI and $200/month on Anthropic. (I often get free tokens as part of preview access to models, but I'm not allowed to share any code written by those models online for the duration of the preview. Most of my work is open source, so I can't actually do much with those free tokens!)
- nh23423fefe 3mo ago
  I wasted time trying to understand sarcasm instead of being given a clear point to read. Bad human.
  - BigTTYGothGF 3mo ago
    > I wasted time trying to understand sarcasm Skill issue.
    - nh23423fefe 3mo ago
      another very original human repeating the meme
      - BigTTYGothGF 3mo ago
        Cliches are cliches for a reason.
zdragnar 3mo ago
> One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The canonical example was RMS needing to fix a printer driver bug back before software updates were really a thing. That meant that there was a greater motivation for users to maintain their changes. Today, with software being an evergreen stack of turtles from the BIOS all the way up the OS to the remote APIs the qpp interacts with, expecting a user to indefinitely maintain their private fork of any software is a really big stretch. Unless it is a local-only, unmaintained project that doesn't get deployed through a software repository or an app store, I think that original vision of open source software is very much the exception and not the rule.
- bonoboTP 3mo ago
  > I think that original vision of open source software is very much the exception and not the rule. RMS has never supported open source. And never emphasized software repositories or deployment or app stores or whatever. He is a proponent of free software based on ethical motivations, to allow users the freedom to control how their computing is done. It perfectly fits the local-only personal project.
throwatdem12311 3mo ago
Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date. I used AI to help me make a change to a library I use that ended up being a single line of code. The pull request was refused for having a Claude attribution even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support (so I considered this incompatibility a bug). Ended up figuring out a workaround in our application code instead just so we could use the upstream. Still not really worth the effort for most projects even with AI. In the era of AI slop being bombarded at you from all sides 24/7 I don’t blame them. Gatekeeping is the only way to maintain a semblance of quality (and sanity). Once you let slop in it accumulates at an insane rate. You need zero tolerance or you will be overwhelmed.
- throwaway27448 3mo ago
  > even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support It seems like a great stretch to call this "slop".
  - throwatdem12311 3mo ago
    I agree but it’s their project and their rules. To them I’m just another guy tossing slop over the fence they don’t have time to review in the hig stack of all the other slop.
- simonw 3mo ago
  > Then you’re maintaining a stack of patches on top of the upstream until the end of time The linked article has an ambitious solution for that, in the form of this prompt to a coding agent harness: Set up a nightly cron job that executes the prompt: fetch upstream changes to the <software> and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version.
hgomersall 3mo ago
Ha, yes! A few times I've had a back and forth with Claude about why software X isn't working as I expected it to, with Claude coming up with more and more ludicrous explanations, and in the end I say, "just go and read the code", and it remembers it can do that and goes and does it and then finds the bug, or the weird UX design or whatever. It's really helpful.
- mrheosuper 3mo ago
  i have the opposite problem, sometime i tell it to read the doc/header to understand how to use API, but then it proceeds to dive into the SDK to read the source, which is not a bad thing but that takes both time and a lot of token
brunoborges 3mo ago
> I think LLMs have changed that equation in a way that makes the original dream much more feasible. > Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". Still highly dependant on one's access to SOTA AI models (availability and funding). Most people praising LLMs publicly for this sort of use case, are the ones with unlimited access to tokens / AI credits, or simply with a lot of money to burn. But reality is that between using one's limited employer-sponsored quota of tokens to do their 9-5 business logic coding maintenance job, versus exploring 3rd-party software as end-users, I am sure of which one their managers will prefer. I believe it will eventually happen, whether with SOTA local models on highly capable local hardware, or super cheap inference APIs... or both.
- simonw 3mo ago
  I've gone back and forth on this. A couple of years ago LLM prompts really were incredibly cheap and falling in price. OpenAI's own models had fallen in cost by a factor of about 1000x since GPT-3. They were also cheap because many of the things you might want to do with an LLM took in the order of a few thousands tokens, at most. Then coding agents happened, and suddenly we had a reason to burn 100,000s or even millions of tokens on a single task. Stuff got expensive! (Classic Jevon's paradox right there.) It feels to me like that's trending back down again though. DeepSeek and Kimi are massively less expensive than OpenAI and Anthropic, and almost as useful. OpenAI dropped the price of Luna by 80% the other day, and it's proving very capable of exploring codebases and generating quite competent code. So I don't think advanced AI that can help debug and maintain software will stay out of the reach of most people for very long.
  - lalitmaganti 3mo ago
    > So I don't think advanced AI that can help debug and maintain software will stay out of the reach of most people for very long. But then what stops the upstream tools from doing exactly the same thing and getting the same speedups? I've certainly seen AI become a huge boon in my debugging experience for random user reports for example. FWIW if we are talking about hyper personalized software like the OP, it's going to quickly go beyond "debug and maintain" and towards bigger issues like UX, ergonomics, features etc. And at that point, if the upstream is also being developed you will have differences between your personal visions and upstream Is the answer at that point "accept whatever AI does"? That to me seems to clash with the entire premise of hyper-personalization which is where your vision is what matters not the AI's. Do you really want to get into the game of having opinions on design of every tool you use forever?
pjmlp 3mo ago
Actually, the harsh reality is that for a large majority it has been an easier way to pirate, nothing else, while feeling entitled to scream at the poor maintainers for not implementing whatever features they needed for yesterday.
- wredcoll 3mo ago
  What a boringly reductive take. It's not like hackernews is some amazing bastion of like, optimism and culture and interesting conversation, but surely we can do better than this?
  - pjmlp 3mo ago
    HackerNews, the site when someone posts about their business for developer tooling, there is always a bunch of folks posting links about half implemented alternatives, because who wants to pay for tooling like any other professionals?
    - rvz 3mo ago
      This is also completely self inflicted. This is one of the only professions that does not want to pay for their tools and will do anything to get it for free, including building it themselves. So this is quite unsurprising that open source developers have become this decade's new starving artists asking for donations for their "free software" only for a coding agent to do it for close to $0.
      - mmcdermott 3mo ago
        Perhaps, but it is also the way in which LLM providers eat their seed corn. If everyone publishes less because the only one to consume it will be an LLM gives no credit, then LLMs will lose training material over time.
    - wredcoll 3mo ago
      Is there some magical utopian profession where people want to pay for tooling? Like, I'm sure there are people/groups who spend more on tools, like say, all the plumbers and carpenters buying $600 dewalt drills or whatever, but I'm having trouble with the idea that they want to do that. If programmers, on average, don't pay very much for tooling, the magic of capitalism tells me that's because the tools aren't worth very much.
dregitsky 3mo ago
Yeah I think this is changing, fast. 100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit. On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less good then, and maybe I should have learned some rust first. But it was close. For a less fast-moving codebase it'd have worked, and that was 8mo ago. On the other hand as someone building in devtools for the first time, I struggle with how to think about this. We're building a cloud agent + sandbox platform, https://boxes.dev https://boxes.dev - same problem space as the author's product exe.dev. We could open source our client or the whole stack (we've been thinking about it), but we're adding stuff so quickly that anyone customizing would have a hard time with updates. There's also a lot on the hosted side that users couldn't modify unless they self-host. But I like this vision of a world where software is some fluid thing, and everyone is writing personal mods and building off of others' - basically OSS with forks but where every user (or their agent at least) is engaged with the code.
- awesome_dude 3mo ago
  > On modifying software [..] It was fun and satisfying, but it ended up being a bit of a pain to keep updated. I don't mean this as a criticism in any way - but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream.
  - dolmen 3mo ago
    > but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream. But the cost of contributing changes made by AI is higher: * high chance of the being just rejected because code made by AI, or PR made by AI * so contributing would require carefully preparing a human-made patch (but that becomes much more work than telling an agent to just upgrade my fork) * there is still a high chance for the patch to be rejected or just ignored for months/years, like before Also, there are much more vibe coded projects which are open source, but the author has no interest in maintaining, so issues/PRs will just be ignored.
swiftcoder 3mo ago
> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. Hell, even when I can justify the time commitment for that, I can't justify the ongoing maintenance burden of fixing up my patches to work on the latest version every release or major security fix...
a3mrouter1 3mo ago
[flagged]
Terr_ 3mo ago
> the freedom is more about being able to lean on other people to do that Alternately: The collective capability is what makes important lasting changes, but individual capability is still a required building-block to get there. Much like freedom of speech, come to think of it.
- tlocke 3mo ago
  Very well put.
traceroute66 3mo ago
> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. A lot of modern open source software is often written in dependency heavy languages. So to do a "proper" examination, by definition you need to consider the dependencies as well as the core code itself. We all know how supply-chain attacks are on the rise.
vector_spaces 3mo ago
> One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. A corollary is that more people will have eyes on the source code than the original developer(s), so the project can benefit from a broader skill set and set of orientations and priorities than if it were proprietary. Not just on the development front, but hopefully also in security, usability and accessibility > The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I imagine you are correct that most people historically didn't inspect or modify most tools they use, but most developers I know who have relied on open source software -- even if they didn't contribute directly upstream -- have had the experience of locally patching a small bug or adding a small enhancement to suit a use case, or studying a piece of an open source module as a starting place for their own implementation for some piece of functionality, or doing a cursory scan of a project to make sure it isn't e.g. phoning home, or simply taking a morbidly curious look to see how the sausage is made. Sure, I'm not a representative sample and it would be great to have some actual numbers on this, but I have observed this among engineers at Fortune 500s and YC startups, but also non-tech businesses as well as at local public utilities and health systems. Anyway, I agree that LLMs can provide a lot of value here and reduce the friction but I question the narrative that open source wasn't providing much value previously because most people didn't have time to read code. It provides value even without developers reading code in the first place, and reading code was historically one of the essential parts of the work
- simonw 3mo ago
  > I question the narrative that open source wasn't providing much value previously Don't get me wrong, I've been a strong advocate for the benefits of open source for decades. I think it's delivered enormous value, and most of the top valued companies in the world today wouldn't exist without open source! What's new now is that the end user inspection and modification benefits are feeling a lot more material for a lot more people than before.
  - 3mo ago
a3mrouter1 3mo ago
[flagged]
techpression 3mo ago
Do you verify the reply on how Z works too?
seba_dos1 3mo ago
> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. As someone who way long before the LLM age had small patches accepted in several dozens of projects I've been using, I can assure you that this is just a matter of mentality. All I needed to be able to do that was to stop thinking that "nobody has done it so far, so it must be hard" and just do it. Sometimes I failed, but more often than not it turned out it wasn't hard at all and nobody has done it so far simply because nobody cared enough to attempt it. > Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn't bother. Not my experience at all. Usually the only limiting factor is the size of the project. Compiling a web browser on my 7 yo 13" laptop is a miserable experience, but compiling most of the desktop components or utilities is and has always been a breeze and, in my experience with both Debian and Arch, just a matter of grabbing the distro's source package. I even do it on my phone these days.
- simonw 3mo ago
  I expect it's a whole lot easier on Debian and Arch than it is on macOS.
  - seba_dos1 3mo ago
    Well, a good OS helps in a multitude of ways. It's somewhat harder to do what we're talking about with proprietary tools anyway.
  - LtWorf 3mo ago
    Perhaps it's time to start using a decent OS?
- deleted 3mo ago
  [deleted]
K3UL 3mo ago
This is in my opinion the single most important revolution that will come from llm in the dev space. Not vibecoding or replacing entire teams. Its this and also the ability for non dev to create their own little tools (for productivity, entertainment, family life, whichever). I think they will put back the "personal" in personal computing
msukkarieh 3mo ago
> Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works" We built a free tool to help with this workflow! Just prepend "ask" to any public github repo and get a chat box to ask questions on it :) For example: https://askgithub.com/openai/codex https://askgithub.com/openai/codex
stephen_cagle 3mo ago
Three points: 1) I think that is a really interesting insight. I have never done the above myself, but often I don't "tinker" with things because the amount of energy it would take me to JUST GET IT RUNNING is large, and I might end up borking my own system in doing so. An LLM in a VM can reasonably and safely completely work out on its own how to run some software. I'd never thought about really doing that as a reflexive thing when I am curious. Good thought. 2) I wonder if this is going to be a bifurcation. Where open source software is looked at far more often than in the past because it can actually be "live" investigated (not just have the code reviewed) with little effort? 3) On the opposite of 2, I wonder how many people are going to start "close sourcing" their software, because previously they could be open source, and rely on the inertia of actually getting it running to be enough to support a consultancy service or whatever. If getting it running is trivial, then maybe I need your service less, I just need the code. Might result in different business models?
- simonw 3mo ago
  > I wonder how many people are going to start "close sourcing" their software, because previously they could be open source, and rely on the inertia of actually getting it running to be enough to support a consultancy service or whatever. I do think there's a bit of a risk there, actually. It's not just the consultancy thing - it's the competitive advantage of the software itself. Used to be that you could release open source safe in the knowledge that few people would extract core parts that they need and discard the rest, or fork the project in another direction, because the friction was too much. Better value for people to contribute to your project directly, which provides a great deal of value in exchange for releasing it in the first place. Now... if you invent some brilliant new database indexing scheme and release it as open source, I can point my coding agent at your code and have it imitate your new insight in a few minutes. For some projects that's fine, but for projects that intended to commercialize that's not ideal at all. So yeah, I do worry about the way coding agents distort the previous incentives for open source projects.
pif 3mo ago
> Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". In principle, you should not need the source code: the AI should be able to answer by examining the binaries.
- simonw 3mo ago
  I mostly work with Python, and often coding agents answer questions about dependencies for me just by digging around in the site-packages folder in whatever virtual environment they have access to. The "clone X and tell me" trick is something I mostly use on my phone - I can answer questions about pretty much any piece of software on GitHub with a regular Claude session, no coding agent needed.
spullara 3mo ago
I now have a fork of Ghostty that is kept up to date with AI and automatically triages and then PRs issues. All because I wanted to have a built in settings page instead of a config file I needed to edit. The future of software is custom per user.
HiPhish 3mo ago
> The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. So it's like everything else in life. I am not a plumber, but I very much do want to be free to do my own plumbing if I want to. Not because I do want to, but because it means that I do get to choose whom I let do my plumbing.
shevy-java 3mo ago
LLMs enable some new things but they ultimate do not solve the underlying problem when a human lacks knowledge. I write a lot of software on my own, but I have little to no real experience in the inner workings of the linux kernel. I could invest more time, but time is a finite resource, so I invest it into various other things that seem more important to me right now. LLMs simplified some things that used to be hard or impossible before, though. That is indeed true. They also amplified AI slop spam, which is annoying. Some humans use AI to reply to other humans; this always upsets me, because it means the other human is not only very lazy, but also does not understand why AI slop spamming other humans is like a vile personal attack. You here state (if one does that) that you are not interested in listening or communicating with that other person.
J-Kuhn 3mo ago
For me, Nix(OS) solved most of the problems: * Getting a dev env with `nix-shell -E '(import <nixpkgs> {}).somePackage'` where I can edit the source and compile it with the various `runPhase` commands[1]. Yes, a bit cumbersome, but it works and it is the same for all packages. * Integrating the resulting patch into the package manager using overrides[2]. Sure, applying the patch may break at some point, but I am more comfortable reviewing that by hand than rely on an agent that does it for me. [1]: https://wiki.nixos.org/wiki/Nixpkgs/Create_and_debug_packages#Using_nix-shell_for_package_development https://wiki.nixos.org/wiki/Nixpkgs/Create_and_debug_package... [2]: https://wiki.nixos.org/wiki/Overlays#Adding_patches https://wiki.nixos.org/wiki/Overlays#Adding_patches
jv22222 3mo ago
Conversely, software that is not open source, but that has a really good API and SDK (like obsidian) is also very easy for your agent to do anything it wants with. This gives the end user all the customization they need and gives a company like obsidian the capability to have a little bit of secret source in today’s day and age.
pull_my_finger 3mo ago
> The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that This is the sad truth. Some of these projects are just WAY too big for anyone to meaningfully digest what's happening. Chromium or Android? That's cool that their open, but they could just leave huge swathes of unobscured, liberally commented code - detailing how they're ravaging the host machine or sending deeply private telemetry home to Google and 99% of users would be none the wiser. All while being "open". You could liken it to those 100 page ToS agreements most people just click "accept" to and never read. There could literally be anything in there, and even if you had the motivation to try and peruse it, the odds are definitely NOT in your favor.
socalgal2 3mo ago
The path I see is I just ask for the functionality and AI builds it from scratch. No need for other people's software/libraries. I get it's not 100% there today but I do have that experience today with quite a few things. I had one project, removed 14 dependencies just by asking the AI, "what would it take to remove dependency X". If it gives me basically "not too much work" then I tell it to remove it. Another I say "no libraries" and a few minutes later I had a mini game running in a mini native game engine, no libraries. Like many I've also asked for small programs for various things. Last week I needed an image that a 4 months ago I would have made in photoshop. I just asked the AI "make me an image generator that given X inputs generates Y style" and 5 minutes later I had the generator in a webpage. I made a couple of minor tweaks that were faster by hand than prompting and had the image I wanted.
- virtue3 3mo ago
  have you considered the token inefficiency of what you're doing and that you're burning electricity to re-invent the wheel? I'm being a bit of a PITA here but if everyone does what you suggest the real world implications could be staggering. Especially if we aren't committing code back into public places for LLMs to ingest and use. I think from an efficiency standpoint it's almost always better to use something already battle tested and used in the open than rolling your own; regardless of leveraging LLMs or not.
  - smnplk 3mo ago
    That goes against "business model" of AI companies
deleted 3mo ago
[deleted]
kuboble 3mo ago
I have vibe-modified quite some software I use daily. - Podcast app (removed nags, ads, added some stats and filters I wanted). - notepad. After windows added copilot to notepad I deleted it. Then i took some simple notepad app from github and added the few features I care about. - android voice keyboard And the biggest win was taking Wezterm and having claude build Lua scripts for the features I'm missing
glitchc 3mo ago
> The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. That's not quite right. It's always developers who make the changes, just those who care strongly enough to dedicate their time. Open source (or in a limited sense an extension framework), allows these developers to share their updates with a wider audience. If the tool evokes strong emotions, the pool can be quite large. While it may seem like I'm nitpicking, my point is this: There is no external benevolent entity as your statement implies. Rather it's just a fellow developer who cares enough to evolve the tool long beyond it's lifecycle.
1-more 3mo ago
The language I use at work has one formatter with zero configurability. This is a good thing. It has had a long open issue on github: allow users to put an import statement anywhere in the source code (not in the middle of a function, but between functions) and have it move up to the import section at the top of the file. This is syntactically invalid if left unformatted; you can't have imports after the first definition. I'd talked to the program's creator and he said it was going to be a high effort change because the formatter is a fork of the compiler, and the compiler first considers imports before switching to considering function declarations. I gave problem to Claude and went and did yard work. It handled it in one shot, including writing tests that I could understand and be satisfied that it works. The PR implementing this remains open and that's fine; it's a lot to ask a maintainers to take responsibility for code I don't fully understand. I don't want to lean on them! But now I use my modified version of the formatter, and I think some people at work do too. It's an amazing era for "give me this feature why not?"
pvtmert 3mo ago
I have sent several bugfixes to software I used as a "daily driver". I did the same when I was working at Amazon. While managers didn't usually understand the benefits of saving a minute or two from the test suite runner, at the scale I think it had tremendous impact. Especially when it comes to the cycle time during development. (Also relevant during the agentic workflows) Since the code became a commodity, it is beneficial for companies to "open source" it. As the cost of doing so is negligible compared to the "responsibility transfer" by acquiring a license.

by simonw 3mo ago

imrehg 3mo ago

I have sent countless small bug fixes even before, to tools that I use that I could dig into when something was off... No big heavy lifting, but plenty of "tinker on your tools" stuff. And I don't think what I did was that special, so maybe the experiences are different? The current LLM-driven stuff seems to break down the expectations, and now there are a lot of places which just ignore anything I send in (the same tinkers as before), generally, for a while. Though there are some tools that picked up the pace and actually react faster (so YMMV here too). But there are few things more frustrating as being half-way. Case to point is LM Studio. It's closed source, has bugs (duh!), and there's at least a GitHub issue tracker to report the bugs -- but then by and large nothing happens to those reported things. It's almost worse than not having an issue tracker (then I could justify never to really touch LM Studio again, this way I keep hoping against hope that reports will turn into fixes and thus I keep using and keep reporting...)

ravenstine 3mo ago
That's my biggest gripe with open source software. It's not really the open source part that's bad, but when projects turn into major projects with a substantial user base, I think the owners have an obligation not to delude their users into thinking they have more say than they actually do. Plenty of big projects leave their issue trackers public and have docs that encourage community contribution, yet effectively ignore user submissions unless perhaps someone with a name raises an issue. I completely agree that allowing users to waste their time believing their issue or pull request can make a difference is actually worse than not allowing public submissions in the first place. I'm not sure why I seem to be in the minority on this. Maybe I've just had bad luck in that most of the issues and PRs I've submitted to open source have been ignored. Hell, I'd prefer a "thanks but no thanks" or even "fuck you" over radio silence. The typical response to this frustration of mine is "just fork the code, bro", which is absurd because forking should be a last resort for software that thrives from having a community.
- zephen 3mo ago
  > which is absurd because forking should be a last resort for software that thrives from having a community. This is true, of course, but having a community is completely orthogonal to whether software is open or closed source.
  - bonoboTP 3mo ago
    The two are correlated which does encourage that mistaken view. Github culture generally blends these two, having an open issue tracker, pull requests etc. as well as the code right there, often with a free license. But you can very much allow bug reports and feature requests in public while developing proprietary software and you can also very much work on a project alone or with a small group without being open to random patches, contributions or requests and be open source / FLOSS. The key definitional question is the license, not any of the cultural stuff.
    - zephen 3mo ago
      Plenty of proprietary packages had robust communities well before anything like github existed. In fact, github is arguably a poor substitute for a community. Look at how communities such as the ones around the linux kernel or cPython communicate. It sure as shit isn't through issues or pull requests. Or rather, perhaps, the limited technical communication that an issue tracker is good for is not a valid large community consensus building mechanism. > The key definitional question is the license, not any of the cultural stuff. For direct modification, certainly. For customization, maybe. For ignored issues like the parent to my original comment was bemoaning? Maybe LLMs are good enough that we are almost ready to say "Make me a custom version of Photoshop" and then it doesn't matter.
      - bonoboTP 3mo ago
        Yes. I've actually added some features to Blender like this, related to some highly specific use case. Just clone the source point an agent at it, say what you'd want (you have to be able to formulate this in a halfway coherent way), and it succeeded. Now, I haven't thought much about what it would mean to maintain this, but I think if I need this ever again, I can point an AI to it again and say "do the equivalent change now to the latest version". For occasional use this is fine.
fleventynine 3mo ago
The solution for this is to pay open source maintainers for their attention. If I want them to review and merge my bugfix I should attach $1000 to the PR.
- jbritton 3mo ago
  Maybe a donate link attached too. The dollars tied to a PR could help set priority of fixes.
- mbreese 3mo ago
  This is actually not a bad idea for funding open source software. It used to be that you’d have an author who coded a project and then could fix the occasional bug or two quickly. Now, we have larger projects where it is rare for one people to have a complete understanding, and the main value is a person to reviewing patches and bugs to make sure the changes align with the larger goals/path for the project. There is little incentive for a maintainer to do this, aside from wanting to limit forks. Paying for that review might be the way to keep this whole model sustainable.
  - katbyte 3mo ago
    Opportunity for gh “Here is my pr I attach x$ payable when it is merged” and allow me to add $ to other prs. I have been waiting year + for multiple feature in some projects that have open prs and for one I would easily bid 100-200$
    - nightshift1 3mo ago
      [dead]
- theshrike79 3mo ago
  Maybe instead of the emoji buttons Github should let people attach money to the issue. If that gets fixed, the project gets the money.

2190asfg 3mo ago

[flagged]

not-kinsale-joe 3mo ago
What do you mean by this?
- simonw 3mo ago
  I think they're suggesting that because I blog about AI I get free tokens and don't have a conception of how much they cost? I currently spend $100/month on OpenAI and $200/month on Anthropic. (I often get free tokens as part of preview access to models, but I'm not allowed to share any code written by those models online for the duration of the preview. Most of my work is open source, so I can't actually do much with those free tokens!)
nh23423fefe 3mo ago
I wasted time trying to understand sarcasm instead of being given a clear point to read. Bad human.
- BigTTYGothGF 3mo ago
  > I wasted time trying to understand sarcasm Skill issue.
  - nh23423fefe 3mo ago
    another very original human repeating the meme
    - BigTTYGothGF 3mo ago
      Cliches are cliches for a reason.

zdragnar 3mo ago

> One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. The canonical example was RMS needing to fix a printer driver bug back before software updates were really a thing. That meant that there was a greater motivation for users to maintain their changes. Today, with software being an evergreen stack of turtles from the BIOS all the way up the OS to the remote APIs the qpp interacts with, expecting a user to indefinitely maintain their private fork of any software is a really big stretch. Unless it is a local-only, unmaintained project that doesn't get deployed through a software repository or an app store, I think that original vision of open source software is very much the exception and not the rule.

bonoboTP 3mo ago
> I think that original vision of open source software is very much the exception and not the rule. RMS has never supported open source. And never emphasized software repositories or deployment or app stores or whatever. He is a proponent of free software based on ethical motivations, to allow users the freedom to control how their computing is done. It perfectly fits the local-only personal project.

throwatdem12311 3mo ago

Then you’re maintaining a stack of patches on top of the upstream until the end of time because the maintainers of the projects don’t want AI slop contributions, but now you depend on these changes for your own use so now you’ve created more work for yourself keeping your own fork up to date. I used AI to help me make a change to a library I use that ended up being a single line of code. The pull request was refused for having a Claude attribution even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support (so I considered this incompatibility a bug). Ended up figuring out a workaround in our application code instead just so we could use the upstream. Still not really worth the effort for most projects even with AI. In the era of AI slop being bombarded at you from all sides 24/7 I don’t blame them. Gatekeeping is the only way to maintain a semblance of quality (and sanity). Once you let slop in it accumulates at an insane rate. You need zero tolerance or you will be overwhelmed.

throwaway27448 3mo ago
> even though it was a single code change that was syntax only with no change in behavior just to make it compatible with an older version of the language they claimed to support It seems like a great stretch to call this "slop".
- throwatdem12311 3mo ago
  I agree but it’s their project and their rules. To them I’m just another guy tossing slop over the fence they don’t have time to review in the hig stack of all the other slop.
simonw 3mo ago
> Then you’re maintaining a stack of patches on top of the upstream until the end of time The linked article has an ambitious solution for that, in the form of this prompt to a coding agent harness: Set up a nightly cron job that executes the prompt: fetch upstream changes to the <software> and rebase all local changes on top of upstream. Check that the software works as intended and replace the current version.

hgomersall 3mo ago

Ha, yes! A few times I've had a back and forth with Claude about why software X isn't working as I expected it to, with Claude coming up with more and more ludicrous explanations, and in the end I say, "just go and read the code", and it remembers it can do that and goes and does it and then finds the bug, or the weird UX design or whatever. It's really helpful.

mrheosuper 3mo ago
i have the opposite problem, sometime i tell it to read the doc/header to understand how to use API, but then it proceeds to dive into the SDK to read the source, which is not a bad thing but that takes both time and a lot of token

brunoborges 3mo ago

> I think LLMs have changed that equation in a way that makes the original dream much more feasible. > Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". Still highly dependant on one's access to SOTA AI models (availability and funding). Most people praising LLMs publicly for this sort of use case, are the ones with unlimited access to tokens / AI credits, or simply with a lot of money to burn. But reality is that between using one's limited employer-sponsored quota of tokens to do their 9-5 business logic coding maintenance job, versus exploring 3rd-party software as end-users, I am sure of which one their managers will prefer. I believe it will eventually happen, whether with SOTA local models on highly capable local hardware, or super cheap inference APIs... or both.

simonw 3mo ago
I've gone back and forth on this. A couple of years ago LLM prompts really were incredibly cheap and falling in price. OpenAI's own models had fallen in cost by a factor of about 1000x since GPT-3. They were also cheap because many of the things you might want to do with an LLM took in the order of a few thousands tokens, at most. Then coding agents happened, and suddenly we had a reason to burn 100,000s or even millions of tokens on a single task. Stuff got expensive! (Classic Jevon's paradox right there.) It feels to me like that's trending back down again though. DeepSeek and Kimi are massively less expensive than OpenAI and Anthropic, and almost as useful. OpenAI dropped the price of Luna by 80% the other day, and it's proving very capable of exploring codebases and generating quite competent code. So I don't think advanced AI that can help debug and maintain software will stay out of the reach of most people for very long.
- lalitmaganti 3mo ago
  > So I don't think advanced AI that can help debug and maintain software will stay out of the reach of most people for very long. But then what stops the upstream tools from doing exactly the same thing and getting the same speedups? I've certainly seen AI become a huge boon in my debugging experience for random user reports for example. FWIW if we are talking about hyper personalized software like the OP, it's going to quickly go beyond "debug and maintain" and towards bigger issues like UX, ergonomics, features etc. And at that point, if the upstream is also being developed you will have differences between your personal visions and upstream Is the answer at that point "accept whatever AI does"? That to me seems to clash with the entire premise of hyper-personalization which is where your vision is what matters not the AI's. Do you really want to get into the game of having opinions on design of every tool you use forever?

pjmlp 3mo ago

Actually, the harsh reality is that for a large majority it has been an easier way to pirate, nothing else, while feeling entitled to scream at the poor maintainers for not implementing whatever features they needed for yesterday.

wredcoll 3mo ago
What a boringly reductive take. It's not like hackernews is some amazing bastion of like, optimism and culture and interesting conversation, but surely we can do better than this?
- pjmlp 3mo ago
  HackerNews, the site when someone posts about their business for developer tooling, there is always a bunch of folks posting links about half implemented alternatives, because who wants to pay for tooling like any other professionals?
  - rvz 3mo ago
    This is also completely self inflicted. This is one of the only professions that does not want to pay for their tools and will do anything to get it for free, including building it themselves. So this is quite unsurprising that open source developers have become this decade's new starving artists asking for donations for their "free software" only for a coding agent to do it for close to $0.
    - mmcdermott 3mo ago
      Perhaps, but it is also the way in which LLM providers eat their seed corn. If everyone publishes less because the only one to consume it will be an LLM gives no credit, then LLMs will lose training material over time.
  - wredcoll 3mo ago
    Is there some magical utopian profession where people want to pay for tooling? Like, I'm sure there are people/groups who spend more on tools, like say, all the plumbers and carpenters buying $600 dewalt drills or whatever, but I'm having trouble with the idea that they want to do that. If programmers, on average, don't pay very much for tooling, the magic of capitalism tells me that's because the tools aren't worth very much.

dregitsky 3mo ago

Yeah I think this is changing, fast. 100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit. On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less good then, and maybe I should have learned some rust first. But it was close. For a less fast-moving codebase it'd have worked, and that was 8mo ago. On the other hand as someone building in devtools for the first time, I struggle with how to think about this. We're building a cloud agent + sandbox platform, https://boxes.dev https://boxes.dev - same problem space as the author's product exe.dev. We could open source our client or the whole stack (we've been thinking about it), but we're adding stuff so quickly that anyone customizing would have a hard time with updates. There's also a lot on the hosted side that users couldn't modify unless they self-host. But I like this vision of a world where software is some fluid thing, and everyone is writing personal mods and building off of others' - basically OSS with forks but where every user (or their agent at least) is engaged with the code.

awesome_dude 3mo ago
> On modifying software [..] It was fun and satisfying, but it ended up being a bit of a pain to keep updated. I don't mean this as a criticism in any way - but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream.
- dolmen 3mo ago
  > but the need to keep your changes current is a strong motivation for getting those changes incorporated upstream. But the cost of contributing changes made by AI is higher: * high chance of the being just rejected because code made by AI, or PR made by AI * so contributing would require carefully preparing a human-made patch (but that becomes much more work than telling an agent to just upgrade my fork) * there is still a high chance for the patch to be rejected or just ignored for months/years, like before Also, there are much more vibe coded projects which are open source, but the author has no interest in maintaining, so issues/PRs will just be ignored.

swiftcoder 3mo ago

> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. Hell, even when I can justify the time commitment for that, I can't justify the ongoing maintenance burden of fixing up my patches to work on the latest version every release or major security fix...

a3mrouter1 3mo ago

[flagged]

Terr_ 3mo ago

> the freedom is more about being able to lean on other people to do that Alternately: The collective capability is what makes important lasting changes, but individual capability is still a required building-block to get there. Much like freedom of speech, come to think of it.

tlocke 3mo ago
Very well put.

traceroute66 3mo ago

> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. A lot of modern open source software is often written in dependency heavy languages. So to do a "proper" examination, by definition you need to consider the dependencies as well as the core code itself. We all know how supply-chain attacks are on the rise.

vector_spaces 3mo ago

> One of the arguments for open source software for end-users has always been the freedom to examine and modify how that software works. A corollary is that more people will have eyes on the source code than the original developer(s), so the project can benefit from a broader skill set and set of orientations and priorities than if it were proprietary. Not just on the development front, but hopefully also in security, usability and accessibility > The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. I imagine you are correct that most people historically didn't inspect or modify most tools they use, but most developers I know who have relied on open source software -- even if they didn't contribute directly upstream -- have had the experience of locally patching a small bug or adding a small enhancement to suit a use case, or studying a piece of an open source module as a starting place for their own implementation for some piece of functionality, or doing a cursory scan of a project to make sure it isn't e.g. phoning home, or simply taking a morbidly curious look to see how the sausage is made. Sure, I'm not a representative sample and it would be great to have some actual numbers on this, but I have observed this among engineers at Fortune 500s and YC startups, but also non-tech businesses as well as at local public utilities and health systems. Anyway, I agree that LLMs can provide a lot of value here and reduce the friction but I question the narrative that open source wasn't providing much value previously because most people didn't have time to read code. It provides value even without developers reading code in the first place, and reading code was historically one of the essential parts of the work

simonw 3mo ago
> I question the narrative that open source wasn't providing much value previously Don't get me wrong, I've been a strong advocate for the benefits of open source for decades. I think it's delivered enormous value, and most of the top valued companies in the world today wouldn't exist without open source! What's new now is that the end user inspection and modification benefits are feeling a lot more material for a lot more people than before.
- 3mo ago

a3mrouter1 3mo ago

[flagged]

techpression 3mo ago

Do you verify the reply on how Z works too?

seba_dos1 3mo ago

> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. As someone who way long before the LLM age had small patches accepted in several dozens of projects I've been using, I can assure you that this is just a matter of mentality. All I needed to be able to do that was to stop thinking that "nobody has done it so far, so it must be hard" and just do it. Sometimes I failed, but more often than not it turned out it wasn't hard at all and nobody has done it so far simply because nobody cared enough to attempt it. > Getting software to compile in order to start hacking on it used to be enough friction that I often wouldn't bother. Not my experience at all. Usually the only limiting factor is the size of the project. Compiling a web browser on my 7 yo 13" laptop is a miserable experience, but compiling most of the desktop components or utilities is and has always been a breeze and, in my experience with both Debian and Arch, just a matter of grabbing the distro's source package. I even do it on my phone these days.

simonw 3mo ago
I expect it's a whole lot easier on Debian and Arch than it is on macOS.
- seba_dos1 3mo ago
  Well, a good OS helps in a multitude of ways. It's somewhat harder to do what we're talking about with proprietary tools anyway.
- LtWorf 3mo ago
  Perhaps it's time to start using a decent OS?
deleted 3mo ago
[deleted]

K3UL 3mo ago

This is in my opinion the single most important revolution that will come from llm in the dev space. Not vibecoding or replacing entire teams. Its this and also the ability for non dev to create their own little tools (for productivity, entertainment, family life, whichever). I think they will put back the "personal" in personal computing

msukkarieh 3mo ago

> Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works" We built a free tool to help with this workflow! Just prepend "ask" to any public github repo and get a chat box to ask questions on it :) For example: https://askgithub.com/openai/codex https://askgithub.com/openai/codex

stephen_cagle 3mo ago

Three points: 1) I think that is a really interesting insight. I have never done the above myself, but often I don't "tinker" with things because the amount of energy it would take me to JUST GET IT RUNNING is large, and I might end up borking my own system in doing so. An LLM in a VM can reasonably and safely completely work out on its own how to run some software. I'd never thought about really doing that as a reflexive thing when I am curious. Good thought. 2) I wonder if this is going to be a bifurcation. Where open source software is looked at far more often than in the past because it can actually be "live" investigated (not just have the code reviewed) with little effort? 3) On the opposite of 2, I wonder how many people are going to start "close sourcing" their software, because previously they could be open source, and rely on the inertia of actually getting it running to be enough to support a consultancy service or whatever. If getting it running is trivial, then maybe I need your service less, I just need the code. Might result in different business models?

simonw 3mo ago
> I wonder how many people are going to start "close sourcing" their software, because previously they could be open source, and rely on the inertia of actually getting it running to be enough to support a consultancy service or whatever. I do think there's a bit of a risk there, actually. It's not just the consultancy thing - it's the competitive advantage of the software itself. Used to be that you could release open source safe in the knowledge that few people would extract core parts that they need and discard the rest, or fork the project in another direction, because the friction was too much. Better value for people to contribute to your project directly, which provides a great deal of value in exchange for releasing it in the first place. Now... if you invent some brilliant new database indexing scheme and release it as open source, I can point my coding agent at your code and have it imitate your new insight in a few minutes. For some projects that's fine, but for projects that intended to commercialize that's not ideal at all. So yeah, I do worry about the way coding agents distort the previous incentives for open source projects.

pif 3mo ago

> Several times a day I'll prompt regular Claude chat to "Clone x/y from GitHub and tell me how Z works". In principle, you should not need the source code: the AI should be able to answer by examining the binaries.

simonw 3mo ago
I mostly work with Python, and often coding agents answer questions about dependencies for me just by digging around in the site-packages folder in whatever virtual environment they have access to. The "clone X and tell me" trick is something I mostly use on my phone - I can answer questions about pretty much any piece of software on GitHub with a regular Claude session, no coding agent needed.

spullara 3mo ago

I now have a fork of Ghostty that is kept up to date with AI and automatically triages and then PRs issues. All because I wanted to have a built in settings page instead of a config file I needed to edit. The future of software is custom per user.

HiPhish 3mo ago

shevy-java 3mo ago

LLMs enable some new things but they ultimate do not solve the underlying problem when a human lacks knowledge. I write a lot of software on my own, but I have little to no real experience in the inner workings of the linux kernel. I could invest more time, but time is a finite resource, so I invest it into various other things that seem more important to me right now. LLMs simplified some things that used to be hard or impossible before, though. That is indeed true. They also amplified AI slop spam, which is annoying. Some humans use AI to reply to other humans; this always upsets me, because it means the other human is not only very lazy, but also does not understand why AI slop spamming other humans is like a vile personal attack. You here state (if one does that) that you are not interested in listening or communicating with that other person.

J-Kuhn 3mo ago

For me, Nix(OS) solved most of the problems: * Getting a dev env with `nix-shell -E '(import <nixpkgs> {}).somePackage'` where I can edit the source and compile it with the various `runPhase` commands[1]. Yes, a bit cumbersome, but it works and it is the same for all packages. * Integrating the resulting patch into the package manager using overrides[2]. Sure, applying the patch may break at some point, but I am more comfortable reviewing that by hand than rely on an agent that does it for me. [1]: https://wiki.nixos.org/wiki/Nixpkgs/Create_and_debug_packages#Using_nix-shell_for_package_development https://wiki.nixos.org/wiki/Nixpkgs/Create_and_debug_package... [2]: https://wiki.nixos.org/wiki/Overlays#Adding_patches https://wiki.nixos.org/wiki/Overlays#Adding_patches

jv22222 3mo ago

Conversely, software that is not open source, but that has a really good API and SDK (like obsidian) is also very easy for your agent to do anything it wants with. This gives the end user all the customization they need and gives a company like obsidian the capability to have a little bit of secret source in today’s day and age.

pull_my_finger 3mo ago

> The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that This is the sad truth. Some of these projects are just WAY too big for anyone to meaningfully digest what's happening. Chromium or Android? That's cool that their open, but they could just leave huge swathes of unobscured, liberally commented code - detailing how they're ravaging the host machine or sending deeply private telemetry home to Google and 99% of users would be none the wiser. All while being "open". You could liken it to those 100 page ToS agreements most people just click "accept" to and never read. There could literally be anything in there, and even if you had the motivation to try and peruse it, the odds are definitely NOT in your favor.

socalgal2 3mo ago

The path I see is I just ask for the functionality and AI builds it from scratch. No need for other people's software/libraries. I get it's not 100% there today but I do have that experience today with quite a few things. I had one project, removed 14 dependencies just by asking the AI, "what would it take to remove dependency X". If it gives me basically "not too much work" then I tell it to remove it. Another I say "no libraries" and a few minutes later I had a mini game running in a mini native game engine, no libraries. Like many I've also asked for small programs for various things. Last week I needed an image that a 4 months ago I would have made in photoshop. I just asked the AI "make me an image generator that given X inputs generates Y style" and 5 minutes later I had the generator in a webpage. I made a couple of minor tweaks that were faster by hand than prompting and had the image I wanted.

virtue3 3mo ago
have you considered the token inefficiency of what you're doing and that you're burning electricity to re-invent the wheel? I'm being a bit of a PITA here but if everyone does what you suggest the real world implications could be staggering. Especially if we aren't committing code back into public places for LLMs to ingest and use. I think from an efficiency standpoint it's almost always better to use something already battle tested and used in the open than rolling your own; regardless of leveraging LLMs or not.
- smnplk 3mo ago
  That goes against "business model" of AI companies

deleted 3mo ago

[deleted]

kuboble 3mo ago

I have vibe-modified quite some software I use daily. - Podcast app (removed nags, ads, added some stats and filters I wanted). - notepad. After windows added copilot to notepad I deleted it. Then i took some simple notepad app from github and added the few features I care about. - android voice keyboard And the biggest win was taking Wezterm and having claude build Lua scripts for the features I'm missing

glitchc 3mo ago

> The reality for most people - even expert programmers - has been that the freedom is more about being able to lean on other people to do that. Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. That's not quite right. It's always developers who make the changes, just those who care strongly enough to dedicate their time. Open source (or in a limited sense an extension framework), allows these developers to share their updates with a wider audience. If the tool evokes strong emotions, the pool can be quite large. While it may seem like I'm nitpicking, my point is this: There is no external benevolent entity as your statement implies. Rather it's just a fellow developer who cares enough to evolve the tool long beyond it's lifecycle.

1-more 3mo ago

The language I use at work has one formatter with zero configurability. This is a good thing. It has had a long open issue on github: allow users to put an import statement anywhere in the source code (not in the middle of a function, but between functions) and have it move up to the import section at the top of the file. This is syntactically invalid if left unformatted; you can't have imports after the first definition. I'd talked to the program's creator and he said it was going to be a high effort change because the formatter is a fork of the compiler, and the compiler first considers imports before switching to considering function declarations. I gave problem to Claude and went and did yard work. It handled it in one shot, including writing tests that I could understand and be satisfied that it works. The PR implementing this remains open and that's fine; it's a lot to ask a maintainers to take responsibility for code I don't fully understand. I don't want to lean on them! But now I use my modified version of the formatter, and I think some people at work do too. It's an amazing era for "give me this feature why not?"

pvtmert 3mo ago

I have sent several bugfixes to software I used as a "daily driver". I did the same when I was working at Amazon. While managers didn't usually understand the benefits of saving a minute or two from the test suite runner, at the scale I think it had tremendous impact. Especially when it comes to the cycle time during development. (Also relevant during the agentic workflows) Since the code became a commodity, it is beneficial for companies to "open source" it. As the cost of doing so is negligible compared to the "responsibility transfer" by acquiring a license.