I disagree. As if a tool is customized via agents and something goes wrong, it should be the users issue to fix it. Say I want to customize a bank app (or sca tool) to use a nickname instead of my name, if it breaks then who fixes it?
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.
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.
> 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.
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.
* 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.
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.
> 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.
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.
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
> 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.
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?"
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.
I agree that devtools should be open source, but... I very much disagree with the premise that no tools should have config files, options, or plugin systems, and instead when you want to change something like your text editor's font size, you should have an LLM download the code, change the hard-coded value, and rebuild it.
That's just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding work, do we want to burn electricity having the LLM build an options dialog or config file parser once, or do we want to burn electricity millions of times as users want to change any little thing about the software they use?
I really hope what you should expect is my answer to that question isn't controversial.
Having an LLM do bespoke customizations that are unlikely to be interesting to other people? Great, sure. But adding a generally-useful feature to a piece of software, but not caring to try to upstream it? Lame. Lame, lame, lame.
I like the idea of devtools being open source. I also like them to work, and that's what I value more that philosophical purity.
Take his side project, Meat. I've been chewing on this problem for a while. It's a real problem right now: it sucks to read all this LLM-generated code. It's worthwhile to have an LLM summarize it for you.
The problem with that is this particular problem resists vibe coding. I've talked to a bunch of people who have tried to solve it on the side, and it's all sort of ... ok, but still unsolved.
- As mentioned, it takes a while to run. You can modify your other tools, as described, to smuggle the latency.
- LLMs don't know what you care about, so you have to maintain a list of things that you do care about, which is ever evolving. If you don't give it that, it produces slop.
- If you miss something, it hurts. Another layer of swiss-cheese AI doesn't feel right. If you trust the AI, just ask Claude to summarize its work!
- The summaries feel shareable, but the author of the PR is actually the most tolerate of slop about a PR. Your reviewers definitely don't want to read the output of a vibe-coded tool talking about 60% of your PR. They could ask their own Claude!
So, we're building a version (https://tern.sh), and it's not open source, because we want it to be shareable and hosted and support teams -- all that stuff that makes it work. At the end of the day, I'm not here to maintain my tools. I'm here to use my tools to do the job.
So, I'm a subscriber/user of exe.dev but even so I was a bit disappointed when the meat.dev tool linked in the article had no screenshots/meaningful docs. So I installed it and was bummed to see it only supported openAI and exe.dev llm integration by default. "You can just fork" - yeah I know, so take it with a grain of salt.
That aside aside, I agree. Since reading this article yesterday I've probably been overthinking an MIT from AGPL license switch for my own project Ouijit (shill time: https://ouijit.com). Its feels a little counterintuitive since AGPL encourages more open source downstream, but at the same time if I have solved some problem other agent harness devs are curious about, I just want them to take the solution without worrying about paying it back/forward.
This is one of the only fields where the customer (developers) almost never pays for their own tools and instead builds their own or even to compete against another developer. Then, they later realize why human developers in open source burnout so easily.
Not even Richard Stallman or Linus Torvalds make money on open source or free software despite preaching it. They actually make money from speaking fees.
"Open source" is now weaponized to price down entire companies to the floor and instead of humans maintaining the software, it is now coding agents doing the work.
Neither the free and open source software movement accounted for this disruption and they have become the new starving artists of the software world.
Why not use both open source and closed source software? Pick your battles. It's okay to buy a Mac or pay a hosting provider. Customize the tools that actually matter to you.
> 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.
This sounds like hell. You have unreliable actor redoing the software every night, and every day there is a chance you wake up and find your workflow broken.
And no, "Check that the software works as intended" is not going to cut it, as AI are very, very good at obeying the letter but not the spirit of the ask. Yes, your diffs appear but they lack filenames. You've added this requirements to the prompt? Ok, filenames are back but they are font size 4, unreadably small. You want them well-seen? next week they become size 54, taking entire screen..
This is not a problem with regular AI development - you review the changes and test them a bit. But doing it day-to-day with no overview is just asking for trouble.
If your coding agent workflow isn't sandboxed, backed up, and rollback-able, it's fundamentally broken. And yes I realize most of us aren't working this way today. But I think we'll have the tooling pretty soon. There's currently a cambrian explosion of solutions in this space.
I don't know; I've been rebasing huge branches in really mean divergent states with Claude Code, and it handled it flawlessly pretty much every single time. So I don't think the actor is as unreliable as you think.
Like everything else, modifying code of open-source tools has its cons and pros. The biggest advantage is of course an ability to customize the tool exactly to your needs. The problem is that it makes patching and upgrading impossible. This is the reason plugins exist - they do not break ability to patch the host product. So, if customization cannot be avoided even at the cost of losing ability to patch/upgrade - that would definitely work. Otherwise, plugins is probably the best approach.
I think there is an argument to be made for how this benefits projects too, like if you want distribution then be as unencumbered as possible.
I've been making a couple little utils like a Clock for AI with an open public endpoint [https://github.com/firasd/mcpclock], a text file sampler [https://github.com/firasd/vblinds] and I was noticing the MIT license seems too encumbered with the requirement to keep crediting authors downstream so I used the 'Unlicense' public domain license
(CC-0 seems to be side-eyed by open source orgs cause it preserves patent rights)
Open-sourced doesnt have to be free either. There's always the very good GNU Affero General Public License 3 (AGPL-3) and others. I think most developers want open-source for transparency. We want to know what we are downloading.
It's a bit ironic to talk about key parts of the toolchain being open source while making black-box, closed source LLM's, controlled by external companies an integral part of all of it.
I'm not against open source. However, if I were to guess, I think less than 1% of people actually review, let alone modify the open source projects they use. I don't really buy this argument.
I think we're seeing a new modality of openness now with open weights, or being able to modify agents with md files, skills, and so forth.
I deeply disagree with the light vs dark framing. I think the real tension between "hacker languages" and "blub languages" is the expectation to modify the language by it's user.
And this is true for dev tools as well. Hackers prefer modifiable environments (such as Emacs), while corporations prefer standard environments (IDEs) to which programmers will adapt.
(As the saying goes: "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Might be why Paul Graham preferred founders with non-blub languages after all, nothing to do with Lisp as such.)
But to be able to adapt the environment, one must understand it. Therefore the pull to make it simpler, a set of universal tools, rather than a complicated machine with many features and ease of use through following prescription.
As a maintainer of a devtool which has strived to make itself easily forkable and modifiable, I can see the allure of this line of thinking but I think it's sadly too idealistic.
Engineers using devtools are not so different to an average user in that they just want things to work. Maintaining a devtool is real work; e.g. suppose upstream adds some feature you want but it clashes with something you did downstream. Not in the merge conflict sense but in the UX sense. Do you want to resolve that on every release? Is it just "AI will fix this"? Maybe one day, but as of today agents can do something along the right lines but don't capture my UX sense very well; and if the whole point is hyper-personalization, I want it exactly how I want it.
"Does it seem to work?" is a fine right until it fails when you're doing something important. Do you then stop and go prompt an agent to fix your tooling, and hope it does a good job this time? What if it doesn't do a good job?
Moreover, for devtools which are fundamentally social (i.e. lots of different people looking at the same thing), there's real value in that thing looking the same for everyone. Having a baseline for teaching, auditing, verifying "we are all talking about the same thing" is incredibly valuable and is sometimes where the most value is.
All in all, maybe in some categories of devtools, this hyper personalization is indeed what will happen but it's a long way from being universal.
"Five years ago, most software engineers I spoke to had no programs they had written for themselves."
What happened five years ago? Before that everyone used tools they wrote themselves. I think the answer is nothing happened five years ago and everyone still uses tools they wrote themselves.
Everything is now open-source by default. All features are replicable. I don’t really care that much any more that tools need to be OSS because I can make my copies when I want. And I do when I so desire.
Really? Software engineer and you just started making personalized tools recently?
Emacs has been customizable probably longer than I've been alive. Apart from tinkering with Basic, Delphi and Visual C++ when I was a kid, the first things I made were Ruby scripts as personal tools for various things. Had a personalized Emacs environment 20 years ago. Iterated on some abandoned open source projects. And so on...
I guess congrats on an AI telling you about things that have pretty much always existed.
Well we can go a step further and say Devtools must not be VC funded too :) Till date, the best and greatest dev tools I've used have not been influenced by VC decisions.
92 comments
[ 0.28 ms ] story [ 23.9 ms ] threadThe 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.
In principle, you should not need the source code: the AI should be able to answer by examining the binaries.
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.
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.
* 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_package... [2]: https://wiki.nixos.org/wiki/Overlays#Adding_patches
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.
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.
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.
- 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
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.
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?"
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.
That's just so inefficient and wasteful. Assuming a world in which LLMs do most of the coding work, do we want to burn electricity having the LLM build an options dialog or config file parser once, or do we want to burn electricity millions of times as users want to change any little thing about the software they use?
I really hope what you should expect is my answer to that question isn't controversial.
Having an LLM do bespoke customizations that are unlikely to be interesting to other people? Great, sure. But adding a generally-useful feature to a piece of software, but not caring to try to upstream it? Lame. Lame, lame, lame.
Take his side project, Meat. I've been chewing on this problem for a while. It's a real problem right now: it sucks to read all this LLM-generated code. It's worthwhile to have an LLM summarize it for you.
The problem with that is this particular problem resists vibe coding. I've talked to a bunch of people who have tried to solve it on the side, and it's all sort of ... ok, but still unsolved.
- As mentioned, it takes a while to run. You can modify your other tools, as described, to smuggle the latency.
- LLMs don't know what you care about, so you have to maintain a list of things that you do care about, which is ever evolving. If you don't give it that, it produces slop.
- If you miss something, it hurts. Another layer of swiss-cheese AI doesn't feel right. If you trust the AI, just ask Claude to summarize its work!
- The summaries feel shareable, but the author of the PR is actually the most tolerate of slop about a PR. Your reviewers definitely don't want to read the output of a vibe-coded tool talking about 60% of your PR. They could ask their own Claude!
So, we're building a version (https://tern.sh), and it's not open source, because we want it to be shareable and hosted and support teams -- all that stuff that makes it work. At the end of the day, I'm not here to maintain my tools. I'm here to use my tools to do the job.
That aside aside, I agree. Since reading this article yesterday I've probably been overthinking an MIT from AGPL license switch for my own project Ouijit (shill time: https://ouijit.com). Its feels a little counterintuitive since AGPL encourages more open source downstream, but at the same time if I have solved some problem other agent harness devs are curious about, I just want them to take the solution without worrying about paying it back/forward.
The new personalization talking point appears to be coordinated. It is all over the Internet since last week.
Problem is, 99.99% of people (including developers) do not need "personalized" software, unless you mean Emacs style.
Not even Richard Stallman or Linus Torvalds make money on open source or free software despite preaching it. They actually make money from speaking fees.
"Open source" is now weaponized to price down entire companies to the floor and instead of humans maintaining the software, it is now coding agents doing the work.
Neither the free and open source software movement accounted for this disruption and they have become the new starving artists of the software world.
I've been paid to produce FLOSS for quite a few years and I know plenty of people who did too. I did not realize we are such unicorns...
This sounds like hell. You have unreliable actor redoing the software every night, and every day there is a chance you wake up and find your workflow broken.
And no, "Check that the software works as intended" is not going to cut it, as AI are very, very good at obeying the letter but not the spirit of the ask. Yes, your diffs appear but they lack filenames. You've added this requirements to the prompt? Ok, filenames are back but they are font size 4, unreadably small. You want them well-seen? next week they become size 54, taking entire screen.. This is not a problem with regular AI development - you review the changes and test them a bit. But doing it day-to-day with no overview is just asking for trouble.
I've been making a couple little utils like a Clock for AI with an open public endpoint [https://github.com/firasd/mcpclock], a text file sampler [https://github.com/firasd/vblinds] and I was noticing the MIT license seems too encumbered with the requirement to keep crediting authors downstream so I used the 'Unlicense' public domain license
(CC-0 seems to be side-eyed by open source orgs cause it preserves patent rights)
I think we're seeing a new modality of openness now with open weights, or being able to modify agents with md files, skills, and so forth.
I've done this a lot when trying to squash bugs
I deeply disagree with the light vs dark framing. I think the real tension between "hacker languages" and "blub languages" is the expectation to modify the language by it's user.
And this is true for dev tools as well. Hackers prefer modifiable environments (such as Emacs), while corporations prefer standard environments (IDEs) to which programmers will adapt.
(As the saying goes: "The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." Might be why Paul Graham preferred founders with non-blub languages after all, nothing to do with Lisp as such.)
But to be able to adapt the environment, one must understand it. Therefore the pull to make it simpler, a set of universal tools, rather than a complicated machine with many features and ease of use through following prescription.
Engineers using devtools are not so different to an average user in that they just want things to work. Maintaining a devtool is real work; e.g. suppose upstream adds some feature you want but it clashes with something you did downstream. Not in the merge conflict sense but in the UX sense. Do you want to resolve that on every release? Is it just "AI will fix this"? Maybe one day, but as of today agents can do something along the right lines but don't capture my UX sense very well; and if the whole point is hyper-personalization, I want it exactly how I want it.
"Does it seem to work?" is a fine right until it fails when you're doing something important. Do you then stop and go prompt an agent to fix your tooling, and hope it does a good job this time? What if it doesn't do a good job?
Moreover, for devtools which are fundamentally social (i.e. lots of different people looking at the same thing), there's real value in that thing looking the same for everyone. Having a baseline for teaching, auditing, verifying "we are all talking about the same thing" is incredibly valuable and is sometimes where the most value is.
All in all, maybe in some categories of devtools, this hyper personalization is indeed what will happen but it's a long way from being universal.
JetBrains and Claude/ChatGPT are not open source.
I think we would like them to be ... but ...
What happened five years ago? Before that everyone used tools they wrote themselves. I think the answer is nothing happened five years ago and everyone still uses tools they wrote themselves.
Everyone's making cash from your open source code except you.
Your feature page is your source code.
Even open weight models aren't fully open source. It's basically like having the back end binary but not the source code.
Use em to make your life easier but I'd rather not we normalize LLMs becoming the primary way we interact with open source software.
Emacs has been customizable probably longer than I've been alive. Apart from tinkering with Basic, Delphi and Visual C++ when I was a kid, the first things I made were Ruby scripts as personal tools for various things. Had a personalized Emacs environment 20 years ago. Iterated on some abandoned open source projects. And so on...
I guess congrats on an AI telling you about things that have pretty much always existed.