# Review a pull request in TensorFlow with Atlas in 2026 > Atlas helps TensorFlow developers review pull requests by fetching full file context, checking API references, and running `pytest` to catch bugs beyond simple diffs. Atlas empowers TensorFlow developers in 2026 to review pull requests comprehensively, moving beyond line-by-line diffs to catch subtle bugs that a human might miss. It integrates directly with your existing TensorFlow toolchain, using `pytest` for testing, `uv` for package management, and `black` for formatting, ensuring a familiar and efficient workflow. Atlas fetches the branch, reads full changed files, checks for breaking API changes with LSP, greps for missed updates, and runs tests, all while providing transparent control over every action. ## Key takeaways - Atlas uses `bash` to fetch branches and run `pytest` for TensorFlow-specific testing. - Atlas's `read` tool provides full file context for `tf.data` pipelines and Keras 3 models, not just diff hunks. - The `lsp findReferences` tool proactively identifies breaking changes to `tf.function` signatures across the entire project. - Atlas `grep`s for missed updates to TensorFlow constants or `tf.compat.v1` references, ensuring codebase hygiene. - Every Atlas action, from `uv install` to `black` formatting, is permission-gated for secure TensorFlow development. ## How Atlas fetches and reads TensorFlow pull request changes Atlas fetches and reads TensorFlow pull request changes by leveraging its robust VCS layer, which exposes `git` data like status, diff, and commits. In 2026, this ensures you always work with the most current branch, allowing Atlas to pull the full content of changed files, not just isolated diff hunks, for a complete contextual understanding. When reviewing a TensorFlow pull request, Atlas first uses its `bash` tool to fetch the specific branch associated with the PR. This ensures the local repository is up-to-date. Following this, Atlas's `read` tool pulls the *entire* content of any file identified in the `git diff` as changed. For instance, if `my_model.py` or `data_pipeline.py` has modifications, Atlas reads the complete file. This approach is crucial for TensorFlow development, where a small change in a `tf.function` decorator or a `tf.data` pipeline definition might have implications for surrounding code that isn't visible in a standard line-by-line diff. By providing this full file context, Atlas helps identify issues like incorrect `tf.TensorShape` inferences or subtle `tf.data` pipeline misconfigurations that depend on code outside the immediate diff hunk. ## How Atlas checks for breaking API changes in TensorFlow Atlas checks for breaking API changes in TensorFlow by employing its `lsp` tool's `findReferences` operation for every modified function signature. This critical step, often overlooked in manual reviews, ensures that a change to a `tf.keras.Model` method or a custom `training_step` override in 2026 doesn't silently break callers not included in the original diff. In a TensorFlow codebase, altering a function signature, such as a method within a `tf.keras.Model` or a utility function used across multiple `tf.data` pipelines, can have far-reaching consequences. Atlas addresses this by using its `lsp` tool. After identifying changed function or method signatures within files like `model_architecture.py` or `custom_layers.py`, Atlas invokes `lsp findReferences` for each. This operation queries the Language Server Protocol server to find all usages of that specific signature across the entire project. If a change to `def call(self, inputs):` in a Keras layer, for example, introduces a new parameter, `lsp findReferences` will flag every location where `call` is invoked without the updated signature, even if those calling sites were not part of the original pull request's diff. This proactive check is vital for maintaining the integrity of complex TensorFlow graphs and Keras 3 model definitions. ## How Atlas identifies missed updates and stale code in TensorFlow Atlas identifies missed updates and stale code in TensorFlow by using its `grep` tool to search for specific patterns that should have been modified but were not. This is particularly useful in 2026 for catching instances where old constant names, deprecated `tf.compat.v1` references, or feature flags were not consistently updated across the codebase, preventing subtle runtime errors. TensorFlow projects often involve constants, configuration flags, or specific API versions that need consistent updates. For example, if a `tf.constant` representing a default batch size or a feature flag like `ENABLE_NEW_OPTIMIZER` is changed in one file, it might be missed in another. Atlas uses its `grep` tool to proactively search for these patterns. After a developer modifies a constant in `config.py`, Atlas can be instructed to `grep` for the old constant name across the entire project. This helps catch instances where a `tf.data` pipeline in `input_pipeline.py` or a custom training loop in `trainer.py` might still be referencing an outdated value. Similarly, it can detect lingering `tf.compat.v1` calls that should have been migrated to modern TensorFlow 2.x APIs, ensuring the codebase remains clean and up-to-date with Keras 3 and current TensorFlow best practices. ## How Atlas runs TensorFlow tests and formats code Atlas runs TensorFlow tests and formats code by directly invoking the project's established toolchain: `pytest` for testing and `black` for formatting. This ensures that any proposed changes, such as modifications to a `tf.function` or a Keras 3 model, pass all 100+ existing tests and adhere to the project's style guidelines before approval, maintaining code quality and consistency. A critical part of reviewing any TensorFlow pull request is verifying that the changes do not introduce regressions and conform to style standards. Atlas achieves this by using its `bash` tool to execute the project's native commands. For testing, Atlas runs `pytest`, the standard test runner for TensorFlow projects, often with specific flags like `atlas bash pytest tests/my_model_tests.py`. This allows Atlas to execute unit tests for `tf.keras.Model` definitions, `tf.data` pipeline components, or custom `tf.function` implementations. The results are then reported as a `todowrite` list, ordered by severity. For code formatting, Atlas invokes `black`, the widely adopted Python formatter. Before committing, Atlas can `atlas bash black my_changed_file.py` to ensure the code adheres to the project's `pyproject.toml` or `.black` configuration, preventing style-related comments during review and ensuring a consistent codebase for Keras 3 and TensorFlow development. ## Atlas's safety and transparency features for TensorFlow reviews Atlas provides robust safety and transparency features for TensorFlow reviews, ensuring developers maintain full control over every action. Every Atlas tool call, whether running `pytest` or modifying a `pyproject.toml`, is permission-gated against `allow`, `ask`, and `deny` rules, preventing unintended changes and offering a secure review environment in 2026. Reviewing complex TensorFlow code requires confidence that an AI agent won't make unauthorized or incorrect modifications. Atlas is designed with multiple layers of safety. Before any tool, such as `bash` to run `uv install` or `lsp` to refactor, is executed, Atlas checks against user-defined `allow`, `ask`, or `deny` permissions. This means a developer can configure Atlas to always `ask` before running `pytest` or `deny` any direct file writes without explicit approval. Furthermore, Atlas drafts a plan in a read-only plan agent, detailing its intended actions, and seeks approval before switching to a build agent that can execute commands. For any proposed file edits, Atlas computes a unified diff and surfaces it for explicit approval before writing, allowing developers to inspect changes to `tf.data` pipelines or Keras model definitions before they are applied. This granular control ensures that Atlas acts as a helpful assistant, not an autonomous agent, in your TensorFlow development workflow. ## Steps 1. Initiate Atlas in your TensorFlow project with a `pyproject.toml` that pins `tensorflow` and `keras`. 2. Ask Atlas to fetch the pull request branch and produce the diff using `atlas bash git fetch origin ` and `atlas vcs diffRaw`. 3. Instruct Atlas to read the full content of all changed files, such as `my_model.py` or `data_pipeline.py`, using `atlas read ` to gain complete context. 4. For every changed `tf.function` or `tf.keras.Model` method signature, have Atlas run `atlas lsp findReferences` to check for breaking callers across the codebase. 5. Direct Atlas to `grep` for old constant names, stale `tf.compat.v1` references, or feature flags that should have been updated but were missed. 6. Prompt Atlas to run the project's tests using `atlas bash pytest` and report findings as a `todowrite` list, ordered by severity. 7. Before approval, ask Atlas to format any modified Python files with `atlas bash black ` to ensure style consistency. ## FAQ ### How does Atlas ensure I don't miss context outside the diff in TensorFlow? Atlas ensures you don't miss context by using its `read` tool to pull the *entire* content of changed files, such as `my_model.py` or `data_pipeline.py`, rather than just the diff hunks. This allows it to understand the full scope of a `tf.function` or `tf.data` pipeline modification, catching issues that a line-by-line review would overlook. ### Can Atlas check if a TensorFlow API change broke other parts of my project? Yes, Atlas can check for breaking API changes. For every modified function or method signature in your TensorFlow code, like a `tf.keras.Model` method, Atlas uses its `lsp` tool's `findReferences` operation to identify all callers across the project. This proactively flags any locations that might break due to the signature change, even if they weren't in the original diff. ### How does Atlas integrate with TensorFlow's testing framework? Atlas integrates direct with TensorFlow's testing framework by using its `bash` tool to directly invoke `pytest`, the standard test runner. It can run specific test files, like `tests/test_model.py`, and reports the findings as a `todowrite` list, allowing you to quickly assess the impact of changes on your `tf.function` or Keras 3 components. ### Does Atlas help maintain code style in TensorFlow projects? Absolutely. Atlas helps maintain code style by using its `bash` tool to run `black`, the preferred Python formatter, on any modified files. This ensures that all changes, including those to `tf.data` pipelines or custom training loops, adhere to your project's formatting standards defined in `pyproject.toml` before they are committed. ### What safety measures does Atlas have for reviewing TensorFlow code? Atlas incorporates several safety measures for TensorFlow code reviews. All tool calls, such as `bash` for `uv install` or `lsp` for refactoring, are permission-gated (`allow`, `ask`, `deny`). Atlas also drafts a read-only plan and presents a unified diff for approval before any file writes, giving you full control over changes to your `tf.keras.Model` or `tf.function` definitions. ### Can Atlas help optimize `tf.data` pipelines during a review? While the primary job is review, Atlas can assist with `tf.data` pipeline optimization. It can be asked to add `prefetch` and `cache` stages to your `tf.data` pipelines and then measure step times before and after, helping to identify performance bottlenecks and suggest improvements during the review process. --- Canonical HTML: https://runatlas.sh/resources/stacks/review-a-pull-request-in-tensorflow Source of truth: aeo_pages row `/resources/stacks/review-a-pull-request-in-tensorflow` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.