saurik

I don't see how being a hobby site makes it more sustainable to have crawlers making insane numbers of constant requests to your server for seemingly no good reason? If what used to be a website you could host for some small number of people who cared scaled well now it is a hundred times more expensive to run.

> I didn't find anyone claiming that two questions are duplicate of one another in different programming languages unless the language is not relevant.

I am honestly at a loss here as to how you are not seeing this is a very different claim, and so am now also on the theory that this is some kind of performance art to reenact the frustration of someone claiming a question that is different is in fact some kind of duplicate content.

Again, this claim was made by a different user in a different branch of discussion off of this post, but it wasn't made by that user or even within this thread: Bratmon makes absolutely no claim about people crossing programming languages for marking duplicates. (I am done, though: feel free to now have the last word.)

(Not sure you'll see this, ofc.) After percolating on this for a couple days, is retrying the tool calls enough? Maybe the reason the tool call is requiring three retries is because the AI simply got locked into too difficult of a way to solve the problem, and if it retried the entire response it would have gone in a different direction entirely. How far back do we feel comfortable?

I would expect that, if you turned off the feature where they can use your data, that they would remove those features, so you don't either accidentally click them or fail to understand that it isn't some kind of local-to-your-account mechanism.

Right... and I said exactly that in both my comments, but I was looking for confirmation that that's the issue being stared at, as it wasn't obvious to me that's what was meant and (I will cite as demonstration of the confusion) now people are bringing up other ideas (such as field order, which is an entirely unrelated constraint). (FWIW, since you are the person I was originally asking, I will take this as positive confirmation that "yes: I am saying it is better to retry the entire tool call" ;P.)

I guess to be more concrete, I thought the way schema aware decoding worked should be identical to a token-level retry: "only even dice rolls are allowed" converting {0:0.1, 1:0.2, 2:0.2, 3:0.1, 4:0.2, 5:0.2} into {0:0.2, 2:0.4, 4:0.4}. That is why I am asking if the difference being stared at is doing the retry at the level of the entire tool call rather than each token (as this let's later errors in the schema re-roll the earlier committed states)? (But like, it isn't clear to me that's what they mean, so I feel a need to ask; as an example, you are now talking about field order, but that's an entirely different issue involving an overly-constrained constraint: nothing would prevent implementing the grammar for the constrained decoding to allow the fields in any order, and if you allow duplicate fields -- which JSON typically allows anyway -- then it is probably already supported as the language loses its additional context requirement.)

Is the schema constraint not implemented in a way where the new distribution is identically scaled to the old distribution with retry? I had thought the way it worked was just to disallow invalid next states... oh, or is the idea that you think it is much preferred to retry at the level of the entire tool call, rather than (conceptually) per token? I guess I can see that making a lot of sense, as maybe the model gets "backed into a corner", so to speak, with a really bad initial choice and is then trying to rescue horrible states?

Why do you believe that having an AI read my code and port it into your code base is "legal now"? Let's call that question A. This is a very different question from B whether it is legal to train a model on my code, which is also still a different question from C whether it is legal to use the model you trained on my code to generate code that is in any way similar to my code into your codebase.

As far as I know, A is still illegal, and nothing at all has changed that situation; if it did, it would be shocking, as it essentially undermines the entire legal framework of copyright, and it would be making national news and destroying -- not harming: entirely wiping out -- major software companies.

The only thing I think people have really litigated in the courts is B (as the obvious defendant is the juicy maker of the model rather than the users of the model, whereas they might be able to dodge culpability in C and even A), with the result that it is very likely legal... but, while that might be a bit frustrating, it was never shocking: a model is a highly transformative use case vs. the original code fed into the training.

However... B being legal doesn't actually imply that C is legal -- even if a ton of people fail to appreciate this distinction -- and C is where the war is starting to be fought. Instead of software, I think the most interesting avenue for this to become scary for people assuming this is legal will come from lawsuits involving the music industry (which tended to lead the pro-copyright cause in many of the skirmishes I was involved in while working on device freedom issues).

That said, people really focus too much on C, hoping for that grey area in both the law and in their analogies, when what developers are actually doing now is often A: the model has become an agent that uses tools, has access to the Internet, pulls code off my got repository, and is essentially just running a non-deterministic transform on that data sitting in its context... I have heard nothing that makes it sound as if A is "legal now".

1) I really wasn't talking about an editor at all: I was talking about the libraries and frameworks you use to program, so that the way you interact with the problem space is the way you think. I mean, even as someone who has almost exclusively used vim for the past 25 years of coding, if I went back to the prior 10 years before THAT of using Visual Studio, I'd have described this no differently.

2) In fact I have never used off-the-shelf coding assistants (Claude Code, etc.) and have only used my own harness; yet to me the issue is that the model itself often likes to think about problems in ways I find frustrating and unhelpful. The issue isn't at the level of how diffs are applied (that's commodity) or how context is managed (I can fix that) but in how problems are described, how abstractions are managed, and the language used to discuss them.

Yeah: in a world where I am coding, I can put in the effort to make the software work the way I think... to use an LLM, I largely have to think the way it wants to work / converse.

The entire concept of copyleft and free software depended on copyright: it isn't "take my code and do what you will", it is "here is a very explicit contract that demands you credit my work and even requires you to contribute back in return for my efforts". And like, maybe a world with no copyright at all is better! But that isn't the world we are in: it is no more legal for you to have an AI read my code and then port it into your codebase (which could involve training as an intermediate step or could merely involve the AI searching for it and loading it into its context) than would be for you to directly read my code and port it into your codebase or even for you to utilize a deterministic tool to read my code and port it into your codebase; you only get to do those things if you retain my license on the result and abide by its terms.

FWIW, many of us who do open source would also find that hypothetical world in which the idea of copyright is abolished rather enticing... but you pretending that is this current world whenever you want to steal our code whilst copyright still paints our interests in using and altering the code from companies that have always been in fear of our community and our licenses (Apple, Microsoft, etc.) as theft is not merely a bit shitty... it is kind of evil/cruel.

This position is trivially incorrect as it makes the entire concept of a login shell impossible in the first place, as you have just described the regime in which login, su, and even basic tools like ping (which have the permission to use raw sockets and write ICMP even though we would never let any of its parents do so) operate.

Terminal (and sshd) are special, in that they actually do end up with inherent transitive permission to their immediate intended child processes, as those children are nigh-unto universally (due to the entire idea of what terminals do) designed to be operated using text written to their input, which Terminal (and sshd) can man-in-the-middle.

But like, that doesn't generalize: it certainly (and obviously) is the case that I can have a process that is allowed to write files to disk that I would be happy to let you run even if I do not trust you to write to even those same files (as you will corrupt them), much less any file on my disk, as I merely need to trust that application to not give you the ability to do arbitrary writes.

The better idea here is that processes are their own form of encapsulation, and just because they can do something doesn't mean that they expose that functionality. You thereby must limit what tools can be used by a parent -- so almost no one gets a generic "exec" permission: you get a whitelist of tools and arguments you can utilize -- but the result doesn't look much at all like the permissions on subprocesses needing be a subset of the parent.

I think part of the problem -- answering all of why people are somehow OK with this, and even why the AI does this in the first place -- is that the majority of software developers never got to the point of understanding any of this: the lack of understanding how to carefully structure data surrounds a question they don't even know how to pose, much less answer, and so "write some tests then incrementally try to make them work without breaking any of the existing tests" is the only way they know how to develop at all. In the end, that means that, with the current state of the art (which might change, of course... potentially quickly), your strategy of treating the AI as a junior engineer who fundamentally isn't ready to do your senior-level architecture job makes a lot of sense.

Reducing access to a weapon/tool behind any variety of roadblocks because you think the weapon/tool is dangerous is not the same as shifting blame off of the person who did the crime. Saying we don't want people to be able to buy guns without limitations or even saying people should not be allowed to make or sell certain kinds of weapons/tools is not the same thing as saying the person who jumped through the hoops (or ducked underneath them) is not liable for the crime they committed using the weapon/tool. It is certainly the case that no one, at the end of the day, claims the gun is to blame for the murder a human carries out with it... some people will claim maybe the humans making or selling the gun share some blame, but it would be a fundamental attribution error to blame the gun itself.