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.
Devtools must be open source
201–210 of 262 posts
Re: Devtools must be open source
#202One 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…
This is the sad truth. Some of these projects are just WAY too big for anyone to meaningfully digest what's happening. Chromium or Android? That's cool that their open, but they could just leave huge swathes of unobscured, liberally commented code - detailing how they're ravaging the host machine or sending deeply private telemetry home to Google and 99% of users would be none the wiser. All while being "open".
You could liken it to those 100 page ToS agreements most people just click "accept" to and never read. There could literally be anything in there, and even if you had the motivation to try and peruse it, the odds are definitely NOT in your favor.
Re: Devtools must be open source
#203Re: Devtools must be open source
#204I 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?
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…
All potentially with the ai model(s) running with no secondary prompt other then “make git error commands sarcastic”
Re: Devtools must be open source
#205Everything 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.
Re: Devtools must be open source
#206Re: Devtools must be open source
#207Earlier quoted context omitted.
Around 2020 I started getting downvoted for predicting that while the most popular programming languages at the time were Python, Java, and JavaScript, or whatever they were, the most popular programming languages in 2035 would be English and Mandarin. Looks more like 2030, after all. So the downvoters had a point.
I think having some real examples of this 2035 is a lot more feasible now than it would have looked to most people in 2020, but the majority of projects in 2030 is absurd. Can you name even one piece of software today that is actually built this way? This means: Every release, the only thing done is they edit a prompt and then ship the build that comes out of LLM -> CI/CD ? Then they delete all the source that was ge…
Re: Devtools must be open source
#208One 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…
> Most people can't justify the time commitment needed to read and then modify the code for tools they use very often. As someone who way long before the LLM age had small patches accepted in several dozens of projects I've been using, I can assure you that this is just a matter of mentality. All I needed to be able to do that was to stop thinking that "nobody has done it so far, so it must be hard" and just do it. S…
Re: Devtools must be open source
#209Earlier quoted context omitted.
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…
> if licenses permit. As if licenses mattered in the LLM era Case in point https://news.ycombinator.com/item?id=48466812 > In looking at the code that the LLMs have produced for the project, especially given the pretty massive and widespread architectural changes needed to make the implementation libified and memory safe, we decided that the codebase is not a derivative work that would require carrying forward the GP…
They still do, if you want your changes be made public, or even upstreamed.
No sane license that gives access to the source code forbids modification for internal use; one reason is that it would be really hard to enforce.