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.
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.
> 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
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...)
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.
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.
> 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.
> 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.
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.
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.
> 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.
> 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.
> 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...
> 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.
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.
> 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?
> 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.
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.
> 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.
Maintaining a fork seems trivial for an LLM. Replaying each upstream commit against your fork is exactly what even dumb models can do without issue.
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.
> 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".
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.
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.
Even pre-LLM this is how suckless tools work, I actually don’t much mind having to edit a variable in a header and recompile when you make a config change.
I completely agree - we've seen that tools with plugins are really scalable and then allow the better plugins to be folded back into the main tool where they become popular. I've taken that approach with my own dev tools that I've created.
The real waste is that tweaking a config setting is a one-and-done deal, I don't want my tools to be side projects that require maintaining their build chains and frequent customization even if an LLM is doing the heavy-lifting.
Updating a constant versus a config parameter isn’t all that different if the build is fast.
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.
Without any evidence to back it up, my hope is that your criticism in a decade will be the equivalent to "Everybody having a mainframe at home? Do we want to waste a whole room in each and every house just for that?".
do you want browser extensions to be able to modify browser code on the fly with regex? that's how you get browser extensions being able to modify browser code on the fly with regex
Having an embedded scripting engine for large programs is nice for simplicity and keeping configuration modular - it would be messy to need to modify source constantly. It’s not an issue of it being difficult to compile something so much as it being pointlessly difficult to maintain.
There are some things that should be configurable and some things that you should not be allowed to configure.
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)
The idea that IT should lock down editor configs treats software development like a factory line where workers should be interchangeable parts. Maybe it is, but I disagree. Software is a craft, and a developer's environment is an extension o fhow they think. If pairing is hard because of someone's custom setup, the answer is to use tools designed for collaboration, not mandating a specific editor config. Check out the code locally.
Personalized tools is how you eliminate friction, it'd be a misallocation of priorities to take that away.
> 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.
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.
> I can see the allure of this line of thinking but I think it's sadly too idealistic.
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.
The idea is that upgrading a devtool is like upgrading a vendored library. It's not something you do automatically or while you're in the middle of doing something else. Usually the AI can fix merge conflicts. If upstream changes are too extensive, you can have the AI rewrite the change entirely.
I think will work better for nice-to-have features that are ultimately disposable if they become too hard to maintain.
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.
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.
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?
It does not even have to break, you and your LLM can introduce subtle bugs or vulnerabilities to a codebase you are not familiar with and there is a userbase of 1 person to catch this.
You tell the AI what broke and it fixes it, and this is usually a better experience than contacting support. But what if that fails?
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.
"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.
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'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.
Before LLMs the barrier to modifying software was much higher - in skill and time investment required.
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 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.
AGPL software is in practice always gratis, because anyone who has a copy can post it on the internet where anyone can download it. The monetization benefit of AGPL is that it makes it significantly more annoying (but by no means impossible) for IaaS providers to sell managed hosting for the software without making a separate commercial agreement with the copyright holder. This usually isn't relevant to dev tools that users run on their own machines.
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.
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. :)
Website not even needed! Janky terminal screenshot in the repo would have been good enough for me lol.
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 :)
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.
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.
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.
(Author here.) Open models are really quite good now. I still use oai as my daily but I have been very impressed by qwen/glm/k3/etc when I try them. They are clearly my future.
Resells OpenClaw? What are you on about? and exe has no markup through their LLM gateway. Maybe educate yourself before talking smack about an awesome little company and platform like exe.dev.
exe.dev has quickly become my platform of choice for hosting, testing, playing and tinkering. I haven't had this much fun playing with a providers offerings since VMs were a new thing. You have no idea what you're talking about here and should do a little research on them first. What you are saying they are, is not that.
"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.
And? It's a convenience for their users (and most users for sure want this) for easy access to frontier closed and also open models (Fireworks). They advise also there is no markup or profit made for them in providing this managed gateway.
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.
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.
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 - 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.
> 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
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...)
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.
> 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.
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.
Solid approach. The cost/performance tradeoff is key here.
> 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.
> 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.
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.
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.
> 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.
> 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.
> 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...
> 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.
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.
> 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?
> 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.
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.
> 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:
Maintaining a fork seems trivial for an LLM. Replaying each upstream commit against your fork is exactly what even dumb models can do without issue.
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.
I too built a terminal emulator and I like it, but I wouldn't say it's easy to maintain even with LLMs. The # of edge cases is insane.
> 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".
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.
What stack is this built on? Looking at the architecture.
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.
Even pre-LLM this is how suckless tools work, I actually don’t much mind having to edit a variable in a header and recompile when you make a config change.
https://dwm.suckless.org/customisation/
Only for trivial programs - I don't mind running make on a 2500 line C program, I would mind having to recompile LLVM or Firefox.
Which is why many of us happily ignore their existence.
I completely agree - we've seen that tools with plugins are really scalable and then allow the better plugins to be folded back into the main tool where they become popular. I've taken that approach with my own dev tools that I've created.
The real waste is that tweaking a config setting is a one-and-done deal, I don't want my tools to be side projects that require maintaining their build chains and frequent customization even if an LLM is doing the heavy-lifting.
Updating a constant versus a config parameter isn’t all that different if the build is fast.
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.
Without any evidence to back it up, my hope is that your criticism in a decade will be the equivalent to "Everybody having a mainframe at home? Do we want to waste a whole room in each and every house just for that?".
do you want browser extensions to be able to modify browser code on the fly with regex? that's how you get browser extensions being able to modify browser code on the fly with regex
[1] https://www.zdnet.com/home-and-office/networking/mozilla-cha...
Having an embedded scripting engine for large programs is nice for simplicity and keeping configuration modular - it would be messy to need to modify source constantly. It’s not an issue of it being difficult to compile something so much as it being pointlessly difficult to maintain.
There are some things that should be configurable and some things that you should not be allowed to configure.
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)
The idea that IT should lock down editor configs treats software development like a factory line where workers should be interchangeable parts. Maybe it is, but I disagree. Software is a craft, and a developer's environment is an extension o fhow they think. If pairing is hard because of someone's custom setup, the answer is to use tools designed for collaboration, not mandating a specific editor config. Check out the code locally.
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.
LLMs make things easier but can we not advocate for making them a dependency to configure our tools?
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.
> 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.
I don’t auto-rebase but I definitely vendor in and choose to update on my own cadence.
> This sounds like hell. You have unreliable actor...
But, at least you know the cost up-front.
Oh, wait...
I like the idea but I think manually editing source code is a bit too extreme. I’d rather have a plugin system or make the config scriptable.
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.
> I can see the allure of this line of thinking but I think it's sadly too idealistic.
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.
The idea is that upgrading a devtool is like upgrading a vendored library. It's not something you do automatically or while you're in the middle of doing something else. Usually the AI can fix merge conflicts. If upstream changes are too extensive, you can have the AI rewrite the change entirely.
I think will work better for nice-to-have features that are ultimately disposable if they become too hard to maintain.
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.
Your feature page is your source code.
Some time ago, there was a comment https://news.ycombinator.com/item?id=48849015
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.
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?
It does not even have to break, you and your LLM can introduce subtle bugs or vulnerabilities to a codebase you are not familiar with and there is a userbase of 1 person to catch this.
You tell the AI what broke and it fixes it, and this is usually a better experience than contacting support. But what if that fails?
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.
"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.
exe dev is a VC-funded company reselling open source software.
Everyone's making cash from your open source code except you.
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'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.
Before LLMs the barrier to modifying software was much higher - in skill and time investment required.
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 think it's pretty common in software companies to maintain own custom fork of an open-source tool/library.
exe.dev is NOT open source. Funny
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)
Good point, but extensibility != OSS though.
JetBrains and Claude/ChatGPT are not open source.
I think we would like them to be ... but ...
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.
AGPL software is in practice always gratis, because anyone who has a copy can post it on the internet where anyone can download it. The monetization benefit of AGPL is that it makes it significantly more annoying (but by no means impossible) for IaaS providers to sell managed hosting for the software without making a separate commercial agreement with the copyright holder. This usually isn't relevant to dev tools that users run on their own machines.
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.
(Author here.)
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. :)
Website not even needed! Janky terminal screenshot in the repo would have been good enough for me lol.
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 :)
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.
I earn income selling copies of free/libre/open source software. Other people could too, if they tried, but they don't.
Torvalds got RedHat and VA Linux stock options and probably has a very good contract with the Linux Foundation.
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.
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.
(Author here.) Open models are really quite good now. I still use oai as my daily but I have been very impressed by qwen/glm/k3/etc when I try them. They are clearly my future.
Company that resells openclaw and closed providers preaches about open source.
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.
Resells OpenClaw? What are you on about? and exe has no markup through their LLM gateway. Maybe educate yourself before talking smack about an awesome little company and platform like exe.dev.
exe.dev has quickly become my platform of choice for hosting, testing, playing and tinkering. I haven't had this much fun playing with a providers offerings since VMs were a new thing. You have no idea what you're talking about here and should do a little research on them first. What you are saying they are, is not that.
https://exe.dev/docs/shelley/llm-gateway
"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.
You don't need to use the LLM integration at all if you choose not to and even without it, it's a lovely service.
I've used the LLM only a few times to make a few sysadmin tasks easier that I could have easily done myself.
And? It's a convenience for their users (and most users for sure want this) for easy access to frontier closed and also open models (Fireworks). They advise also there is no markup or profit made for them in providing this managed gateway.
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