To review a C++ pull request with Atlas, you get the diff and then leave the diff. Atlas produces the changed files and the raw patch with bash, reads the changed .cpp and .h files in full rather than the hunks, and runs the lsp tool's findReferences operation on every changed function signature to check callers the diff never touched. In C++ that last step is the whole point: a changed header in include/ can break a translation unit that appears nowhere in the patch, and GoogleTest via ctest is the only thing that will tell you.
How do I review a C++ pull request with an AI coding agent?
Atlas reviews a C++ pull request in 5 documented steps: bash fetches the branch and produces the raw patch, read pulls the full .cpp and .h files rather than the hunks, the lsp tool checks whether a changed signature broke a caller the diff never shows, grep hunts stale copies, and bash runs ctest.
A line-by-line read of a C++ diff catches typos and misses bugs. The changed hunk in src/render/pipeline.cpp looks correct in isolation, but the constructor it calls three lines above the hunk was also changed, and the header in include/render/pipeline.h now declares a different default argument. Atlas therefore fetches the branch and produces the diff with bash, using Atlas's VCS layer, which exposes status, diff, diffRaw, and commits over the same git data. Then Atlas reads the changed files in full with read, not just the hunks, so context outside the diff is visible. That is where C++ bugs actually live: in the interaction between a changed header and the translation units that include it.
How does Atlas catch C++ callers the diff never touched?
Atlas runs the lsp tool's findReferences operation on every changed function signature to check callers the diff never touched, which is step 3 of its 2026 review workflow. In C++ a header change in include/ propagates to every translation unit that includes it, and those .cpp files may not appear in the pull request.
The most dangerous C++ pull request is one that changes a header. Adding a parameter to a method declared in include/net/socket.h changes the contract for every .cpp that includes it, and only the files the author happened to update show up in the diff. Atlas closes that hole by running the lsp tool's findReferences operation on each changed signature, which asks the language server for every callsite across the project, including the translation units the pull request never opened. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so each C++ function is retrieved as a declaration, and Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion when you need to find related code by behavior rather than by name.
What should Atlas grep for when reviewing a C++ change?
Atlas greps for the 3 patterns a C++ change should have updated but did not: old constant names, stale copies, and feature flags. A pull request that renames a constant in include/config.h but leaves the old name in a CMakeLists.txt option or a second .cpp is a compile error waiting for CI.
The review question grep answers is what the author forgot. Atlas greps for the patterns the change should have updated but did not, and in a C++ project the usual suspects are concrete: the old constant name still referenced in another translation unit, a stale copy of a struct definition duplicated into a second header, a feature flag toggled in src/ but not in the corresponding CMakeLists.txt target, or a vcpkg dependency added to the code but never declared in vcpkg.json. Atlas's grep takes a real regex with include and path filters, so scoping the sweep to include/**/*.h and then to CMakeLists.txt files is two calls. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so a review session can be configured read-only.
How does Atlas run and report on a C++ test suite during review?
Atlas runs the tests with bash, executing GoogleTest via ctest against the built targets, and reports findings as a todowrite list ordered by severity. A review that ends in a prioritized list of 5 concrete issues is actionable, where a wall of inline comments is not.
A C++ review should end with evidence, not opinions. Atlas runs the tests with bash, invoking GoogleTest via ctest against the targets your CMakeLists.txt defines, so a claim that the pull request breaks the socket tests is demonstrated rather than asserted. Atlas then reports findings as a todowrite list ordered by severity, putting the header change that breaks three uninspected translation units above the clang-format nit. That ordering is what makes the review usable by the author. Atlas is a terminal-native TUI rendered with SolidJS through the OpenTUI renderer, so the ctest output, the diff, and the findings list all live in the terminal where you would have run cmake anyway. Atlas reads git branches, status, and diffs, so switching between the pull request branch and main is part of the same session.
Can Atlas review a C++ pull request without modifying my repo?
Yes. Reviewing a C++ pull request is a read-only job, and every Atlas tool call in 2026 is permission-gated against allow, ask, and deny rules before it runs, so a review session can allow bash, read, grep, and the lsp tool while denying every write to src/ and include/.
A reviewer should not be able to commit. Atlas's permission system supports exactly that posture: allow GoogleTest via ctest and the git commands the review needs through bash, allow read, grep, and the lsp tool, and deny edit and write entirely. If a fix does come out of the review, Atlas computes a unified diff for every file edit and surfaces it for approval before writing, and Atlas snapshots file changes as git patches so edits can be diffed and rolled back. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, which is the natural way to turn a review finding into a change. For a proprietary C++ codebase, Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, and clang-format remains your formatting gate.
Step by step
- 01Run atlas in a project with a CMakeLists.txt so Atlas can read your headers, translation units, and build targets.
- 02Fetch the branch and produce the diff with bash; Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data.
- 03Read the changed .cpp and .h files in full with the read tool, not just the hunks, so context outside the diff is visible.
- 04For every changed function signature, run the lsp tool's findReferences operation to check callers the diff never touched, especially translation units that include a modified header.
- 05Grep for the patterns the change should have updated but did not: old constant names, stale struct copies, feature flags, and vcpkg.json dependencies.
- 06Build and run the tests with bash using GoogleTest via ctest against the targets your CMakeLists.txt defines.
- 07Report findings as a todowrite list ordered by severity, putting a header change that breaks uninspected translation units above a clang-format nit.
- 08Keep the session read-only by allowing bash, read, grep, and the lsp tool while denying writes to src/ and include/.
- 09If a fix is warranted, let Atlas propose it, review the unified diff it surfaces, and run clang-format before committing.
Frequently asked questions
- how do I review a C++ pull request with an AI agent
- Atlas fetches the branch and produces the diff with bash, then reads the changed .cpp and .h files in full rather than the hunks. For every changed signature it runs the lsp tool's findReferences to check callers the diff never touched, then runs GoogleTest via ctest.
- how do I find callers broken by a changed C++ header
- Run the lsp tool's findReferences operation on the changed signature. In C++ a header change in include/ propagates to every translation unit that includes it, and those .cpp files often do not appear in the pull request at all, so the diff alone cannot show them.
- can an AI agent review my C++ code without being able to change it
- Yes. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so a review session can allow bash, read, grep, and the lsp tool while denying every write to src/ and include/.
- does Atlas work with CMake and vcpkg projects
- Yes. The documented C++ setup is to run atlas in a project with a CMakeLists.txt and let Atlas read your headers, translation units, and build targets. vcpkg is the package manager, GoogleTest via ctest is the test runner, and clang-format is the formatter.
- why read whole C++ files instead of just the diff hunks
- The bug in a C++ pull request usually lives in the context outside the hunk: a constructor changed three lines above, a default argument altered in the header, a member initialized in a different order. Atlas reads the changed files in full for that reason.
- how does Atlas prioritize C++ review findings
- Atlas reports findings as a todowrite list ordered by severity, so a header change that breaks three uninspected translation units ranks above a clang-format nit. The findings are backed by an actual GoogleTest via ctest run rather than by assertion.
- what should I grep for when reviewing a C++ change
- Grep for what the author should have updated but did not: old constant names still referenced in another translation unit, stale struct copies duplicated into a second header, feature flags toggled in src/ but not in CMakeLists.txt, and dependencies missing from vcpkg.json.
- can I keep my C++ source off third-party servers during review
- Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers. The read, grep, lsp, and bash steps all run locally against your working tree and your CMake build.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Review a Pull Request with Atlas (2026 Workflow)
How to review a pull request with Atlas in 2026: bash produces the raw patch, read pulls whole files, the lsp tool's findReferences checks callers the diff never shows.
Atlas for C++ in 2026
In 2026, C++ developers adopt Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas offers secure, context-aware assistance for modern C++ projects, integrating with CMake and ensuring code quality
Rename a symbol across the repo in C++ with Atlas (2026)
How Atlas renames a symbol across a C++ repo in 2026: lsp findReferences for the true reference set, grep for strings and docs, and edit that refuses ambiguous matches.
Diagnose a Hanging or Long-Running C++ Command with Atlas (2026)
Diagnose a hanging or long-running C++ build or test with Atlas in 2026. Read the bash shell_metadata block to tell a slow ctest run from one blocked on stdin.
Automate GitHub Issue and Pull Request Triage in C++ with Atlas in 2026
Automate GitHub issue and pull request triage for C++ projects using Atlas. Safely respond to events, enforce permissions, and manage context overflow in 2026 with your existing C++ toolchain.
Write unit tests for untested code in C++ with Atlas (2026)
Add GoogleTest coverage to an untested C++ module with Atlas in 2026: enumerate symbols with lsp, copy the repo's conventions, and actually run ctest on the result.
Plan a Multi-File Change Before Editing in C++ with Atlas (2026)
Design a C++ change across headers and translation units in 2026 before one line moves: Atlas plan mode denies every edit tool until you approve the plan and switch to build.
Refactor a Legacy Module in C++ with Atlas (2026)
How to refactor a legacy C++ module with Atlas in 2026: enumerate callsites with the lsp tool, restructure with apply_patch, and prove behavior with GoogleTest via ctest.