To debug a single failing test in TensorFlow, Atlas runs the specific test in isolation using `pytest` via its `bash` tool, then analyzes the code with `lsp` to identify the root cause. Atlas integrates directly with your TensorFlow project's `pyproject.toml` and uses `uv` for package management and `black` for formatting, ensuring a familiar and efficient debugging experience.
How to run a single TensorFlow test with Atlas bash
Atlas runs a single failing TensorFlow test in isolation using its `bash` tool, providing a focused output for debugging. This approach mirrors how a developer would manually execute `pytest` with a specific filter, ensuring that only the relevant test output, often just 1 or 2 lines, is presented for analysis.
When a TensorFlow test fails, the first step is to isolate it. Atlas achieves this by invoking `pytest` directly through its `bash` tool. For instance, if `tensorflow/python/ops/math_ops_test.py::MathOpsTest::test_add_simple` is failing, Atlas will execute a command similar to `pytest tensorflow/python/ops/math_ops_test.py::MathOpsTest::test_add_simple`. This command runs only the specified test, drastically reducing the output noise compared to running the entire test suite. Atlas can also incorporate verbose flags or specific environment variables, just as you would in a standard terminal session, to gather more detailed runtime information from your TensorFlow environment. This direct interaction with the shell ensures that all standard `pytest` features, including test filtering and output control, are fully available to the agent.
How Atlas understands TensorFlow test code and call graphs
Atlas understands the failing TensorFlow test and its exercised module by leveraging its `read` and `lsp` tools, which provide deep code insights. By 2026, Atlas's `lsp` integration offers precise `goToDefinition` and `findReferences` operations, crucial for navigating complex TensorFlow and Keras 3 codebases.
After running the isolated test, Atlas uses its `read` tool to examine the test file, such as `tensorflow/python/ops/math_ops_test.py`, and the specific module it exercises. For example, if `test_add_simple` fails, Atlas will read the test's assertion and the TensorFlow operation it calls. Subsequently, Atlas employs its `lsp` (Language Server Protocol) tool to walk the call graph. Using `lsp`'s `goToDefinition` operation, Atlas can trace from the failing assertion back through the TensorFlow API calls, like `tf.add`, to their underlying implementations. The `findReferences` operation helps identify where a particular TensorFlow function or Keras model definition is used, providing context for potential side effects or shared dependencies within your `pyproject.toml`-defined project. This detailed code navigation is essential for understanding how `tf.function` graph tracing or `tf.data` pipelines might be contributing to the failure.
How Atlas forms hypotheses and debugs TensorFlow code
Atlas forms a hypothesis about the TensorFlow test failure and checks it by adding temporary logging or re-running tests with verbose flags. This iterative process, often involving 3 to 5 cycles of modification and re-execution, helps pinpoint issues within `tf.function` or `tf.data` pipelines.
Once Atlas has a clear understanding of the call graph, it forms a hypothesis about the root cause of the TensorFlow test failure. To validate this hypothesis, Atlas can use its `edit` tool to insert temporary logging statements directly into the production code. For instance, it might add `print` statements or `tf.print` operations within a `tf.function` decorated method or a `tf.data` transformation to inspect intermediate tensor values. Alternatively, Atlas can re-run the single test with additional verbose flags through its `bash` tool, such as `pytest -v -s`, to get more detailed output from `pytest` or TensorFlow's internal logging. Each modification is followed by re-running the isolated test to observe the impact, allowing Atlas to refine its understanding and narrow down the problem area, whether it's an issue with Keras 3 model definitions or a custom `training_step` override.
How Atlas fixes TensorFlow production code with edits
Atlas fixes the underlying TensorFlow production code using its `edit` tool for small, focused changes, or `apply_patch` for more extensive modifications. This ensures that fixes, whether to a Keras 3 layer or a `tf.data` pipeline, are applied precisely and efficiently, often resolving issues within 1 or 2 attempts.
After confirming the hypothesis, Atlas proceeds to fix the production code. For minor adjustments, such as correcting a tensor shape in a Keras model or adjusting a parameter in a `tf.function`, Atlas uses its `edit` tool. This tool allows for precise, line-by-line modifications. If the required change spans multiple hunks or involves a more complex refactoring, Atlas utilizes `apply_patch`. This ensures that larger code modifications, perhaps to optimize a `tf.data` prefetch stage or to correct a custom `training_step` implementation, are applied as a unified patch, preventing brittle chained `edit` operations. Atlas always computes a unified diff for every file edit and surfaces it for approval, ensuring transparency and control over the proposed changes to your TensorFlow codebase.
Reviewing and committing TensorFlow changes with Atlas
Atlas ensures all TensorFlow code changes are reviewed and approved before committing, providing a robust safety net. Every Atlas tool call is permission-gated, and all proposed edits are presented as unified diffs, allowing developers to review 100% of the changes before they are written to disk.
Before writing any changes, Atlas operates with a strong emphasis on review and safety. Atlas drafts a plan in a read-only plan agent and asks for approval before switching to a build agent that can make modifications. Every Atlas tool call, including `edit` and `apply_patch`, is permission-gated against allow, ask, and deny rules. This means you explicitly approve each action. Atlas computes a unified diff for every file edit and surfaces it for your approval before writing. Once the fix is applied and approved, Atlas re-runs the single test to confirm the fix, then runs the full `pytest` suite to ensure no regressions were introduced. Finally, Atlas can stage and create commits on your behalf, and it snapshots file changes as git patches, allowing edits to be easily diffed and rolled back if needed, maintaining the integrity of your TensorFlow project managed by `uv` and formatted by `black`.
Step by step
- 01Ask Atlas to run the specific failing TensorFlow test in isolation using `pytest` via its `bash` tool, for example: `atlas bash 'pytest tensorflow/python/ops/my_test.py::MyTest::test_failing_feature'`.
- 02Instruct Atlas to `read` the failing test and the TensorFlow module it exercises, then use `lsp`'s `goToDefinition` and `findReferences` operations to trace the call path through `tf.function` or Keras 3 components.
- 03Guide Atlas to form a hypothesis and check it by using `edit` to add temporary `tf.print` or `print` logging statements in the TensorFlow code, or by re-running the test with verbose flags via `bash`.
- 04Approve Atlas's proposed `edit` to fix the production TensorFlow code; for larger changes spanning multiple hunks, approve `apply_patch` instead.
- 05Have Atlas re-run the single fixed TensorFlow test with `bash` to confirm the resolution.
- 06Ask Atlas to run the full `pytest` suite to ensure the fix has not introduced any regressions in your TensorFlow project.
- 07Instruct Atlas to `edit` and remove any temporary logging statements added during the debugging process, then approve the changes.
- 08Approve Atlas to stage and create a commit for the verified fix, ensuring your `pyproject.toml` project remains clean.
Frequently asked questions
- How does Atlas handle `tf.function` retracing warnings during debugging?
- Atlas can wrap hot Python loops in `tf.function` and explain the retracing warnings it removes. During debugging, Atlas can use its `bash` tool to run tests with specific TensorFlow environment variables that might suppress or highlight retracing warnings, helping to diagnose performance-related test failures.
- Can Atlas debug issues within `tf.data` pipelines?
- Yes, Atlas can debug `tf.data` pipeline issues. It can add `tf.data` prefetch and cache stages, measure step times, and use its `edit` tool to insert temporary `tf.print` operations within pipeline transformations to inspect data flow and identify bottlenecks or errors.
- What if my TensorFlow project uses a custom `training_step` in Keras 3?
- Atlas is designed to read your Keras model definitions and any custom `training_step` overrides. When debugging, Atlas will use its `lsp` tool to work through these custom implementations, allowing it to understand and propose fixes for issues specific to your Keras 3 training logic.
- How does Atlas ensure code quality after a fix in TensorFlow?
- After applying a fix, Atlas re-runs the single test and then the full `pytest` suite to prevent regressions. It also ensures code quality by formatting the diff with `black` before presenting it for approval, aligning with your project's `pyproject.toml` standards.
- Is Atlas compatible with my existing TensorFlow development environment?
- Yes, Atlas is terminal-native and designed to integrate direct. It runs in a project with a `pyproject.toml` that pins TensorFlow and Keras, uses `uv` for package management, and `black` for formatting, fitting directly into your established TensorFlow toolchain.
- How does Atlas's safety mechanism work for TensorFlow code changes?
- Atlas employs a robust safety mechanism: every tool call is permission-gated, and it drafts plans in a read-only agent before executing. All proposed file edits are presented as unified diffs for your explicit approval, and changes are snapshotted as git patches for easy rollback, ensuring full control over your TensorFlow codebase.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Debug a Single Failing Test with Atlas in 2026
How to debug one failing test with Atlas in 2026: run it in isolation with bash, walk the call graph with the lsp tool, and fix the code, not the assertion.
Atlas for TensorFlow: Terminal-Native AI Coding for Keras 3 and tf.data in 2026
Atlas is a terminal-native AI coding agent for TensorFlow and Keras 3 in 2026, where tf.function graph tracing and tf.data pipelines are what make training fast.
Research a third-party API before integrating it in TensorFlow with Atlas in 2026
Streamline TensorFlow API integration in 2026. Atlas helps developers research external APIs, fetch documentation, and verify against `pyproject.toml` conventions before writing code.
Write Unit Tests for Untested Code in TensorFlow with Atlas in 2026
Streamline writing unit tests for TensorFlow modules with Atlas. Learn how Atlas uses `pytest`, `uv`, and `black` to add robust tests, matching your repo's conventions in 2026.
Rename a symbol across the repo in TensorFlow with Atlas in 2026
In 2026, Atlas empowers TensorFlow developers to accurately rename functions, classes, or constants across their entire codebase, leveraging LSP, grep, and robust safety features. Ensure your Keras 3 models and tf.data
Plan a multi-file change before editing in TensorFlow with Atlas in 2026
Design and review multi-file TensorFlow changes with Atlas in 2026. Atlas's plan agent ensures no code is modified until your design is approved, integrating with pytest, uv, and black for a safe workflow.
Self-review your working diff before committing in TensorFlow with Atlas in 2026
TensorFlow developers in 2026 use Atlas to self-review uncommitted diffs, catching mistakes with `pytest`, `black`, and `uv` before code reaches CI or reviewers.
Automate GitHub Issue and Pull Request Triage in TensorFlow with Atlas in 2026
Streamline GitHub issue and pull request triage for TensorFlow projects using Atlas in 2026. Safely automate responses for trusted users, integrating with `uv`, `pytest`, and `black`.