Branches and worktrees exist and can effectively act as a "separate" history. At the end of the day you would still merge the changes in, possibly with a squash if you don't care about the little commits.
I have found that git.exe outperforms any other codebase representation with GPT5.x once you figure out how to not mangle the arguments. Commands like grep and log can replace a lot of other tools if you can use them reliably.
Git is a particularly egregious one, imo. It has a simple cli and solves all of the problems presented here! Worktrees for "exploratory" work that you might throwaway, and otherwise atomic commits just make tracking changes and reasoning for changes easy.
I dont want "agent-native CLIs" to proliferate because I'd rather we design CLIs for human use and programmatic (automation) use first. Agents are good at vomiting json between tool calls, I am not, and never will be.
Too many tools stray so wildly from UNIX principles. If we design for agents first we will likely see more and more of this.
I would naively suppose that the agent is able to read the man page or run the help command of the tool. They usually contain plenty of information. But bending the tool to suit the agent has some value. The GNU-AI suite of userland tools? Unfortunately it's possible that every model will settle on a different average. If that's the case we can't bend to every model. Models will have to bend to whatever we want to use.
Of course it can read the man page and run cmd --help.
Now you've wasted context on, what? Learning how to use the tool. And it will waste context on it every single time. (You can write skills to mitigate this a bit, but still).
The alternative is to make the tool work as the user (an LLM in this case) expects it to work, without having to resort to the manual.
If the parameter names mostly standardize across tools because the models learn to predict those names, then humans will also learn to predict those flag names so this actually has the potential to make tools more human friendly and easier to learn.
> Let the Agent use the CLI and if it guesses the wrong option, you make that the RIGHT option
This sounds backwards and presumes that the statistics machines which are LLMs are getting it right when they "average" out to the wrong command. No, fix the agents behavior, dont change the CLI to accommodate it.
the real solution is to simply provide hints in responses so that the model may self-correct, e.g., recommended next actions, describe commands to get schema definitions, etc.
I don’t remember exactly the specific examples off the top of my head (some are definitely ffmpeg commands) but I do know that when LLMs keep hallucinating command line flags that don’t exist for that specific command their “suggestion” is actually very reasonable and so many developers are adding support to their tools for common hallucinations.
Not to belabor my point, but I think "adding support to tools for common hallucinations" is a bad idea. Sounds like something a vibecoded project being spammed with issues by agents might do. Not so much a serious, mature project, though.
Well we will have to agree to disagree because my understanding of what has been generally the case is that the LLMs might vibe-coding spam, that’s true, but the interesting difference is generally speaking their “suggestions” are very reasonable and represent in hindsight useful changes that make the commands more useful for everyone, humans included.
If an option exists but it's got a poorly named flag, adding a flag alias is probably a good idea for usability in general. Most CLI tools probably don't report telemetry about failed executions, though, cuz that would be very creepy.
It’s also likely that agents would also be better if they didn’t deal with json vomit either. I’m optimistic that agent frameworks will eventually come full circle and realize concise teletype linear CLIs aka old school UNIX is actually very effective and efficient for agents as well as humans!
2 questions. First, how does a vibe coded / generated fork or derivation pose security risks to the original work? Second, what is a "more appropriate channel" to express his opinions than the platform he has as a maintainer of a massively popular project?
I would argue that we don't see enough open source developers presenting their political or social views in the context of their works.
The security risk is I Google for "notepad++ Mac", because I have a Mac, and get malware served up to me.
The appropriate channel for other people to voice their politics is anywhere else, so that ASalazarMX doesn't have interact with it and gets to pretend everything's okay.
Since you answered the first question, I'll answer the second according to my original intent.
The appropriate channel for voicing politics and ideology would be my personal accounts, not a software utility. Would you enjoy if your generous neighbor offered to mow your lawn for free, but left political messages on it?
I've rarely contributed to, or released something open source, but I know it's unprofessional to mix personal and work subjects, and open source is work, even if you do it for free.
And to counter the visibility argument, I followed Don Ho on Twitter, now on BlueSky, and actually enjoy his publications even when they aren't strictly work related.
I would guess the only way to make this data available long term is by regulation. Then again, I would hope Flock is subject to FOIA already if they are collaborating with state or local law enforcement...
YC CEO funded Flock and is involved in politics to remove police regulations
To quote him responding to criticism against Flock: "You're thinking Chinese surveillance. US-based surveillance helps victims and prevents more victims."
Cameras are free speech and are a shield against property crimes and assault.
Our building complex has rampant break-ins. We've needed more cameras for years and we're only now starting to add them.
Worse, someone recently someone set fire to the roof which caused a 12-hour long debacle. Not sure what the "#-of-alarms fire" ranking it was, but several people lost their homes to months of remediation and they tore apart the roof.
Cameras would have implicated the contractor responsible (we know it was a contractor, but there were no cameras or access logs).
One theory as to why the number of violent crimes is going down in this country isn't that we just de-leaded the water and taught better conflict de-escalation, but that there are cameras and smartphones everywhere.
All of that said - camera networks in the hands of an all-powerful state are bad.
The state does not need access to these systems outside of a rigorously documented system with proper judicial oversight. We need regulations and even civil liberties that limit the scope of state access and state dragnets to these camera networks.
But individuals, companies, and communities should be at liberty to hire surveillance tech to protect their persons and their property.
> Cameras are free speech... individuals, companies, and communities should be at liberty to hire surveillance tech to protect their persons and their property.
At scale, corporate surveillance can effectively intermingle with, and/or become indistinguishable from, state surveillance. We see that happening today: why wiretap when Palantir exists?
Cameras may be speech, but surveillance has a chilling effect against it.
I think this is a false dichotomy. You can feel and be more protected against crime while also being exploited for your data by a shadowy camera company. We should let the state step in to regulate Flock et al, assuming we can do something about the corruption they're already involved in.
The same one that I make when I stand somewhere and describe what I see. So I hold a camera to do it more accurately. And then I get tired so I mount the camera on a trip setup instead.
ACLU of IL v. Alvarez (2012): "The act of making an audio or audiovisual recording is necessarily included within the First Amendment’s guarantee of speech and press rights as a corollary of the right to disseminate the resulting recording."
Which is one of many reasons why privatizing government services probably isn't a good idea.
You could also make different laws but that's probably not going to happen. Think about just about any of the important laws that we rely on for a stable and just society in the USA, and consider that most or all of them would be politically unviable if they didn't already exist. Including FOIA itself. Not a good situation.
As far as I can tell you can theme nearly everything in the app. I've got custom colors for diffs and some syntax, and my base theme is ripped from Monokai.
#2 makes #1 a big problem. AI-generated code is fine if you have thorough engineering practices around it. Are they blindly merging in AI generated code without review? Maybe. Thats an issue of engineering practices, not of the use of generative AI in general.
So if a company self hosts their physical infrastructure which will burn down once a fire sets in, they are more "sovereign" than a company running on a redundant cloud? I definitely would not want to be "sovereign" then.
Point is: This discussion is much more multi-dimensional than some suggest.
A redundant cloud that could be rug pulled from you any day if the platform decides you are in violation of their terms, or if they just dont like your project. Yes, on prem is more sovereign than that. That doesnt mean it doesn't have drawbacks, and no one said it didnt. But if sovereignty is more important than redundancy, then on prem is certainly an option.
Yeah sorry it's marketing BS speak for self-hosted or just infra that you control. It could be a VPS, it could be a Raspberry Pi at home. Your repos live on your servers. (And we support this on Tangled today!)
But a VPS isn't actually infrastructure you control, you essentially have as much control over it as "cloud", so I don't think that'd be counted as "sovereign", would it?
reply