Posted by shintoist 12 hours ago
"Critical path" and "long pole in tent" didn't make it into the model training data, but those were certainly also in play incessantly.
But they're all reasonably useful descriptions for common things, so I'm not surprised.
"The current behavior paper" -> The behavior in the running system that was previously described as papered over.
"Marker transport over-claim" -> The inaccurate review finding on the object's sentinel flag in the API response.
I suppose the cryptic/invented language problem is about token efficiency? But this sort of token efficiency is extremely difficult to deal with when it comes to conversation with a human about complex system. It might be efficient inside reasoning blocks, but when the model generates the final turn text, it should avoid this, as it's brutally inefficient due to the time spent wondering what each uniquely coined phrase means and having to ask for constant clarifications, which then you have to wait for another turn, eating up time and context while it burns more xhigh reasoning just thinking about how to explain its own awful language.
Want me to take a first pass looking at other surfaces this vocabulary change could effect? Or would you like me to find other methods of reducing my vernacular to more terms that are more concise rather than verbose.
For those who care to read everything rather than walk away, Fable can be extraordinarily dense. I suspect they'll pull the promo before I learn to read it.
Still, I feel I must read rather than correct it, as results are that much better if I let it do this "with" itself: orchestrator to agents back to orchestrator.
You can also ask fable/4.8 to do it but I find it helps to keep the working model surrounded by the complexity rather than drawing it out. Simplifying text is something that takes relatively low effort in comparison to technical tasks. Sometimes I use Gemini, deepseek, grok, and recently meta just to see if they have any added perspectives, sometimes they do. Meta is really good at turning a technical mess into a story that paints a picture in my head.
I think Claude means something like map-reduced or at least a functionally derived series of some kind?
Anything with series data sounds like a laundromat.
...
Want me to take a first pass looking at other surfaces this vocabulary change could effect?
The thing is, "load-bearing" is a useful phrase when discussing architecture. What would you rather have it say, that has all the same nuances in as few words?
It's kind of like those sports metaphors that often get used in management-speak, like sending some important email "at close of play". Sure, they can sound a bit weird, but they're often useful -- they capture common concepts in a clear and pithy way.
Jargon isn't always just for obfuscation, good jargon exists because we needed a short word for the complicated thing that frequently comes up.
Usefulness aside, I quite like that Claude Code and other LLMs have their own weird way of speaking. Back in the day we always imagined robots and computers would talk like HAL or Spock; turns out that they talk more like Troi instead. Is that so bad? It reminds you that you're talking to an LLM, and as long as you're not lazy, it spurs you to rephrase things in your own words.
# AI speech is an Infohazard
Apart from all its other possible boons and ills, one danger of AI is just that it is useful, so you use it. A lot.
In earlier days I would dive deeply into an author's work and start to think and write like them for a while. It was a heady feeling: slinging sonnets like Shakespeare—not at his level, but stylistically reminiscent—or tweaking turns like Twain.
Like all things, the effect lasts in relation to how long and how much you do it. The point is: our thinking is influenced by what we take in. Take more of a certain thing in, think more like that thing.
Now enter AI. My hand-crafted coding days are in their twilight months ("AI years"), and most of my software engineering is done through jaggedly capable agentic power tools. Instead of working directly with raw codestuff, I work with slop prose flecked with code sprinkles.
I read orders of magnitude more AI-speak—I call it "babble", or perhaps "Babel"—than human-written text. I can feel its genuinely honest points, clearly stated, slipping their banal tendrils into my thoughts and inner monologue.
Solutions? For me:
1. Be aware. "I notice that my thought stream is under assault."
2. Read stuff far from slop. Even a small dose of the good stuff can help inoculate. Recently I thought On the Calculation of Volume was something completely different.
3. Write stuff that is different. This post. Force the mind to synthesize thoughts in other ways.
4. debabel.py / debabel.js: a tool, and a pi extension, which filters common babble from visible LLM output. A lint for mind-killing prose.
It is not perfect, but it 80/20s nicely. I am willing to accept mildly awkward prose to avoid polluting my own internal distributions.
Details and example in the first comment. Tool available upon request.
Information hazard: https://en.wikipedia.org/wiki/Information_hazard
Babel: https://en.wikipedia.org/wiki/Tower_of_Babel
On the Calculation of Volume: https://en.wikipedia.org/wiki/On_the_Calculation_of_Volume
The revenge of NLP
The tool uses good old-fashioned regex/NLP—no LLMs—and rewrites the visible LLM Markdown without touching files on disk. I made it by analysing 10M+ words of past pi transcripts, doing frequency and pattern analysis, and iterating on rules to strip out the most egregious sloperisms. Now the circle is complete.
BEFORE
"Honestly, you're absolutely right—and that's a great question. Let me be clear: the fact that the parser works at all is actually quite remarkable. We utilize the tokenizer in order to handle the majority of edge cases, and due to the fact that it's recursive, it processes a large number of inputs. It's worth noting that this isn't really a bug—it's genuinely a deliberate design choice. In terms of raw throughput, the cache is significantly faster, and I think we should simply ship it.
That said, at the end of the day, not only is the design correct, but it is also fast. In other words, prior to refactoring, we should clearly delve into the nuanced, robust architecture. In conclusion, this is a testament to the seamless, intricate work the team has done."
AFTER
"That's a great question. That the parser works at all is remarkable. We use the tokenizer to handle most edge cases, and because it's recursive, it processes many inputs. This is a deliberate design choice. For raw throughput, the cache is faster, and we should ship it.
Not only is the design correct, but it is also fast. Before refactoring, we should delve into the nuanced, robust architecture. This is a testament to the seamless, intricate work the team has done."
("It consists in gumming together long strips of words which have already been set in order by someone else, and making the results presentable by sheer humbug" -- Orwell predicts the LLM)
and also https://www.jstor.org/stable/25515288 "The Myles na gCopaleen Catechism of Cliché" itself is rather hard to find online, but he's a very funny writer so it's worth the effort.
I was hoping for a reference to the Babel Fish, whispering its translations in your ear.