- “(The) honest caveat:” (or “genuine caveat:”, both with the colon)
- “(The) honest answer:” (again, with colon)
- “The thing to internalize:”
- “The smoking gun:”
(really, sentences that start with “The <tag suggesting the next clause is the key point>:” are a strong tell, but those four are the most prolific)
- “load bearing” (when not talking about architecture)
- “blast radius” (when not talking about actual explosives, but rather the effect of an event/action)
- “smoke test” (esp. when “sanity check” is more apropos)
- Lists of three clauses/adjectives where the third is really just a combination of the first two
- Referring to the “shape” of things figuratively
- Social media posts that end with “Curious if anyone…”
- Stories or anecdotes using. “Oh. Oh.” (where the second “oh” is italicized)
Edit: Yes, some of those last ones are terms that we often use as devs...but I would argue about the actual frequency of their use. Plus, these tells live on in prose generated by the latest models.
These LLM idioms are constantly being consumed every day and are bound to make it into the next, if not current, generation's vernacular. It's going to be unbearable.
> I would argue about the actual frequency of their use
Assuming you mean load bearing & blast radius, I'd see those used and use them myself very frequently pre LLM, mostly in online discussions though so its telling where they got their training data. Load bearing itself is/was a pretty normal phrase in the ops world in daily discussion.
Smoke test though, I can't say I've ever see irl usage.
> Smoke test though, I can't say I've ever see irl usage.
We use it all the time at my employer, and have for decades. They're basic tests to tell you if the app is up or not.
Like: you go to this page, and it shows a big green banner if the app can connect to the database and its disk isn't full. If one of those basic things are wrong you get big red banner or you can't load the page at all.
Can't remember when I first heard it, but I searched my email and got a pile of results from 2012 and 2009. It's possible there's earlier in there somewhere but 2009 was a busy year so I got bored of clicking the "more results" button...
The funniest one I've seen with regularity is belt-and-suspenders/belt-and-braces, when I've never seen anyone ever use that term. I had to tell AI to stop using it, it was just annoying.
Everything is an escape hatch, try catch is an escape hatch, a cli flag is an escape hatch. It makes no sense, and quickly ended up in my “banned words and phrases” md file
Which seems logical - if they were somehow consistent between all LLMs i'd be even more curious how LLMs are... crab-evolving to 'isms, but hopefully that's not the case hah. (i say crab-evolving in jest)
I use qwen3.5 locally and it often outputs a lot of claude-isms. Claude actually stopped telling me that I'm absolutely right with every message, but Qwen still does.
I think that the convergence of these tics is just a symptom of distillation.
I routinely use "load bearing" in conversations and writing, both seriously and ironically (like a "load bearing just" or "load bearing paint").. maybe I should stop.
Considering that LLMs output continuously becomes more human-sounding (by design), you’d either have to continuously run what you write through various detectors and keep changing it or you must resign to inevitably be called an LLM at some point.
Simultaneously, because humans subconsciously mimic what we see, we also converge to sound more LLM-ish.
The harsh reality is that no matter what you write and how much research you put into it—especially if you try to be legible to others and not make grammatical mistakes—someone could discount all that and claim you just prompted an LLM. If they want, they can always find some magic “AI checker” that will return a high enough probability. We all know that with a good enough prompt and with round-trip validation against a checker (there are definitely products with this all built in) it will avoid the common tells, it’s just the matter of a few extra tokens.
I wonder, could we use these catch phrases to track down what data was used dor training? They must have occurred in abundance in some training corpus. Perhaps some specific company's email culture?
This stuff reminds me of the classic writing style guide Plain Words by Gowers which advises against all of the above nonsense. I absolutely hate the magazine writing style that LLMs seem to love to regurgitate. It's even worse when it's used not for entertainment but for actually conveying information.
It’s just still so trivial to jailbreak even the latest Anthropic models (via api, and not talking about the silly ENI or Pliny breaks) I don’t understand where the safety teams are doing their work. Is it in the default chat-trained model?
It's more of a research program than a product feature. No-one knows how to fully prevent a model from responding based on what's in its base training data, which is what you're seeing with jailbreaks.
And going to one of the roots of the issue - the base training data - comes with its own set of unsolved challenges, not least of which is the unavoidable subjectivity of what is or isn't "safe".
CarPlay is essentially a conditional pair of video inputs. Any system that supports on-screen rear-view camera and that has a wheel speed sensor can support CarPlay.
What do you really need? Is the car moving forward or backward is the only one you can't figure out from GPS on the phone (this is possibly what they are getting from wheel speed - GPS speed is more accurate if you have a signal).
There are a lot of nice to haves of course. GPS does eat phone battery so better if the car can give you that. There is a lot of other car data that is interesting, why force plugging a OBDII dongle in to get DTCs, RPM, O2 sensor values, or whatever. However for car play to work at all it doesn't need anything more.
Nav apps on phones will use dead-reckoning if they don't have a GPS signal, so they don't really even need the wheel-speed sensor, but I'd guess they use it just to increase accuracy.. e.g. in a long tunnel.
Increasing accuracy is a wild understatement. Dead reckoning with mobile phone hardware won't give you a usable result for long. Maybe your experiences are from tunnels with dedicated beacons to tell the phone where you are.
Most vehicular tunnels aren't too terribly long, if you're stuck in one in traffic, yeah dead reckoning drifts quite a bit. But if you're driving through one for a minute or two, it's sufficient.
On a side note I've personally had bad experience with beacons in train tunnels telling me I'm miles away from where I'm actually at.
Well done! I’ve built this same sort of thing for my family to play with. My advice for the best results:
1) Structure the choices offered by the LLM; add “choice_type” and add instructions to the LLM on what those choices should do. E.g. action, dialogue, investigation, whatever makes sense for the genre—the LLM can even generate these at story start—then “choice should direct the narrator to focus on an action-oriented moment”, “choice should direct the narrator to focus on a dialogue between two or more characters in the scene”, etc.
2) Use reasoning whenever making tool calls for choices, summarize the reasoning, and include it in narrative summaries provided as part of the context for future narrative requests. For example, the combined summary might be: “In the last narrative I wrote for the user, Harry and Luna were startled by the noise coming from the edge of the forest. Important scene developments: 1) Luna and Harry had been approaching the edge of the forbidden forest for the last three narrative turns, and in the turn I just wrote they arrived at the edge. 2) Harry seemed to be the more courageous of the two in previous narrative turns, but in the most recent one, the user’s choice resulted in Harry becoming more deferential to Luna. 3) In the most recent narrative turn, the noise that had been emanating from the forest was now accompanied by a flickering light. I then suggested paths that would allow for character development through dialogue between Harry and Luna (I gave two options here), a path to move the story forward by having Harry take Luna’s hand before running into the forest, and another path that would slow the pace by having Luna investigate the flickering light accompanying the sound. The user’s choice: ‘Have Luna investigate the flickering light.’
3) Add an RNG weighted by story length or whatever works for you that will result in choices that lead the story to a conclusion. Include that direction in the tool call for generating choices, along with a countdown to the finale choice.
This is a rough mental sketch of what worked the best for me, i purposefully left out implementation or application details, as I don’t know what you’re wanting to do next.
How do you come up with this? I feel it is quite hard to formulate exactly what you want from the LLM in general. Is this something you exercised? So good. Or just output from another AI, who knows haha
My answer to this in my own pet project is to mask terms found by the NER pipeline from being corrected, replacing them with their entity type as a special token (e.g. [male person] or [commercial entity]). That alone dramatically improved grammar/spelling correction, especially because the grammatical "gist" of those masked words is preserved in the text presented to the LLM for "correction".
Exercise vigilance regarding copycat or coat-tailing sites that seek to exploit the project's popularity for potentially malicious purposes. It is imperative to rely solely on information from https://Helper-Scripts.com/ or https://tteck.github.io/Proxmox/ for accurate and trustworthy content.
One note: For truly "responsive" text (and other measures, like padding/margins), I often use relative units of measurement. At the very least, rem/em, but more and more I'm using viewport¹ (including dynamic) and container query² units. I'm not your target market, and I know that owning the renderer makes this request more complex that it would seem, but I thought I'd point it out just in case you think it should be on your radar.
This is something we are going to add for sure. Ideally, we will support any unit (em, rem, %) you can use in CSS for any property we expose like padding or font-size.
- “(The) honest answer:” (again, with colon)
- “The thing to internalize:”
- “The smoking gun:”
(really, sentences that start with “The <tag suggesting the next clause is the key point>:” are a strong tell, but those four are the most prolific)
- “load bearing” (when not talking about architecture)
- “blast radius” (when not talking about actual explosives, but rather the effect of an event/action)
- “smoke test” (esp. when “sanity check” is more apropos)
- Lists of three clauses/adjectives where the third is really just a combination of the first two
- Referring to the “shape” of things figuratively
- Social media posts that end with “Curious if anyone…”
- Stories or anecdotes using. “Oh. Oh.” (where the second “oh” is italicized)
Edit: Yes, some of those last ones are terms that we often use as devs...but I would argue about the actual frequency of their use. Plus, these tells live on in prose generated by the latest models.
reply