Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by shay_ker - Years ago, we were revamping a mission-critical project with more than a 1000 database tables to a backend of .net and EF. Our rewrite was much cleaner, but still had 450 tables. We started noticing that our backend took 2 minutes after starting up to serve the first request, fast after that.
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.
by aljgz - I liked your article on its merits but this:
> 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.
- Specially in an article that initiates the conversation advocating for setting a machine that stays on overnight running agents making rebases among who knows what else. There are two other frontpage threads right now tangentially about the cost of AI, I'll have this conversation there, to see how well the idea this cost is gone holds up against a primed crowd.by nightlycosts
- 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.
by knighthacker - I think it's pretty common in software companies to maintain own custom fork of an open-source tool/library.by ivanjermakov
- > 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've done this a lot when trying to squash bugs
by s777 - 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.
by pornel - 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.
by fasterik - 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.
by js8 - 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.
by jedberg - The answer is you don't sell the tool. You release the tool, others help you make it better, then you use the tool to build the actual thing.by dismalaf
- Open sourcing devtools seems like a "commodify your complement" thing. A way to do that is to sell hosting. People can self-host if they want to, but some people will prefer to pay a hosting service.
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.
by skybrian - > Some tools have started making licenses that are free for individuals and startups but cost money for profitable companies.
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.
by pbjerkeseth - > 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.
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.
by rglover - 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.
by lalitmaganti - 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.
by skybrian - > 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.
by zephen - "We need the source code." No, you want the source code. You want software someone else put their time, effort, and judgement into to be available for you to do whatever you'd like with it without any recompense. The sense of entitlement here is exhausting.
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.
by quintu5 - > 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.
by theamk - > This sounds like hell. You have unreliable actor...
But, at least you know the cost up-front.
Oh, wait...
by zephen - Workflow being broken is the least of your worries. This is a security nightmare.
- I don’t auto-rebase but I definitely vendor in and choose to update on my own cadence.by arjie
- I don't know; I've been rebasing huge branches in really mean divergent states with Claude Code, and it handled it flawlessly pretty much every single time. So I don't think the actor is as unreliable as you think.by 9dev
- If your coding agent workflow isn't sandboxed, backed up, and rollback-able, it's fundamentally broken. And yes I realize most of us aren't working this way today. But I think we'll have the tooling pretty soon. There's currently a cambrian explosion of solutions in this space.by apitman
- > "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.
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.
by g3f32r - I suspect the people advocating for this don't actually do this, its one of those things that you say because it sounds modern and up to date, and makes for a good sounding blogpost. The actual reality of any of what they're talking about is absolutely terrible
Even just the cost of this would be a disaster, especially once everything goes to token based pricing
by 20k - 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.
by kelnos - 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)
by bluGill - 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?".by herrkanin