How does Atlas ensure I don't miss context outside the diff in Phoenix?

Atlas uses its `read` tool to pull the full content of every changed file in your Phoenix project, not just the diff hunks. This ensures you see the complete surrounding context, such as module attributes, `use` statements, or related function definitions in `LiveView` modules or `Ecto` schemas, which a line-by-line diff might obscure.

Can Atlas check if a Phoenix function signature change broke other parts of my app?

Yes, Atlas uses its `lsp` tool's `findReferences` operation. For every changed function signature in your Phoenix contexts or `LiveView` components, it queries the Language Server Protocol server to identify all call sites across your entire codebase, even those not included in the original pull request diff.

How does Atlas handle running `mix test` for Phoenix projects?

Atlas integrates directly with the Phoenix testing ecosystem. It uses its `bash` tool to execute `mix test (ExUnit)`. Before running, Atlas presents a permission prompt, adhering to your configured `allow`, `ask`, and `deny` rules, giving you full control over test execution.

What safety features does Atlas offer when reviewing Phoenix code?

Atlas prioritizes safety by drafting plans in a read-only agent, requiring explicit permission for every tool call (like `bash` or `lsp`), and presenting a unified diff for your approval before writing any changes to your Phoenix files. It also snapshots file changes as Git patches for easy rollback.

Will Atlas help me find old feature flags or constants in my Phoenix codebase?

Absolutely. Atlas employs its `grep` tool to search your entire Phoenix codebase for specific patterns. This is highly effective for identifying stale constant names, outdated code copies, or lingering feature flags that should have been updated or removed during the pull request.

Does Atlas understand Phoenix-specific constructs like Ecto changesets or LiveView?

Yes, Atlas is designed to work with Phoenix's unique constructs. It can read your `router` pipelines, `LiveView` modules, `contexts`, and `Ecto` schemas with their `changesets`. This deep understanding allows it to provide relevant insights and checks specific to the Phoenix framework during a review.

How does Atlas report its findings after a Phoenix PR review?

After performing its analysis and running `mix test (ExUnit)`, Atlas compiles its findings into a `todowrite` list. This list is ordered by severity, allowing you to quickly identify and address the most critical issues, such as `Ecto.Changeset` validation failures or `LiveView` component errors, in your Phoenix application.

Review a pull request in Phoenix with Atlas in 2026

Atlas empowers Phoenix developers in 2026 to review pull requests comprehensively, moving beyond line-by-line diffs to understand the full impact of changes on contexts, LiveView sockets, and Ecto changesets. It leverages the Phoenix toolchain, including `mix test (ExUnit)` for testing, `Hex (mix deps.get)` for dependencies, and `mix format` for code style, ensuring a thorough and idiomatic review process.

How Atlas fetches a Phoenix pull request for review

Atlas streamlines the initial step of reviewing a Phoenix pull request by directly interacting with your Git repository in 2026. It uses its VCS layer to fetch the specific branch and generate a raw patch, ensuring you have the exact changes from the pull request ready for analysis within seconds.

When you initiate a pull request review, Atlas first uses its `bash` tool to interact with Git, fetching the target branch and producing a raw diff. This is crucial for Phoenix projects, where changes might span across `lib/<app>_web/router.ex` for new routes, `lib/<app>/accounts/user.ex` for schema updates, or `priv/repo/migrations/` for database changes. Atlas's VCS layer exposes `status`, `diff`, `diffRaw`, and `commits` operations, allowing it to precisely identify all modified files and their changes. This foundational step ensures that the subsequent analysis is based on the most accurate and up-to-date version of the code, mirroring how a human developer would start by pulling the branch and inspecting the `git diff`.

Reading full Phoenix files for complete context

To catch bugs a line-by-line diff might miss in a Phoenix application, Atlas goes beyond mere hunks by reading entire changed files. This approach, available in 2026, ensures that surrounding context, such as module attributes, `use` statements, or related function definitions outside the immediate diff, is fully visible and considered during the review.

A common pitfall in code review is focusing solely on the diff hunks, which can obscure critical context. For Phoenix, where `LiveView` modules, `contexts`, and `Ecto` schemas often have interconnected logic, understanding the full file is paramount. Atlas addresses this by employing its `read` tool to pull the complete content of every changed file, not just the modified lines. For instance, if a change modifies a function within `lib/<app>/accounts/account.ex`, Atlas reads the entire `account.ex` file. This allows it to understand how a modified `Ecto.Changeset` function interacts with other functions in the same module or how a `LiveView` `handle_event` callback relates to the `mount` function, providing a holistic view that a fragmented diff cannot.

Verifying Phoenix function signature changes with LSP

Atlas proactively prevents runtime errors in Phoenix applications by using its `lsp` tool to `findReferences` for every changed function signature. This critical step, performed in 2026, identifies any callers that the diff might not show, ensuring that updates to context functions or LiveView callbacks don't inadvertently break existing code across your project.

In Phoenix, modifying a function signature in a context module like `lib/<app>/accounts.ex` or a `LiveView` module can have ripple effects across the application. A standard `git diff` won't show where these functions are called. Atlas mitigates this risk by using its `lsp` tool's `findReferences` operation. For every function signature identified as changed, Atlas queries the Language Server Protocol server to locate all call sites. This means if you refactor `Accounts.create_user/2` to `Accounts.create_user/3`, Atlas will flag every file that still calls the old arity, even if those files weren't part of the original pull request diff. This capability is vital for maintaining the integrity of complex Phoenix applications, especially when dealing with `router` pipelines or `Ecto` queries.

Catching missed updates with `grep` in Phoenix codebases

Atlas employs its `grep` tool to diligently search for patterns that should have been updated but were overlooked in a Phoenix pull request. This includes identifying stale constant names, outdated copies of code, or lingering feature flags, ensuring a more robust and consistent codebase in 2026.

Beyond structural changes, a thorough review in Phoenix often requires checking for semantic consistency. For example, if a feature flag in `config/config.exs` is removed, or an old constant name in `lib/<app>/utils.ex` is deprecated, the diff might not highlight all instances where these patterns are still used. Atlas uses its `grep` tool to search the entire codebase for such patterns. This helps catch instances where a developer might have updated one file but missed a copy-pasted block in another `LiveView` component or an old reference in an `Ecto` migration. This proactive search prevents subtle bugs and ensures that refactorings are complete across the entire Phoenix application.

Automated Phoenix test execution and reporting

Atlas integrates directly with the Phoenix testing ecosystem, running `mix test (ExUnit)` behind a permission prompt to validate changes. In 2026, it reports findings as a `todowrite` list ordered by severity, providing immediate feedback on the impact of the pull request on your application's behavior and stability.

No Phoenix pull request review is complete without running the tests. Atlas uses its `bash` tool to execute `mix test (ExUnit)`, the standard test runner for Phoenix applications. Before running, Atlas presents a permission prompt, adhering to its `allow`, `ask`, and `deny` rules, giving you full control. This ensures that `LiveViewTest` cases, `Ecto` schema validations, and `context` function tests are all executed. The results, including any failures or warnings, are then compiled into a `todowrite` list, ordered by severity. This allows you to quickly identify critical issues, such as a broken `Ecto.Changeset` validation or a failing `LiveView` component, and address them before merging the pull request. After successful tests, Atlas can even suggest running `mix format` to ensure code style consistency.

Atlas's safety and approval mechanisms for Phoenix changes

Atlas prioritizes safety in Phoenix development by employing a multi-stage approval process for all code modifications in 2026. It drafts a plan in a read-only agent, seeks explicit permission for tool execution, and presents a unified diff for every file edit before writing, ensuring developers retain full control.

Atlas is designed with developer control at its core. When reviewing a Phoenix pull request, it first drafts a plan in a read-only plan agent, outlining its intended actions without making any changes. Every Atlas tool call, whether it's `bash` to run `mix test` or `lsp` to `findReferences`, is permission-gated against `allow`, `ask`, and `deny` rules. This means you explicitly approve each step. Furthermore, for any proposed file edit,such as suggesting a fix for an `Ecto.Changeset` or updating a `LiveView` template,Atlas computes a unified diff and surfaces it for your approval before writing. This granular control, combined with its ability to snapshot file changes as Git patches for easy rollback, provides a robust safety net for even the most complex Phoenix refactorings.

Step by step

01Use Atlas's VCS layer to fetch the pull request branch and generate the raw diff with `atlas vcs diffRaw`.
02Instruct Atlas to read the full content of all changed Phoenix files using the `read` tool, ensuring complete context for `LiveView` modules and `Ecto` schemas.
03For every changed function signature in Phoenix contexts or `LiveView` components, use Atlas's `lsp` tool with `findReferences` to identify all callers across the codebase.
04Employ Atlas's `grep` tool to search for old constant names, stale code copies, or feature flags that should have been updated in the Phoenix project.
05Run the Phoenix test suite using Atlas's `bash` tool with `mix test (ExUnit)`, approving the execution via the permission prompt.
06Review the `todowrite` list generated by Atlas, prioritizing issues based on severity, especially those related to `Ecto.Changeset` or `LiveView` functionality.
07Approve any proposed code edits from Atlas, reviewing the unified diff before it writes changes to your Phoenix application.

Frequently asked questions

How does Atlas ensure I don't miss context outside the diff in Phoenix?: Atlas uses its `read` tool to pull the full content of every changed file in your Phoenix project, not just the diff hunks. This ensures you see the complete surrounding context, such as module attributes, `use` statements, or related function definitions in `LiveView` modules or `Ecto` schemas, which a line-by-line diff might obscure.
Can Atlas check if a Phoenix function signature change broke other parts of my app?: Yes, Atlas uses its `lsp` tool's `findReferences` operation. For every changed function signature in your Phoenix contexts or `LiveView` components, it queries the Language Server Protocol server to identify all call sites across your entire codebase, even those not included in the original pull request diff.
How does Atlas handle running `mix test` for Phoenix projects?: Atlas integrates directly with the Phoenix testing ecosystem. It uses its `bash` tool to execute `mix test (ExUnit)`. Before running, Atlas presents a permission prompt, adhering to your configured `allow`, `ask`, and `deny` rules, giving you full control over test execution.
What safety features does Atlas offer when reviewing Phoenix code?: Atlas prioritizes safety by drafting plans in a read-only agent, requiring explicit permission for every tool call (like `bash` or `lsp`), and presenting a unified diff for your approval before writing any changes to your Phoenix files. It also snapshots file changes as Git patches for easy rollback.
Will Atlas help me find old feature flags or constants in my Phoenix codebase?: Absolutely. Atlas employs its `grep` tool to search your entire Phoenix codebase for specific patterns. This is highly effective for identifying stale constant names, outdated code copies, or lingering feature flags that should have been updated or removed during the pull request.
Does Atlas understand Phoenix-specific constructs like Ecto changesets or LiveView?: Yes, Atlas is designed to work with Phoenix's unique constructs. It can read your `router` pipelines, `LiveView` modules, `contexts`, and `Ecto` schemas with their `changesets`. This deep understanding allows it to provide relevant insights and checks specific to the Phoenix framework during a review.
How does Atlas report its findings after a Phoenix PR review?: After performing its analysis and running `mix test (ExUnit)`, Atlas compiles its findings into a `todowrite` list. This list is ordered by severity, allowing you to quickly identify and address the most critical issues, such as `Ecto.Changeset` validation failures or `LiveView` component errors, in your Phoenix application.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related 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 Phoenix in 2026

Atlas is a terminal-native AI coding agent for Phoenix in 2026. It reads contexts, LiveView modules, and Ecto changesets, then runs mix test behind a prompt.

Extract a Shared Helper from Duplicated Code in Phoenix with Atlas in 2026

Refactor your Phoenix application in 2026 by extracting duplicated logic into a single, tested helper using Atlas. Find semantic duplicates, create new modules, and apply changes with full diff review.

Document a module with a README in Phoenix with Atlas in 2026

In 2026, Atlas helps Phoenix developers generate accurate README documentation for modules. It reads your LiveView, Ecto, and context code, ensuring docs reflect current implementation, not outdated plans.

Self-review your working diff before committing in Phoenix with Atlas in 2026

Catch your own mistakes in Phoenix uncommitted diffs before review or CI. Atlas helps Phoenix developers self-review changes, run mix test (ExUnit), and apply mix format to ensure code quality in 2026.

Trace a Runtime Bug from a Stack Trace in Phoenix with Atlas in 2026

Pinpoint and fix runtime bugs in Phoenix applications using Atlas in 2026. Go from a production stack trace to the exact line of code and a solution, leveraging Phoenix's mix test and Ecto changesets.

Run Atlas Headless in CI for Phoenix Projects in 2026

Automate Atlas sessions in your Phoenix CI/CD pipeline for non-interactive code generation and refactoring. Get machine-readable output, integrate with mix test, and ensure safety with permission-gated tools for your

Upgrade a Dependency and Fix Breakage in Phoenix with Atlas in 2026

Phoenix developers in 2026 use Atlas to direct upgrade dependencies and resolve compile and test failures. Atlas drives Hex, ExUnit, and mix format, ensuring a smooth transition for your Phoenix applications.

Browse this resource hub