Hacker News Reader

Comment by mrweasel | Hacker News Reader

Can someone explain why this would even be needed? Why is there a cost to generating say an UUIDv4? E.g. Claude Code has some regex in the client side code that filters out "bad words", so why can't the agent just generate UUIDs client side, using zero tokens.

I sort of get the "problem", but the fact that this is even needed is stupid.

View on HN

Yeah, it doesn’t make a whole lot of sense. Over hundreds of hours of Claude Code use, I’ve never had this problem.

I feel like people just jam poorly specified input into LLMs and hope for the best. Then pile more tools on top when they don’t get what they want.

> I feel like people just jam poorly specified input into LLMs and hope for the best. Then pile more tools on top when they don’t get what they want.

People call this exact process "vibe coding".

It's not that there's a cost to generating them -- per say. I wouldn't want an LLM generating UUIDs anyways. I think it's the cost of consuming them in conversation context that is the issue.

The problem is really more getting the agent to reliable relay a UUID. For example, we were creating files for visualizations and having the agent reference them in there response with a custom <visualization file=UUID /> and found that it would often fail to accurately return a UUID from a tool response it was previously provided (running sonnet 4.6).

For this use case, our solution was just to use a slug for the filename, but we can control the uniqueness constraint on our backend.

Except that we don't yet know what would need in all cases, this seems like something that should be provided by the environment.

It feels much like the random number generators in your operating system. The OS is responsible for providing applications with a source of entropy. In the same line of thinking maybe IDEs, agent frameworks, whatever you want to call it, should be responsible for providing some base functionality.

Not sure I understand. If you generate a random string to use as a reference for something that the LLM interacts with... and the LLM cannot reliably recall the reference, then it's a problem that needs to be solved by simplify the random string.

This might be my understanding that's wrong, but I assumed that the LLM itself actually can't produce like a UUID, but it can "predict" one, hence why it sometimes hallucinate IDs. So my thinking was, strip that bit out of the AI prompt and output and leave it to the "wrapper" e.g. Claude Code or your IDE to insert the actual ID.

So in the same way that your crypto library don't have its own randomness generator (ideally) and rely on the operating system to provide an API, the agents would rely on their "operating shell" / IDE / application to provide functionality that lies outside the score of an LLM.

I haven't encountered this exact problem but I have had LLMs make occasional transcription errors when "copying" hex strings around (e.g. cryptographic constants). They make surprisingly human-like mistakes e.g. a transposed pair of digits, which can be annoying to track down.

But this seems orthogonal to token usage, and if I was designing an "LLM-friendly UUID" it would have some additional checksum data, to detect transcription errors.

I thought the same thing, and was wondering if this wouldn't even cause more drift and hallucination as these tokens will have stronger relations within the model as opposed to the UUIDv4 that probably gets dropped as noise (correctly so).

Honestly same question LMAOO its like Tween all again

the machines this is designed for are stupid. this makes them less stupid. do not anthropomorphize.

I can see this being useful when feeding raw table dump csvs into models, isomorphism means it's a simple pre-post processing step which could give you a cheap decrease of tokens and increase in accuracy.

You wrote a lot of things, but said nothing.

I guess you’re another bot

Looks like it ;)

Reply on news.ycombinator.com