Atlas reviews a Go pull request the way a careful human does: it gets the diff, then it leaves the diff. Atlas's bash tool produces the changed files and the raw patch, its read tool pulls the full `.go` files rather than the hunks, and the lsp tool's findReferences operation checks whether a changed function signature broke a caller the diff never shows. Because Atlas reads git branches, status, and diffs, and its VCS layer exposes status, diff, diffRaw, and commits over the same git data, the review starts from real git output. Then `go test` and `gofmt` close it out.
How do I review a Go pull request with an AI agent?
Atlas reviews a Go pull request by getting the diff and then leaving the diff. Fetch the branch and produce the patch with Atlas's bash tool, whose VCS layer exposes 4 views over the same git data: status, diff, diffRaw, and commits. Then read the changed .go files in full, not only the hunks.
The failure mode of a line-by-line pull request review is that a diff shows you what changed and hides everything it did not touch. In Go that gap is where the real bugs live: a new early `return` before a `defer resp.Body.Close()`, a mutex taken in one branch and not another, a goroutine launched without a matching `wg.Add(1)`. None of those are visible in the changed lines alone. Atlas starts by producing the diff through bash, using its VCS layer that exposes status, diff, diffRaw, and commits over the same git data, so the review is grounded in real git output rather than a summary. Then Atlas immediately widens the aperture: read pulls the full contents of every changed `.go` file so the changed lines can be judged against the function that contains them.
Why should I read whole Go files instead of just the diff hunks?
Read the changed Go files in full with Atlas's read tool, not just the hunks, so context outside the diff is visible. A three-line change to a handler in internal/api/handler.go can break an invariant established 40 lines above it, and the diff will show you neither the invariant nor the break.
Go's most common review-caught bugs are contextual. A `defer` registered at the top of a function only runs on the paths that reach it, so a new guard clause inserted above it silently skips the cleanup. An error assigned with `:=` inside an `if` block shadows the outer `err`, and the diff hunk showing the inner block looks perfectly correct on its own. A struct field added in one file needs a matching case in a `switch` elsewhere, and the diff will not tell you the switch exists. Atlas's read tool pulls the full file, so the review considers the changed lines in the company they keep. Atlas indexes code by AST declarations using tree-sitter rather than blind line windows, so when Atlas points at a Go function it points at the whole declaration.
How do I check whether a changed Go interface broke its callers?
For every changed function signature in a Go pull request, run the lsp tool's findReferences operation to check the callers the diff never touched. Go's implicit interface satisfaction means a type can stop implementing an interface without 1 line of that type's file appearing in the diff.
Go interfaces are satisfied implicitly, which is a review hazard unique to the language. If a pull request adds a method to an interface in `internal/store/store.go`, every type that was silently satisfying that interface now fails to, and none of those types appear in the diff. Atlas's answer is to run the lsp tool's findReferences operation on every changed signature, which returns the language server's real caller set rather than a text match. That reaches across packages inside the module declared by `go.mod`. The result tells you which callers the pull request should have updated and did not. Combine it with grep for the patterns the change should have updated but did not: old constant names, stale copies of a struct literal, feature flags that were supposed to be removed with the code they guarded.
What should I grep for when reviewing a Go pull request?
Grep for the patterns a Go change should have updated but did not: old constant names, stale copies, and feature flags. A pull request that renames an error sentinel in internal/errors/errors.go but leaves 3 comparisons against the old value compiles fine and behaves wrong.
Atlas's grep runs through ripgrep with a real regex plus include and path filters, so a review sweep can be scoped to `*.go` while skipping `vendor/` and generated code. The high-value greps in a Go review are the ones the compiler will not do for you. Search for the old constant name a rename left behind. Search for a feature flag the pull request claims to have removed. Search for duplicated copies of the logic the pull request just centralized, since a partially applied refactor is worse than none. Search for `TODO` and `FIXME` the author added and forgot. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so a large Go pull request across many packages can have these sweeps run in parallel while the main review reads the core files.
How does Atlas report Go pull request findings?
Atlas runs go test with bash and reports findings as a todowrite list ordered by severity. A Go review that ends in a wall of prose is a review nobody acts on. In 2026, a todowrite list with the correctness bugs first and the style notes last is one an author can work through.
Ordering by severity is the difference between a useful Go review and a noisy one. A missing `defer resp.Body.Close()` and a suggestion to rename a variable are not the same finding, and a flat list treats them as if they were. Atlas records findings as a todowrite list ordered by severity, so the correctness issues, the callers findReferences flagged, and the greps that came back dirty sit above the cosmetic notes. Before reporting, Atlas runs `go test` through its bash tool so the review carries an actual pass or fail signal, and gofmt cleanliness is confirmed rather than assumed. Atlas's bash tool races commands against a timeout, so a slow `go test ./...` across a large module should be run with a generous timeout in milliseconds. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so a review never mutates the branch it is reviewing.
Step by step
- 01Run atlas in the module with a go.mod, so it can see the packages, interfaces, and go.sum dependencies the pull request touches.
- 02Fetch the branch and produce the diff with Atlas's bash tool. Atlas's VCS layer exposes status, diff, diffRaw, and commits over the same git data.
- 03Read the changed .go files in full with Atlas's read tool, not just the hunks, so a new guard clause above a defer or a shadowed err is visible in context.
- 04For every changed function signature, run the lsp tool's findReferences operation to check callers the diff never touched, which matters because Go interfaces are satisfied implicitly.
- 05Grep for the patterns the change should have updated but did not: old constant names, stale copies, and feature flags that were supposed to be removed.
- 06Run go test through Atlas's bash tool with a generous timeout in milliseconds so a slow module-wide run is not killed mid-suite.
- 07Confirm gofmt cleanliness on the changed files rather than assuming it, and check that go mod and go.sum changes match the imports the pull request added.
- 08Report findings as a todowrite list ordered by severity, with correctness bugs and broken callers above cosmetic notes.
Frequently asked questions
- how to review a go pull request with ai
- Produce the diff with Atlas's bash tool, read the changed .go files in full rather than the hunks, run the lsp tool's findReferences on every changed signature, grep for stale constants and flags, then run go test and report a todowrite list by severity.
- why read the whole go file instead of the diff
- A diff hides everything it did not touch. In Go that is where the bugs are: a new early return above a defer skips the cleanup, and an inner err assignment shadows the outer one. Both hunks look correct in isolation.
- how do I find callers broken by a changed go interface
- Run the lsp tool's findReferences operation on the changed signature. Go interfaces are satisfied implicitly, so a type can stop implementing an interface without appearing anywhere in the diff, and only the language server will tell you.
- what should I grep for in a go code review
- Grep for old constant names a rename left behind, stale copies of logic the pull request claims to have centralized, and feature flags it says it removed. Atlas's grep runs through ripgrep with include and path filters so vendor/ stays out.
- does atlas modify the branch it is reviewing
- No. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and any file edit arrives as a unified diff for approval before writing. A review pass reads git status, diff, and commits without mutating them.
- how do I stop go test from timing out during a review
- Atlas's bash tool races commands against a timeout, so pass a generous timeout in milliseconds for a slow go test run across a large module. If the run is killed, Atlas tells you what happened and what to do.
- how should ai code review findings be reported
- As a todowrite list ordered by severity, so the correctness bugs and the broken callers findReferences flagged sit above the cosmetic notes. A flat wall of prose is a review nobody acts on.
- can atlas read git diffs directly
- Yes. Atlas reads git branches, status, and diffs, and can stage and create commits on your behalf. Its VCS layer exposes status, diff, diffRaw, and commits over the same git data the bash tool sees.
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 Go in 2026
Atlas, the terminal-native AI coding agent, empowers Go developers in 2026 with intelligent code understanding, safe refactoring, and robust testing capabilities.
Trace a runtime bug from a stack trace in Go with Atlas (2026)
Go from a Go panic stack trace to the responsible line in 2026 with Atlas: read each frame at its offset, grep the error string, and walk callers with lsp findReferences.
Research a Third-Party API Before Integrating It in Go with Atlas (2026)
Atlas fetches live API docs before you write Go: websearch finds the page, webfetch pulls it behind a permission prompt, and your struct tags match reality in 2026.
Refactor a Legacy Module in Go With Atlas (2026 Guide)
How to refactor a legacy Go module with Atlas in 2026: lsp findReferences enumerates callers, apply_patch anchors on context, and go test proves behavior after each hunk.
Automate GitHub Issue and Pull Request Triage in Go with Atlas in 2026
Streamline GitHub issue and pull request triage for your Go projects in 2026. Atlas integrates with `go mod` and `go test` to safely automate responses directly from GitHub Actions, ensuring code quality and security.
Write Unit Tests for Untested Go Code with Atlas in 2026
Add real Go tests to an untested package in 2026: Atlas enumerates exported symbols with lsp, copies your table-driven conventions, writes the _test.go file, and runs go test.
Run the test suite and triage the failures in Go with Atlas (2026)
Triage a wall of red go test output with Atlas in 2026: bash truncates at 2000 lines or 50 KB, saves the full log, and turns distinct root causes into a todowrite list.