What makes Claude Code so damn good

Oof, this comes at a hard moment in my Claude Code usage. I'm trying to have it help me debug some Elastic issues on Security Onion but after a few minutes it spits out a zillion lines of obfuscated JS and says:

  Error: kill EPERM
      at process.kill (node:internal/process/per_thread:226:13)
      at Ba2 (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19791)
      at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19664
      at Array.forEach (<anonymous>)
      at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19635
      at Array.forEach (<anonymous>)
      at Aa2 (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19607)
      at file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:19538
      at ChildProcess.W (file:///usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js:506:20023)
      at ChildProcess.emit (node:events:519:28) {
    errno: -1,
    code: 'EPERM',
    syscall: 'kill'
  }

I'm guessing one of the scripts it runs kills Node.js processes, and that inadvertantly kills Claude as well. Or maybe it feels bad that it can't solve my problem and commits suicide.

In any case, I wish it would stay alive and help me lol.

Claude and some of the edgier parts of localstack are not friends either. It's pretty okay at rust which surprised me.

It makes me think that the language/platform/architecture that is "most known" by LLMs will soon be the preferred -- sort of a homogenization of technologies by LLM usage. Because if you can be 10x as successfully vibey in, say, nodejs versus elixir or go -- well, why would you opt for those in a greenfield project at all? Particularly if you aren't a tech shop and that choice allows you to use junior coders as if they were midlevel or senior.

This mirrors a weird thought I’ve had recently. It’s not a thing I necessarily agree with, but just an idea.

I hear people say things like, “AI isn’t coming for my job because LLMs suck at [language or tech stack]!”

And I wonder, does that just mean that other stacks have an advantage? If a senior engineer with Claude Code can solve the problem in Python/TypeScript in significantly less time than you can solve it in [tech stack] then are you really safe? Maybe you still stack up well against your coworkers, but how well does your company stack up against the competition?

And then the even more distressing thought accompanies it: I don’t like the code that LLMs produce because it looks nothing like the code I write by hand. But how relevant is my handwritten code becoming in a world where I can move 5x faster with coding agents? Is this… shitty style of LLM generated code actually easier for code agents to understand?

Like I said, I don’t endorse either of these ideas. They’re just questions that make me uncomfortable because I can’t definitively answer them right now.

LLMs write python and typescript well, because of all the examples in their training data. But what if we made a new programming language whos goal was to be optimal for an LLM to generate it? Would it be closer to assembly? If we project that the future is vibe coded, and we scarcely look at the outputted code, testing, instead, that the output matches the input correctly, not looking at the code, what would that language look like?

I have thought the same thing. How is it created? is it an idea by an LLM to make the language, or a dev to create a language designed for an llm.

How do we get the LLM to gain knowledge on this new language that we have no example usage of?