Devtools must be open source
blog.exe.dev
blog.exe.dev
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.
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...)
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.
This is true, of course, but having a community is completely orthogonal to whether software is open or closed source.
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.
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.
Does it? I think a lot of software projects which are not as huge as the Linux kernel etc. thrive best with a tight core development team, and not from a "community" if you mean that word beyond "users".
Look at it from the point of view of a maintainer. Not sure if you've ever tried. People want to pull your software towards a million incompatible directions. They write some big patch and then get angry if you don't merge it.
My advice: consult the maintainers first whether they agree with your idea and whether they are open to considering your submission. You still won't have a guarantee that it will be accepted, because that's their final say. But at least you won't spend effort coding up something that they could already tell you they don't want to have in their software.
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.
“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$
If that gets fixed, the project gets the money.
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.
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.
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.
It seems like a great stretch to call this "slop".
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.But at the same time LLMs also let you question why you’re using a dependency if it’s causing certain issues for you.
e.g. I got tired of waiting for libghostty to publish a new stable release since the one in March which would have a memory leak fix I reported, so I spent a week of getting LLMs to build my own solid pty/terminal emulator. Now I have my own and frankly I'm in a better position having done it.
That's a ridiculously massive change to our relationship with software projects.
And even if you aren't that robust about it, terminal apps are the sort of ideal vibe-coded app since, using it daily, you are giving it a constant real world test that uncovers issues to be fixed incrementally.
Is neovim over tmux over ssh glitching? LLM can fix it.
Is codex or claude code overwriting lines in the TUI, maybe due to alt screen, but it also happens in other major terminal apps? LLM can figure out why and whether you can come up with better general architecture to fix it.
Is there behavior you wish you had but no other terminal app supports? LLM can add it.
You can end up with a far better product than what you would find in the wild, and it's a fun sort of work.
I thought about this but I currently maintain a fork of about ~6 things I use on my own, none of which I have any interest of contributing upstream because it'd be out-of-scope and put a burden on the maintainers that is unrelated to their primary goal. It has been an extremely easy experience with claude to keep those tools up to date on top of upstream.
StGit/Stacked Git is a proven tool for this and has worked wonders, I can literally just ask claude to fetch upstream and reapply stg patches on top and fix each patch if they break in order. I also keep extensive description of the INTENT on the stg patches so claude can easily figure out if something is no longer relevant (ie: somewhat implement by upstream) or where to land the code/hooks. I've added features, reworked how algorithms work (pathfinding related!) and small nits I hit on daily usage.
Even on a very churny upstream (one of the projects the single dev likes to refactor alot) it's still extremely chill and doesn't take more than an hour to get it updated when everything breaks. I can't say i care enough to setup a daily cron like a sibling suggested, but it would likely work just based off of this stg experience.
It's also nice, because some of those were actual bug fixes too which i have contributed back upstream! Maintaining your personalized fork is truly reasonable nowadays.
> 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.
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.
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?
Yeap. Most users want someone else to think for them. Not just "something" (AI). Having a vision on what works best (design) is still, for the time being, a human task IMO.
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?
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.
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.
Ah, but we used to pay, and many of us still do, because as programmers, some of us also like to earn salaries, we don't get to buy groceries with pull requests.
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 - 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.
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.
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.
Asking because I am working on an open/standard protocol/layer for provisioning cloud resources across different providers. One of the ideas is to provide a marketplace of providers/resources via one unified/standard API, which I would allow automatic selection and provisioning of VMs (and other resources) based on price/value/feature/reputation requirements/priorities.
I've written three different solutions for platforms that solve this standard protocol layer. What has worked for us was deciding to standardize on the Kubernetes API for our services back in 2017, and then from then on, all our providers have provided either a k8s API to interact with resources, or provide a Cluster API for provisioning. For example we have two datacenter VM providers that implement the k8s API and we've been able to swap the providers with no user refactoring, it's a good solution in hindsight with how many people have k8s in their stack.
For the second big feature you're thinking of, we never really go a good solution to this problem, a lot of our workloads are long lived and not necessarily spot instance-able, but it's a very fun routing problem. Most of our need to be in multiple clouds is that we want to heavily separate our customer facing services, and keeping it away from internal workloads that support those customer APIs.
Is this public work? I'd love to take a look. This is my bread and butter.
I will be publicly releasing everything ~soon (I hope), it's in a pretty early stage at this point, many open questions.
Our use case is pretty specific though - one persistent machine that you set up your full developer environment on, then ability to very quickly spin off full copies of that machine (filesystem + memory) as separate VMs to run agents on. Firecracker VMs + support for "forking" the box were our key requirements. Another provider that could do this was Modal, but they use gVisor and not Firecracker, which means it's harder for users to run docker inside the box.
So if you want to not piss off your users, that's the way to do it. Build a model where you can actually sustain the product, and no, giving it away on seed and series A round money then rug pulling that gift is not the way to achieve that.
As if licenses mattered in the LLM era
Case in point
https://news.ycombinator.com/item?id=48466812
> In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GPL license and have decided to release the code under the MIT instead.
LLM are copyright laundering machines
Not only they launder copyright from Internet at large, they can also launder from specific targets
They still do, if you want your changes be made public, or even upstreamed.
No sane license that gives access to the source code forbids modification for internal use; one reason is that it would be really hard to enforce.
And yet I am worried that my actions are perceived as hostile. Some people just don't care.
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...
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.
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.
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
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.
I'm grateful for the work you've done!
And when I'm debugging I read all the code I have access to - certainly glibc pretty often, Python C implementation and C libraries quite often; the Go runtime, if only for the education, etc. It's not often I need to read the kernel implementation, except sometimes for networking protocols where it's also educational. I have found over my career that reading excellent code is as important to the quality of my code as writing code and iterating on it to make it good.
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.
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
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
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?
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.
In principle, you should not need the source code: the AI should be able to answer by examining the binaries.
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.
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.
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.
- 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.
[1] https://www.zdnet.com/home-and-office/networking/mozilla-cha...
Remember you are not working alone. Different people/companies work differently, but nearly every job has - at least once in a while - a time when someone will be ask your computer reading something on your screen with you. vi vs emacs is bad enough, but at least I know how to do minimal navigation, save, and exit from each (I expect that advanced users of those tools can do much more): there are only so many different systems I can learn though, and it is unfair to make everyone have to learn another. Thus emacs should not allow your to customize your environment with local scripts, either it is in base (as IT installed it), or it isn't allowed! (to my knowledge vi/vim doesn't allow this). Similar for other tools, if it isn't easy for someone who isn't an expert: either your company shouldn't allow it at all, or they need to ensure everyone is encouraged to get training (not forced in case you wouldn't do that anyway - but it should be automatic if you want it and you should know you can get it)
Font size - I've worked with nearly blind people who need huge fonts just to see/read. However this is a compromise and they are worse developers for lack of ability to see as much text as a smaller font enables. Don't get me wrong, they are still great developers, but their eyes are a limit to how good they can be. It is thus reasonable to have a configurable accommodation for that. There are a number of other examples where things can be configurable, but the configurations should be controlled and easy to find. (I'm color blind, if you allow color coding that is fine so long as I can find a color that works for me)
Personalized tools is how you eliminate friction, it'd be a misallocation of priorities to take that away.
As an side, vim definitely allows user scripts.
Cream and SpaceVim are not separate editors, but sets of configs and plugins to provide a much different experience from stock Vim or neovim.
I do think modularity will remain important because it makes merge conflicts less likely, and a system with good modularity could look a lot like a plugin system, except that AI can likely deal with minor compatibility breaks if it’s clear what to do.
It’s a similar argument to why Linux device drivers are in-tree. If there are API changes then the AI fixes the callers. Compile-time checks are good because it’s direct feedback to the AI.
Not even remotely true except that in both cases you change a number in some text file. If you do it in source code, you have to get the source code, you have to identify the correct line[s], you need a build environment, you might have to reinstall the new version after the build. And on top of this you want to involve a language model in this. The difference in complexity, effort, and resource consumption is orders of magnitude. And we are not even considering that you will have to go through this for each future version to keep your modification included. This is an insane way to change a font size.
If you have a self-sufficient OS, the build environment is already part of it.
> you have to identify the correct line[s]
Just run a full-text search on the old value.
How often does 10 appear in the code base? And is the value you are looking for even 10 or does only the UI show 10 points but in code it is defined as 200 twip?
...and the build doesn't require any tools that aren't already on your machine, and there are no dependencies to download
Many of the best tools I use are written in languages I don't program in and thus I don't want the build tools and package caches for those languages taking up space on my drive. I'll take the config file any day.
Having your config file be a c header and needing a recompile is different than not having any user accessible configuration
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.
But, at least you know the cost up-front.
Oh, wait...
Right now, I just have a build server that I ship things to and does lots of build-caching etc. so it's fine, but I would have preferred not to have a system that actively allows build-time thievery of my ~/.ssh
Even just the cost of this would be a disaster, especially once everything goes to token based pricing
Looks more like 2030, after all. So the downvoters had a point.
This means:
Every release, the only thing done is they edit a prompt and then ship the build that comes out of LLM -> CI/CD ?
Then they delete all the source that was generated, along with the context, and only the prompt is carried forward to the next release?
If you want the model to maintain a certain look and feel, or to preserve the UX in other ways, tell it. Even if it doesn't get it 100% right today, the direction of progress is pretty clear, so you might as well get used to prompting the models accordingly.
This is simply not the case when working with Fable-class models. Those who persist in believing it are hopefully very close to retirement.
I'm not 'advocating' anything, just stating a fact.
Surely you don't think that he literally meant to use those seven words as a bullet proof prompt, right?
I will never understand this way of responding literally and pedantically to verbal psudocode. He's leaving it as an exercise to the reader to specify "check that the software works as intended" because he could never possibly properly articulate a perfectly comprehensive QA and validation flow for every piece of software that would satisfy every individual's need.
Again, this is normal if you are interactively working on software and can fix any problems you see. It is only problematic if you do what OP says, and make it on cron, daily and unattended.
There are plenty of good reasons to choose an an open source tools and sure, the ability to personalize a tool at the source layer can be valuable enough in some instances to justify maintaining a fork manually or with an agent.
Asserting that dev tools must be open source to prioritize a paradigm where users roll the dice on adding features by one-shotting them with an agent and then burning tokens until the end of time to try to keep their forks compatible with upstream changes because plugin APIs are too restrictive doesn't pass muster.
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.
I think will work better for nice-to-have features that are ultimately disposable if they become too hard to maintain.
I think it would be exhausting. Even if nothing broke, upstream UI changes could change your program daily. It makes a lot more sense for pulling changes that are security or bug fixes.
It seems like it would make sense for pulling enhanced functionality with no UI changes, but would you even use the enhanced functionality if you didn't even know it was there?
OTOH, I suppose if you organized your workstream correctly, you would always have previous binaries to fall back on.
I agree that they need to be open source. But that makes it really hard to make a successful business. Sure, there are examples of success, but also many examples of successful open source tools never becoming successful companies.
The most famous example is Sendmail (where I worked way back in the day). They took millions in funding and ultimately sold to an infra company, returning pennies on the dollar to their investors.
The difficulty stems from the fact that your customers are developers and operators, and they all think that they don't need you because they are perfectly capable of running the software themselves and adding whatever they need to it. In a lot of cases they are right.
And now, with AI coders, it gets 10 times worse, because they can take your open source and then vibe code a "good enough" version of your commercial product.
I don't know how to square this circle. There are a lot of great dev tools made by people for free for the love of the game. But even those people need to eat.
Some tools have started making licenses that are free for individuals and startups but cost money for profitable companies. That's an interesting strategy but I know some companies won't allow those tools precisely because of their license.
Ive seen this as well, but at a certain point it just seems like if your code is online, someones either taking it wholesale or recreating core pieces from the spec regardless of any licensing.
Its a tough time to be building OSS if you don't have distribution solved AKA some pedigree from the before times.
I think this has always been true, but you're right, it's much more pronounced now.
You really don't. If people can get something for free (effectively what OSS means to the average bear these days), they will, and they really don't care if the creator/maintainer can survive. And if that creator/maintainer doesn't, the logic boils down to "what's the replacement for <insert incumbent>?"
IMO, the combination of OSS and "generous free tier" SaaS plans basically nuked the willingness to pay for software, especially dev tools. Folks are just too conditioned to expect stuff to be cheap or free nowadays. Maybe that changes long-term but shrug, who knows.
The successful business model is more like make tool, give away tool, make random project management/accounting/tool that devs would never use and normies can't make.
It's not just FOSS: the era of commercial software is equally over. Why pay for something that leaves you dependent on a third party for bug fixes or new features? Vibe it up yourself, and pay for only what you need, when you need it.
Dev tools are a tougher sell because other devs can make them. Your normie SP500 manager isn't going to whip up some project management software in his free time.
This is what exe.dev is doing. Their open source devtools (like Shelley) sit on top of their hosting service and could be self-hosted. But they aren't open sourcing the software they use to run their VM hosting service.
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.
Regarding personalization, I would much rather use software with strong design principles that's simple, opinionated, and works out of the box with sane defaults. I want to spend my time getting work done, not tweaking settings and adding custom features.
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.
Now we're getting to the point where any user can say "Claude, I don't like that. Please fix" and have it fixed. Configurability/extensibility can work in some cases, but having source code makes it much more powerful.
I've done this a lot when trying to squash bugs
> Both the upfront fixed costs and the ongoing costs of personalizing software have disappeared.
Is just wishful thinking, at best. We can say your own quirky little personalised software that works on your computer might have become cheaper. Production grade software that people pay for is a different beast. That’s why people pay for software: support and ongoing maintenance. LLMs have not and are unlikely to change that part of the equation. As a business the pure liability of not having anyone to call about an issue is a BIG issue.
It turned out EF had a stage named "view generation" which verified that data would round-trip, meaning if it goes into the DB and comes back, would stay the same. Run time was exponential on the number of tables and complexity of models.
People used tricks to work around it, which was basically caching the "generated view" in a file, which could speed up the production startup, not as easy in DEV environment, our programmers still needed to wait 2 minutes after each compile.
I started looking into it, and it turned out that Microsoft had open sourced EF a short time ago (long after we had started the project).
While profiling, view generation took much longer, 450s, as it was a CPU-heavy process. There was a function excluded from release builds by a `[Conditional('DEBUG')]` attribute, and when I removed the call to it, the time went down to 64 seconds, 63 of which was in a very simple function. A LINQ statement in there could be re-written to make it 120ms.
I ended up contributing it to EF core, being acknowledged in their blog post, and we ended up using our own release build of EF libraries until the fix made it to the public release.
Had they not open sourced EF, it could turn into an existential threat to the project.
But back to OP, for this prompt:
> 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.
Seems like nice syntax sugar to add a `/maintain-fork` command.
This might not generalize beyond developers, or at least not right away. Even if we’re not doing the upgrades ourselves, we know what a merge conflict is, and we’re probably better at telling the AI what went wrong so it can fix it.
These don’t seem like skills that are all that hard to learn for someone who’s interested. Also, merge conflicts an AI can’t deal automatically likely mean something major changed upstream.
There will be jobs helping people who get into more trouble than they can dig themselves out of. And if you can’t afford that, I guess it’s a learning experience.
All potentially with the ai model(s) running with no secondary prompt other then “make git error commands sarcastic”
Yes, please make me rebuild my software to change an API endpoint or port number. It's a wonderful use of time and electricity to build and spin up agents to fix the inevitable problems with building software. Instead of changing a string in configuration file.
(/s if not obvious).
Configuration and plugin systems exist for a good reason: software should be reconfigurable and modular without requiring the wholesale replacement of the original. Even if the code is open source, there are good reasons to move logic and data out of tree and into config or plugins.
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.
Apparently the dude found some new acquaintances.
Everyone's making cash from your open source code except you.
"Lather, rinse, repeat." Some things never change.
- GitHub closed source - AWS closed source - GCP closed source . Slack closed source - ChatGPT closed source . Claud closed source - though mention only in passing Google Docs is also closed source
Then they hawk a product they are selling: Cloud Pool plan
If you limit the argument to just be the exact thing you have running on your desktop then I think the definition is so narrow its nearly useless.
The other day I wanted to build personal apps for my Kobo device. It has a single ~800Mhz core and 512 MB of RAM, probably eight times less than a rasbperry pi, but runs a Linux.
I wanted to break free from watching my laptop screen for long Claude sessions partially due to degrading eyesight and have a sidekick for approvals streamed to the Kobo. Apart from the Claude and Codex permissions sidekick done via hooks, I ended up building an entire SDK, an HN client, an RSS discovery & reader and an audiobook generator using deep research and ElevenLabs API all running on it.
Anyone using an LLM can now personalize it for their own Kobo device, which might have some nuances over my Clara BW. Significantly less work I hope than doing it all from scratch even with a coding agent.
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.
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 the other side of it is more important: making software simpler so that people can work with the code without having to use AI. That's what I try to do.
https://peat.eth.demokluster.com https://peat.eth.limo https://peat.eth.link
git clone https://peat.eth.demokluster.com/peat0.git
(webpage itself incl ro-git is hosted/mirrored over IPFS/ENS)
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...
Your feature page is your source code.
The scammers are now doing open source vendor/dev lock-in via massive size and complexity... while there are small and stable in time alternatives able to do a good enough job. Those guys are not all malicious, many are just brain washed and some suffer from a mental disorder: accute Rube Goldberg Machine syndrome.
I can use codex on pi, deepseek on pi, I use them on different tasks and let them review each other.
Tell deepseek flash anything you want changed and a minute later it's there.
Forget vibe coding, I'm vibe-using the thing and having so much fun.
JetBrains and Claude/ChatGPT are not open source.
I think we would like them to be ... but ...
I've seen https://v-it.org/ here on hackernews. Same idea, different wording.
And we live in capitalism, where making money is not optional.
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.
FWIW the first version of meat was based on anthropic models, I switched to Oai models because they are faster and just as good right now. This is an astonishing thing to say, but the switch was a single shot prompt using a frontier model. I’m happy to add some selector there, but that is also the point of this article: do you really need me to make it configurable when you can switch the tool over to Anthropic with a single prompt? It’s a strange new world we live in.
On the website: you’re right. I have some side-by-side diff examples I want to turn into a website. I am just short on hours in the day. My real goal is to make the tool compelling enough that I can convince my colleagues that we should build it into Shelley. :)
On another note, the reason I was perusing the blog was because I was curious about more of how exe handles review/quality/testing because you mentioned there being no code review in another post about stripe billings (maybe a different author). So consider this a casual request for more content on reducing delivery bottlenecks :)
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's the memed magical thinking of "make no mistakes"
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.
We are on the road that leads there, and this describes going further along it.
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.
"The exe.dev LLM gateway provider source within an LLM integration remains supported. It provides exe.dev-managed access to Anthropic, OpenAI, and Fireworks models. Your subscription includes a monthly token allocation, and you can purchase additional tokens at https://exe.dev/user/shelley."
The access to closed platforms is managed according to the docs.
I guess I don't understand the OP's point even. Is there some conflict with providing this service and still being passionate about open source? IMV the answer is no.
Their main software product, Shelley, is open source: https://github.com/boldsoftware/shelley
I've used the LLM only a few times to make a few sysadmin tasks easier that I could have easily done myself.
I agree with you.
They are manipulating public opinion, fooling users.
We are all busy discovering the shape of new tools and norms as our profession has been overturned by LLMs. It is not too surprising similar ideas are floating about. Though I have not seen anything that captured how I now go about personalizing programs, and how I expect it to change our industry. So I wrote this.