Ask anyone who uses Claude Code across a few languages and you'll probably hear similar feedback. It's great at TypeScript and JavaScript. Hand it a React app or a Node API and it moves fast and mostly gets it right. Hand it a C or C++ codebase and it gets shakier: things compile and then crash, or a fix works on one machine and not another, and you spend more time checking its work.
The benchmark says it's the opposite
The most direct test I know of is Multi-SWE-bench, from ByteDance's Seed team. It takes 1,632 real, human-checked GitHub issues across seven languages and asks AI agents to fix them. The best result in the paper came from Claude 3.7 Sonnet, and its fix rates look like this:
- C++: 14.73 percent
- C: 8.59 percent
- JavaScript: 5.06 percent
- TypeScript: 2.23 percent
For comparison, the same setup scored 52.20 percent on Python. So on this test, Claude did better at C and C++ than at TypeScript and JavaScript. The authors say directly that "TS and JS consistently yield the lowest resolved rates, highlighting the difficulty LLMs face in handling their event-driven, asynchronous programming paradigms."
Caveat here: Claude 3.7 Sonnet is a 2025 model, several generations behind what Claude Code runs today. And the benchmark is about fixing bugs in large, unfamiliar open-source projects, which is a different job from building a new app. Still, it's enough to rule out the simple version of the story, where Claude just knows TypeScript better.
TypeScript tells Claude when it's wrong
What TypeScript really has going for it is a fast, loud feedback loop. When Claude writes a function with the wrong type, the compiler says so in seconds, and Claude Code reads the error and fixes it before you ever see the mistake. GitHub's 2025 Octoverse report makes the same point: "Type systems reduce ambiguity and catch LLM errors before production." It also cites a 2025 study that found "94% of LLM-generated compilation errors were type-check failures," which is exactly the class of mistake TypeScript catches for free.
That loop is a big part of why TypeScript took off alongside AI coding. According to the same report, "August 2025 marks the first time TypeScript emerged as the most used language on GitHub, surpassing Python by ~42k contributors."
Most people building with Claude Code in TypeScript are making web apps: forms, pages, API routes, database calls. That code is full of patterns the model has seen countless times, and when something breaks it usually breaks visibly, in the browser or the test output. Claude gets corrected quickly, so it looks smart.
C and C++ let mistakes through quietly
C and C++ are the opposite. Code can compile cleanly, run, pass a quick check, and still be wrong. A pointer used after its memory is freed, a write one byte past the end of a buffer, an integer that overflows: these often don't fail on the spot. They show up later, on another machine, or only under load. Chromium's security team reports that "around 70% of our high severity security bugs are memory unsafety problems (that is, mistakes with C/C++ pointers)," and that's from a huge, heavily tested C++ project with its own security team.
The Multi-SWE-bench authors name the rest of the friction: "manual memory management, complex build systems, and intricate type systems." A C++ project might need a specific compiler, a build tool like CMake, system libraries, and flags that differ between Linux, macOS, and Windows. Claude can get all of that right in the code and still trip over the environment.
So the model may not be worse at C++ at all. The language just gives it, and you, fewer chances to notice a mistake before it matters. And if you can't read C++ well yourself, you lose the last line of defense, which is being able to read what it wrote.
How to make Claude better at C and C++
The fix is to give C and C++ the feedback loop TypeScript gets for free:
- Make warnings fatal. Build with
-Wall -Wextra -Werrorso the compiler refuses code it has doubts about, and Claude has to deal with it. - Turn on sanitizers while you develop. Building with
-fsanitize=address,undefinedin GCC or Clang makes many memory and undefined-behavior bugs crash immediately with a clear report, instead of hiding. - Write tests first, and have Claude run them. A test suite is the only way Claude Code can check its own work on logic the compiler can't see.
- Put the build in your CLAUDE.md. The exact configure, build, and test commands, plus which compiler and platform you're on, so Claude isn't guessing at your toolchain.
- Keep changes small. One function at a time, built and tested, is much easier to verify than a large refactor.
None of this makes C++ as forgiving as TypeScript. It does turn a lot of silent mistakes into loud ones, which is the thing that made TypeScript feel easy in the first place. And it's the same reason spotting a confident wrong answer is easier in some languages than others.
Sources
Multi-SWE-bench: A Multilingual Benchmark for Issue Resolving (ByteDance Seed) - The 1,632-instance benchmark across seven languages, the per-language resolved rates for Claude 3.7 Sonnet with MopenHands including C++ 14.73 percent, C 8.59 percent, JavaScript 5.06 percent, TypeScript 2.23 percent, and Python 52.20 percent, the finding that TypeScript and JavaScript yield the lowest resolved rates, and the description of manual memory management and complex build systems as sources of difficulty.
GitHub: Octoverse 2025 - TypeScript becoming the most used language on GitHub in August 2025, the statement that type systems catch LLM errors before production, and the cited finding that 94 percent of LLM-generated compilation errors were type-check failures.
The Chromium Projects: Memory safety - The finding that around 70 percent of Chromium's high-severity security bugs are memory unsafety problems involving C and C++ pointers.
