I'm surprised vacuous is not on the list. The word selection and way of writing has taken the joy out of using Claude.
Also can't believe vacuous is not there.
Show HN: The load-bearing vocabulary of Claude
51–60 of 327 posts
Re: Show HN: The load-bearing vocabulary of Claude
#52That confirms the recent spike of Claude calling everything I was recently working on a 'spike'. I still don't know what that term is supposed to represent (apparently).
In some software development methodologies, "spike" is a task whose goal is figuring something out instead of delivering shippable code. https://agiledictionary.com/209/spike/
TIL that agile has its own words for everything.
Re: Show HN: The load-bearing vocabulary of Claude
#53To all the people in the HN comments saying negative things about Claude: why don't you just use other models instead?
Re: Show HN: The load-bearing vocabulary of Claude
#54Earlier quoted context omitted.
I'm also missing the "latch" that "wedged" my test run.
At least "wedged" is a thing i would say on a spinning out of control test that is stuck. "latch" though... not so much. I really wonder if this is the EU AI Act interfering with everything Claude does these days. As a non-EU citizen, I want a version without the rewriting of with watermarking in text.
I don't think so.
I understand it's not active yet, and when it will be, it should only nudge the chances between choices that are anyway likely and are already randomized today via temperature.
Watermarking is not the reason Claude talks like that.
Re: Show HN: The load-bearing vocabulary of Claude
#55To all the people in the HN comments saying negative things about Claude: why don't you just use other models instead?
Work only allows the tools they buy. So at least for me, I am stuck with Claude. At home for personal projects I am a fan of DeepSeek v4 Flash.
Re: Show HN: The load-bearing vocabulary of Claude
#56It's a waste of tokens to do it post-hoc instead of fixing it upstream, but when I see a wall of text I just prompt "TLDR;"
Depends what you mean by "upstream". It would probably be inefficient to force the model to use more human-readable wording in its internal thinking traces, while translating a block of text at the end is a pretty trivial task for an LLM.
Re: Show HN: The load-bearing vocabulary of Claude
#57Earlier quoted context omitted.
ItMs because Claude sprinkles these words as flavoring without aiding understanding. It feels like Claude thinks of metaphors that don’t actually mean anything (or maybe only makes sense to itself).
I don't understand. Does the metaphor "load-bearing assumption" not actually mean anything to you?
It doesn't mean anything at all, since any assumption that is not 'load-bearing' is irrelevant and unlikely to be discussed at all. It's just noise.
Re: Show HN: The load-bearing vocabulary of Claude
#58I was pleasantly surprised when I attempted to scroll down and realized everything the author wanted to present fit on-screen. It's almost ironic that this site is able to make such an obvious, compelling presentation without being overly verbose or complicated (something which LLMs have a hard time doing). I wouldn't read TOO deeply into what is being presented, but the author has done a good job to not inject their…
In the enterprise, we are already adopting them. “Seam”, I term I’d never heard used before, is now not only our defacto way to describe the boundary between systems/workflows/components, it is encoded into our organizational roles and responsibilities descriptions.
I am the proud owner of several seams, and am considering giving them person-names. The empty space between my inventory APIs and their clients might be “Karen”.
I can’t say that Claude invented this; the same type of terminology cycling happens every few quarters based on what leadership is reading/being told by Gartner.
Re: Show HN: The load-bearing vocabulary of Claude
#59Things like seam, fold, and load-bearing are useful concepts, they are everywhere, and they are more descriptive and more concise than alternatives. Over-usage can definitely be irritating (e.g. these should NOT appear in documentation) but they are almost unavoidable for humans engaged in code review or colab on complex stuff.
I don't want to use more words or letters than "seam" to actually pinpoint boundary conditions and the mechanical details of joinery when the context is understood by all. Too much effort for people! Easy for robots though.. so why are they abbreviating, and why would we want to allow it? A phrase like that permits a human who wants to educate a human to do so quickly with minimal time/effort. But it allows a robot a chance to not mention a filename, function-name, or to not reinforce/clarify it's own understanding or to state specific intentions.
It's bad for human-to-human comms if we just accept "ok, all technical terms are slop now, we have rephrase everything". Now YOU must cite details and sources, and the robot doesn't? Fuck that noise. Seam and fold are fine! Humans can be lazy! Robots should do the real work of explaining themselves without hiding behind tactical ambiguities.
Re: Show HN: The load-bearing vocabulary of Claude
#60To all the people in the HN comments saying negative things about Claude: why don't you just use other models instead?
Claude is all we have at $work, if you don’t count MS Copilot (and you shouldn’t count MS Copilot).
Imagine being “incentivized” to aggressively use a tool for your job, and that tool produces thousands of lines of text in Olde English which you need. You’d be griping too, methinks.