AI coding agents for C++

The AI-coding-agent space saw a Cambrian explosion in 2024-2025. By May 2026 the field consolidated to roughly nine tools that own the daily-developer conversation. The May 2026 wave (Grok Build, Codex CLI v0.133, Cursor 2.5, Claude Code surface-agnostic release) pushed multi-agent and local-first patterns to the foreground. C++ adds three constraints that shift the rankings versus the generic “best agent” lists:

1. Templates and metaprogramming need long context. A reflection-heavy refactor easily spans 5-10 headers; agents with smaller windows or aggressive context truncation produce subtly wrong specialisations.
2. ABI / undefined behaviour means supervised only. Async-agent flows (“submit and review the PR”) are a poor fit. Default to pair-programming or supervised agent mode.
3. Compliance. Defence, embedded, finance, and proprietary engines often forbid cloud egress. Local-only stacks (Continue.dev or Aider + a local model) are not a fallback — they are the requirement.

Each agent below shows licence, cost, MCP support, and our verdict for C++ work specifically. Premium open-source picks are flagged below the table.

The agents

Premium-OSS picks

Two tools earn the Premium-OSS flag for C++ work: Aider and Continue.dev. Both are Apache-2.0 licensed, both work with any model (including a fully-local Ollama / vLLM endpoint), and both put you in full control of your data. Pair either with Qwen3-Coder-Next on a 24+ GB GPU (or a Jetson AGX Thor, our reference hardware) and you have a complete loop with zero data egress. See the integration recipe at Local LLM for C++.

If your shop allows cloud agents but you still want OSS for the harness: Cline and OpenAI Codex CLI both work BYOK against any model API.

AGENTS.md template for C++ projects

The AGENTS.md convention (a sibling of CLAUDE.md / cursor.rules) tells coding agents how to operate inside your repository: build commands, conventions, things to avoid. Drop this at your repo root and tweak.

# AGENTS.md

## Build
- Generate: `cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug -GNinja`
- Build:    `cmake --build build -j`
- Test:     `ctest --test-dir build --output-on-failure`
- Sanitize: rebuild with `-DCMAKE_CXX_FLAGS="-fsanitize=address,undefined"`.

## Standard / features
- C++26 (`-std=c++26`).
- Reflection enabled: clang-p2996 uses `-freflection-latest -stdlib=libc++`;
  GCC 16.1 uses `-freflection`.
- Modules NOT enabled. Headers + sources only.

## Conventions
- RAII for every owned resource; smart pointers preferred over raw owning.
- Headers in `include/<project>/`; sources in `src/`. One TU per public header.
- No exceptions in hot paths (use `std::expected`).
- All public APIs documented with Doxygen-style `///`.

## MCP servers (if your agent supports MCP)
- clangd: semantic queries, find-references, refactor.
- cmake-tools: build / configure / target-graph.
- compile-commands-reader: per-TU flags.

## Forbidden
- Do not modify `third_party/` (vendored).
- Do not edit `compile_commands.json` directly; regenerate via cmake.
- Do not commit `build/`, `*.o`, `*.so`, `compile_commands.json`.

## Review
- All PRs require sanitizer-clean CI before merge.
- ABI-affecting changes require explicit reviewer sign-off (header layout,
  virtual table layout, exported symbol set).

MCP servers worth wiring

The Model Context Protocol is now ubiquitous (over 10,000 public MCP servers as of Q1 2026). For C++ work the high-leverage ones are:

• clangd (semantic engine) — exposes find-references, go-to-definition, rename, semantic-token queries. Wire your agent to clangd and it stops guessing about template instantiations.
• cmake-tools-mcp — agents can ask “what are the compile flags for src/foo.cpp under target bar?” and get the right answer instead of inventing flags.
• compile_commands.json reader — the cheapest possible MCP. Tiny, but turns “I think you should add -fno-rtti” into “this TU is built with -fno-rtti -fno-exceptions, so RTTI-using code will not link”.
• sanitizer-output parser — structured access to ASan / UBSan / TSan reports so the agent can diff a known-good run against a regression.

Multi-agent patterns for C++ monorepos

Every major tool shipped multi-agent in February 2026 (Grok Build, Windsurf, Claude Code Agent Teams, Codex CLI, Devin). For a C++ monorepo, the pattern that actually works is agent-per-target: each agent owns one CMake target and never edits headers exposed by another target without a checkpoint. Headers in include/ shared between targets stay single-writer (one agent at a time, gated by a small lock file or a code-owner rule).

If you do not have explicit target ownership, multi-agent runs into write-write conflicts on shared headers within the first hour. Either invest in the ownership doc or stick to single-agent flows for that repo.

Decision tree

If you only read one section of this page, read this:

1. Compliance forbids cloud egress? → Continue.dev or Aider + local model (see Local LLM for C++).
2. Daily inline editing in an IDE? → Cursor (premium) or Continue.dev (premium-OSS).
3. Hard multi-file refactor, template debug, ABI work? → Claude Code (terminal, deep reasoning).
4. Want every change auto-committed and transparent? → Aider (premium-OSS).
5. VS Code agent, BYOK, watch every diff? → Cline (premium-OSS).
6. Large monorepo, parallel modules? → Windsurf or Grok Build (multi-agent).
7. Multi-agent with local-first guarantee (no source upload)? → Grok Build (new May 2026; too early for hard C++ verdict).
8. Async task delegation with strong eval? → Devin — and only with explicit rollback discipline.