--- title: Devtools must be open source | daily.dev description: AI agents have fundamentally changed the economics of software personalization. Using two simple prompts — one to download and modify source code, another to... canonical: https://daily.dev/posts/devtools-must-be-open-source-x03leabiq twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Devtools must be open source | daily.dev og:description: AI agents have fundamentally changed the economics of software personalization. Using two simple prompts — one to download and modify source code, another to... og:url: https://daily.dev/posts/devtools-must-be-open-source-x03leabiq og:image: https://api.daily.dev/og/posts/X03leaBIQ.png og:image:alt: Devtools must be open source og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Devtools must be open source **[Hacker News](https://daily.dev/sources/hn)** · 9 min read · 0 upvotes · 0 comments ## Summary AI agents have fundamentally changed the economics of software personalization. Using two simple prompts — one to download and modify source code, another to set up a nightly cron to rebase local changes on upstream — developers can now continuously personalize any open-source tool without maintaining it manually. The author demonstrates this with Shelley (their open-source agent) and a custom diff-minimization tool called meat.dev, integrated into Shelley with a single prompt. The core argument: because agents can learn a codebase and make targeted changes cheaply, plugin systems and config files are becoming obsolete. Open-source devtools are essential to this future — closed-source tools like Claude Code hit a hard wall where personalization is impossible beyond predefined hooks. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 94 comments across hackernews (as of 2026-08-08). **TL;DR:** The community broadly agrees that open-source devtools are valuable, but is skeptical of the post's core claim that AI agents make plugin systems and config files obsolete — many commenters see the nightly-rebase-via-LLM workflow as fragile, exhausting, and overly idealistic. There's also notable cynicism about the author's motives given their VC-funded, partially closed-source company. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - LLMs have genuinely lowered the barrier to reading, understanding, and modifying open-source codebases, making the original OSS dream more feasible (simonw). - Maintaining a personal fork of a fast-moving project is now more tractable with AI handling merge conflicts and rebases. - Open source enables deeper customization than any plugin system or config file can offer, especially for niche personal workflows. - Developers can now use LLMs to explore unfamiliar codebases quickly ("clone X and tell me how Z works") without a large time investment. **The pushback** - A nightly AI-driven rebase is seen as fragile and risky — AI reliably satisfies the letter but not the spirit of requirements, and broken tooling mid-workflow is costly. - The argument that config files and plugin systems should be replaced by source-level AI edits is widely rejected as wasteful and inefficient. - Maintaining a personal fork is still real ongoing work even with LLMs, especially when upstream UX or architecture changes conflict with downstream customizations. - The author's company (exe.dev) is VC-funded and partially closed-source, which many commenters see as hypocritical given the post's open-source advocacy. - Open-source maintainers are already overwhelmed by AI-generated PRs and slop contributions, making the ecosystem harder to sustain. - Most developers (and users) simply want tools that work, not side projects requiring ongoing maintenance of build chains and custom patches. - LLM-assisted personalization still depends on access to expensive frontier models, which is not universally available. **By community** - hackernews (mixed): Commenters appreciate the broader open-source argument and acknowledge LLMs are changing the economics of code exploration, but strongly push back on the nightly-rebase workflow and the dismissal of plugin/config systems, while also questioning the author's credibility given exe.dev's own closed components. **Hottest debate:** Whether AI agents make traditional plugin systems and config files obsolete, or whether source-level personalization via nightly LLM rebases is an impractical, fragile, and exhausting alternative. **Open questions** - How do you handle upstream UX or architectural changes that conflict with your personal downstream customizations in a way that AI can't automatically resolve? - Is hyper-personalized tooling actually desirable if it means every developer's environment looks different, undermining the social/collaborative value of shared tooling? - How do open-source devtool companies build sustainable businesses when AI makes it trivially easy to vibe-code a 'good enough' clone of their commercial product? - Does the dependency on closed, expensive frontier LLMs undermine the open-source ethos the post is advocating for? **Highlights** > 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. > — [simonw on hackernews · 14 comments](https://news.ycombinator.com/item?id=49156719) > > Set up a nightly cron job that executes the prompt: fetch upstream changes to the 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. > — [theamk on hackernews · 2 comments](https://news.ycombinator.com/item?id=49157016) > 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. > — [lalitmaganti on hackernews · 2 comments](https://news.ycombinator.com/item?id=49158172) > 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. > — [kelnos on hackernews · 6 comments](https://news.ycombinator.com/item?id=49156731) > 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. > — [throwatdem12311 on hackernews · 3 comments](https://news.ycombinator.com/item?id=49157657) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49146900) · 11 points · 2 comments - [hackernews](https://news.ycombinator.com/item?id=49156111) · 232 points · 92 comments ## Similar posts on daily.dev - [Developers don’t get paid to write code](https://daily.dev/posts/developers-don-t-get-paid-to-write-code-iwue76sb3) · All Things Open · 0 upvotes · 0 comments - [AI Agents Could Make Free Software Matter Again](https://daily.dev/posts/ai-agents-could-make-free-software-matter-again-ijrbpmgqk) · Hacker News · 3 upvotes · 0 comments - [These open-source tools do what Claude charges for, and some do it better](https://daily.dev/posts/these-open-source-tools-do-what-claude-charges-for-and-some-do-it-better-nqphnogii) · XDA Developers · 1 upvotes · 0 comments - [Leveraging AI as a Developer: Creating Developer Tools](https://daily.dev/posts/leveraging-ai-as-a-developer-creating-developer-tools-mgadsenbd) · Atomic Spin · 1 upvotes · 0 comments --- Tags: [#open-source](https://daily.dev/tags/open-source), [#devtools](https://daily.dev/tags/devtools), [#ai-coding](https://daily.dev/tags/ai-coding), [#claude-code](https://daily.dev/tags/claude-code) [View this post on daily.dev](https://daily.dev/posts/devtools-must-be-open-source-x03leabiq) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Devtools must be open source","url":"https://daily.dev/posts/devtools-must-be-open-source-x03leabiq","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/devtools-must-be-open-source-x03leabiq"},"datePublished":"2026-08-03T15:17:40.129Z","dateModified":"2026-08-08T12:04:07.564Z","description":"AI agents have fundamentally changed the economics of software personalization. Using two simple prompts — one to download and modify source code, another to...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3c36a4718cb9f2c0b2a1eb1e73a77980?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3c36a4718cb9f2c0b2a1eb1e73a77980?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/devtools-must-be-open-source-x03leabiq","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"open-source,devtools,ai-coding,claude-code","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Devtools must be open source"}]} ```