Software you can't personalize is obsolete: why devtools must be open source

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.

> 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.

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've worked at a DevTools company and been the CEO of one too. Here's my thoughts:

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.

I used to be much more of an open source fundamentalist than I am now. For me, it's more about trust than source availability. There are closed source projects that I have high trust in, and there are open source projects that I don't trust at all. A project being open source can increase trust, but not necessarily so.

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.

Separately, JetBrains's revenue grew 25%: https://www.jetbrains.com/lp/annualreport-2026/

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.