Show HN: The load-bearing vocabulary of Claude

Strange. I see both "vacuous" and "vacuously" on the list.

> "It s no " instead of "It doesn't "

The meaning is often different in these constructs. Consider: “Claude answers no questions” vs “Claude doesn’t answer questions”. The first could be a bot or a politician avoiding the substance, the second could be a broken UI or a politician cancelling the QA of a press conference.

I love this. I think you should be clearer about that - it's obvious to people who have experience doing this kind of data analysis, but a lot of people I've shown this were confused, as in "huh, load-bearing and genuinely makes sense but how'd he pick all these other words!?"

I think it should be made clear that the sorting is sort of Texas Sharpshooter-ish - the ones on top are on top because they sort that way.

The fact that load-bearing ends up on top is the proof that this works because we all know a priori that load-bearing is a Claudism.

When I say total market capture I mean in the March time frame. At that point Claude code / 4.6 was so far beyond any competition even meta abandoned their entire internal coding harness and fine tuning efforts in favor of large scale Claude code adoption. Codex was far behind, Gemini was a non entity, Chinese models hadn’t had their moment (and frankly aren’t practical to this day for enterprise work due to PRC concerns). The world was cursor, aider, and a few others with an unclear superior model. 4-6 was strikingly better - if could develop autonomously from a spec to done with generally high quality and didn’t require turn by turn guidance. In my 35 years I’ve never seen such a rapid pivot across so many companies and individuals.

Since then Anthropic has done little to capitalize on the good will and a lot to squander it. sol, r4, kimi, even metas avacado has come a long way and in many, if not most, cases surpassed opus-5. Concurrently opus has declined in utility to the point of near uselessness, fable roll out didn’t seem to understand market dynamics, and their competitors are watching their consistent missteps closely. The fall has been breathtakingly fast - from March to July they imploded in a half dozen or more missteps, devolved their product quality, and failed to effectively respond to competitors. Their product focus seems to lack exactly that - focus.

Many things in life are about risk and tradeoffs.

In some cases, I do not trust it to write code unchecked, and review everything it produces (which does not imply I catch all bugs, obviously).

In other cases, occasional failure is an option, and the speed you get by iterating fast is absolutely worth not even looking at the code.

So, do I trust this to write working code? Sometimes I do.

If I'm doing work for a client, it is not very common for me to simply vibe code something, because part of what clients expect of me is high quality (it's part of how we position ourselves), and I cannot simply assume the LLM will produce high quality (and indeed it does not without a lot of guidance). When I do vibecode in such cases, I make it clear that I did so and why (e.g. because it's a tool to be used in the project to help DX, not a core part of the product). Still, I haven't written 10 consecutive manual lines of code in almost a year.

If I'm working on something for myself, or on an internal product, then vibe coding is absolutely allowed and sometimes the norm. Here often we really do care about finding the right thing to build first.

You can clearly feel the tipping point where the LLM starts to crumble under the weight of the mess it has created, but that often doesn't matter when building an MVP for market validation or for small products that don't get particularly big. Plus, clearly the tipping point takes longer to reach with better and smarter models, and to me it is very clear that you need to learn how to iterate with LLMs right. The things I vibe-code now are much better than those I did before, even with similar models, because the tooling and approaches (the "real harness" and my "mental harness") are better. As with any tool: it takes practice to know how to use it, and if you're a good engineer and problem solver, you are miles ahead of the competition. Anyone can vibecode, but those with this kind of mind seem to be much more successful.

Nowadays I do produce a lot more than I used to, but I also have much more fun, perhaps only surpassed by when I learned how to code when I was a kid. A big chunk of this comes from my very privileged work position, where I get to call so many of the shots, and I'm aware of that.

I would really say the biggest downside to all of this, on a personal level, is exactly what I shared: what comes out of the LLM while discussing has become hard to grasp (especially on larger context windows), and it doesn't help that so many people now like to just throw me whatever ChatGPT/Claude wrote verbatim. I can't stand that, especially because most of the time they don't realize they're throwing me incomplete and poorly thought-out ideas.

Finally, naturally, like I said, this has to do with risk. I wouldn't trust Claude to give me legal advice, for example. I may check what it says and use it to brainstorm, but I wouldn't trust it with any meaningful informed decision like this.