Google Can Keep Its Chrome Browser but Will Be Barred From Exclusive Contracts

The reason you hire a structural engineer is because they do - and they are on the hook if it goes wrong. Which is also why they have to stamp drawings, etc.

Because the next person who owns the house should have some idea who was screwing with the structure of it.

You might be 100% on top of it - in which case that structural engineer should have no problem stamping your calcs eh?

This might not quite be true, strictly speaking, but a very similar statement definitely is. LLMs are highly prone to hallucinations, a term you've probably heard a lot in this context. One reason for this is that they are trained to predict the next word in a sequence. In this game, it's almost always better to guess than to output 'I'm not sure,' when you might be wrong. LLMs therefore don't really build up a model of the limits of their own 'knowledge,' they just guess until their guesses get better.

These hallucinations are often hard to catch, in part because the LLM will sound confident regardless of whether it is hallucinating or not. It's this tendency that makes me nervous about your use case. I asked an LLM about world energy consumption recently, and when it couldn't find an answer online in the units I asked for, it just gave a number from a website and changed (not converted) the units. I almost missed it, because the source website had the number!

Stepping back, I actually agree that you can learn new things like this from LLMs, but you either need to be able to verify the output or the stakes need to be low enough that it doesn't matter if you can't. In this case, even if you can verify the math, can you be sure that it's doing the right calculation in the right way? Did it point out the common mistakes that beginners make? Did it notice that you're attaching the support beam incorrectly?

Chances are, you've built everything correctly and it will be fine. But the chances of a mistake are clearly much higher than if you talked to an experienced human (professional or otherwise).

Do you have a few examples? I'm curious because I have a very sensitive BS detector. In fact, just about anyone asking for examples, like the GP, has a sensitive BS detector.

I want to compare the complexity of my questions to the complexity of yours. Here's my most recent one, the answer to which I am fully capable of determining the level of BS:

    I want to parse markdown into a structure. Leaving aside the actual structure for now, give me a exhaustive list of markdown syntax that I would need to parse.

I responded with:

    I am seeing some problems here with the parsing: 1. Newlines are significant in some places but not others. 2. There are some ambiguities (for example, nested lists which may result in more than four spaces at the deepest level can be interpreted as either nested lists or a code block) 3. Autolinks are also ambiguous - how can we know that the tag is an autolink and not HTML which must be passed through? There are more issues. Please expand on how they must be resolved. How do current parsers resolve the issues?

That's also what Grok says:

> Is there a constant time string comparison algorithm in the JRE?

No, the Java Runtime Environment (JRE) does not provide a built-in constant-time comparison method directly for String objects in the standard library. The String.equals() and String.equalsIgnoreCase() methods perform variable-time comparisons that short-circuit upon finding the first mismatch, which can be vulnerable to timing attacks in security-sensitive contexts like password or token verification. However, the JRE does include a constant-time comparison utility for byte arrays via java.security.MessageDigest.isEqual(byte[] digesta, byte[] digestb), introduced in Java 6 and documented as performing a comparison where "the calculation time depends only on the length of digesta [and] does not depend on the ... contents." This makes it suitable for secure comparisons against timing side-channel attacks. To use it for strings:

Convert both strings to byte arrays using a consistent encoding (e.g., UTF-8 via getBytes("UTF-8")). Ensure the byte arrays have the same length first (as the method requires equal-length inputs for meaningful results). Call MessageDigest.isEqual() on the arrays.