How does Atlas handle dynamic TensorFlow API calls that `lsp` might miss?

Atlas employs a hybrid approach. While `lsp findReferences` captures static calls, Atlas also uses `grep` to search for string-based or dynamically constructed usages of the deprecated TensorFlow API. This ensures comprehensive coverage, especially important for `tf.function` graphs or `tf.data` pipelines where symbols might be referenced as strings.

Can Atlas ensure my TensorFlow code remains formatted correctly during migration?

Yes, Atlas integrates with your existing TensorFlow toolchain. After applying changes, Atlas can format the modified code using `black`, your project's configured formatter. This ensures that all changes adhere to your codebase's style guidelines, maintaining consistency throughout the migration process.

What if a file changes while Atlas is in the middle of migrating a TensorFlow API?

Atlas's `apply_patch` tool is designed for safety. It uses context-anchored patches, meaning it will explicitly fail with a 'Failed to find expected lines' error if the target file has drifted or been modified since the initial analysis. This prevents misapplication of patches and ensures your TensorFlow code is never silently corrupted.

How does Atlas verify that the TensorFlow API migration hasn't introduced bugs?

Atlas integrates directly with your test runner. After each file modification, Atlas runs `pytest` via the `bash` tool on the affected tests. The `todowrite` entry for that callsite is only marked complete once `pytest` passes, providing immediate, granular verification that the change is functional and regression-free for your TensorFlow project.

Does Atlas require my TensorFlow code to be sent to a third-party server?

No, Atlas can build its code index with local Ollama embeddings, keeping your TensorFlow code entirely off third-party servers. This ensures that sensitive Keras model definitions, `tf.data` pipelines, and custom training logic remain within your local environment, adhering to strict privacy requirements.

How does Atlas ensure I review every change before it's applied to my TensorFlow codebase?

Atlas provides multiple layers of review. It drafts a plan in a read-only agent and asks for approval before executing. Every Atlas tool call is permission-gated, and for every file edit, Atlas computes and surfaces a unified diff for your explicit approval before writing any changes to your TensorFlow project files.

Migrate a Deprecated API Across Every Callsite in TensorFlow with Atlas in 2026

Atlas enables TensorFlow developers in 2026 to systematically migrate deprecated APIs across an entire codebase by enumerating all callsites, tracking progress with `todowrite`, applying changes with `apply_patch`, and verifying with `pytest` and `black`. This ensures no caller is missed and the codebase remains functional and well-formatted.

How to find all calls to a deprecated TensorFlow API with Atlas?

Atlas identifies every callsite of a deprecated TensorFlow API using a two-pronged approach, ensuring 100% coverage across your project. The `lsp` tool's `findReferences` operation provides a complete set of static references, while `grep` catches dynamic or string-based usages, crucial for complex `tf.function` graphs.

To initiate a migration in a TensorFlow project, Atlas first leverages the `lsp` tool to query the language server for all references to the deprecated symbol. This is particularly effective for statically typed Python code within TensorFlow, including Keras 3 model definitions or `tf.data` input pipelines. For instance, if `tf.compat.v1.placeholder` is deprecated, `atlas lsp findReferences tf.compat.v1.placeholder` will yield a comprehensive list of its direct callers. However, TensorFlow's dynamic nature, especially with `tf.function` graph tracing or string-based API calls, necessitates a secondary check. Atlas then cross-references these findings with `grep` to uncover any string literals or dynamically constructed calls that the language server might miss. This hybrid semantic and keyword retrieval, fused by reciprocal rank fusion, guarantees that every single callsite, from explicit imports to implicit string references in a `tf.data` transformation, is identified before any migration work begins.

How Atlas tracks deprecated TensorFlow API migration progress?

Atlas ensures no deprecated TensorFlow API callsite is overlooked by creating a dedicated `todowrite` entry for each identified instance. This granular tracking provides clear visibility into partial progress, allowing developers to see exactly how many of the 100+ potential callsites remain to be migrated at any given moment.

Once all callsites of the deprecated TensorFlow API are enumerated, Atlas uses the `todowrite` tool to create a distinct, trackable entry for each one. This approach transforms the daunting task of migrating an entire codebase into a manageable series of discrete, verifiable steps. For example, if `tf.nn.rnn_cell.BasicRNNCell` is being replaced, Atlas will generate a `todowrite` item for every file and line where it's used. This means that as you work through the migration, you can always see the remaining scope of work. Partial progress is immediately visible, preventing any callsite from being silently skipped or forgotten, which is critical for maintaining the integrity of complex TensorFlow models and `tf.data` pipelines.

How Atlas safely migrates TensorFlow API calls and ensures review?

Atlas applies changes to TensorFlow code with robust safety mechanisms, generating a unified diff for every file edit and requiring explicit approval. The `apply_patch` tool is context-anchored, meaning it will fail rather than misapply a change if the file has drifted, providing a 100% guarantee against unintended modifications.

Migrating deprecated TensorFlow APIs with Atlas is a secure and reviewable process. When Atlas proposes a change to a callsite, it uses the `apply_patch` tool, which is designed for precision. This tool seeks the exact hunk's context and `old_lines` within the target file. If the file has been modified or 'drifted' since the initial enumeration, `apply_patch` will throw a 'Failed to find expected lines' error instead of attempting a potentially incorrect modification. This prevents silent corruption of your TensorFlow code. Before any changes are written, Atlas computes a unified diff for every proposed file edit and surfaces it for your approval. All Atlas tool calls, including `apply_patch`, are permission-gated against `allow`, `ask`, and `deny` rules, and the initial plan is drafted in a read-only plan agent. This multi-layered review process ensures that every modification to your `pyproject.toml` pinned TensorFlow and Keras project is intentional and verified.

How to verify TensorFlow API migrations with `pytest` and `black`?

After each file modification during a TensorFlow API migration, Atlas automatically runs the affected tests using `pytest` via a `bash` command. This immediate feedback loop ensures that the change hasn't introduced regressions, and the `todowrite` entry is marked complete only after all 0 new test failures are confirmed and the code is formatted with `black`.

Verification is a cornerstone of Atlas's migration workflow for TensorFlow. After `apply_patch` modifies a file to replace a deprecated API, Atlas immediately executes the relevant tests. This is achieved by running `pytest` through the `bash` tool, for example, `atlas bash pytest path/to/affected_test.py`. This ensures that each individual change maintains the expected behavior of your TensorFlow models, `tf.data` pipelines, or custom `training_step` overrides. Only once these tests pass successfully is the corresponding `todowrite` entry marked as completed. Furthermore, Atlas can format the diff with `black` before presenting it for approval, ensuring code style consistency. The final step involves a comprehensive `grep` for the deprecated symbol across the entire codebase, confirming zero remaining hits, and then safely deleting the old implementation. This rigorous, step-by-step verification process guarantees a clean and functional migration.

Step by step

01Enumerate all callsites of the deprecated TensorFlow symbol using `atlas lsp findReferences <symbol_name>` and cross-check with `atlas grep -r '<symbol_name>' .` for dynamic usages.
02Create a `todowrite` entry for each identified callsite, ensuring every instance of the deprecated TensorFlow API is tracked.
03Migrate each callsite by drafting a change with Atlas and applying it using `atlas apply_patch`, reviewing the unified diff for accuracy.
04After each file modification, run the affected TensorFlow tests using `atlas bash pytest path/to/modified_file_tests.py` to verify functionality.
05Mark the `todowrite` entry as completed only after the `pytest` suite passes without regressions.
06Ensure code style consistency by having Atlas format the changes with `black` before committing.
07Perform a final verification by running `atlas grep -r '<deprecated_symbol>' .` to confirm zero remaining hits of the deprecated TensorFlow API.
08Delete the old TensorFlow API implementation once all callsites are migrated and verified.

Frequently asked questions

How does Atlas handle dynamic TensorFlow API calls that `lsp` might miss?: Atlas employs a hybrid approach. While `lsp findReferences` captures static calls, Atlas also uses `grep` to search for string-based or dynamically constructed usages of the deprecated TensorFlow API. This ensures comprehensive coverage, especially important for `tf.function` graphs or `tf.data` pipelines where symbols might be referenced as strings.
Can Atlas ensure my TensorFlow code remains formatted correctly during migration?: Yes, Atlas integrates with your existing TensorFlow toolchain. After applying changes, Atlas can format the modified code using `black`, your project's configured formatter. This ensures that all changes adhere to your codebase's style guidelines, maintaining consistency throughout the migration process.
What if a file changes while Atlas is in the middle of migrating a TensorFlow API?: Atlas's `apply_patch` tool is designed for safety. It uses context-anchored patches, meaning it will explicitly fail with a 'Failed to find expected lines' error if the target file has drifted or been modified since the initial analysis. This prevents misapplication of patches and ensures your TensorFlow code is never silently corrupted.
How does Atlas verify that the TensorFlow API migration hasn't introduced bugs?: Atlas integrates directly with your test runner. After each file modification, Atlas runs `pytest` via the `bash` tool on the affected tests. The `todowrite` entry for that callsite is only marked complete once `pytest` passes, providing immediate, granular verification that the change is functional and regression-free for your TensorFlow project.
Does Atlas require my TensorFlow code to be sent to a third-party server?: No, Atlas can build its code index with local Ollama embeddings, keeping your TensorFlow code entirely off third-party servers. This ensures that sensitive Keras model definitions, `tf.data` pipelines, and custom training logic remain within your local environment, adhering to strict privacy requirements.
How does Atlas ensure I review every change before it's applied to my TensorFlow codebase?: Atlas provides multiple layers of review. It drafts a plan in a read-only agent and asks for approval before executing. Every Atlas tool call is permission-gated, and for every file edit, Atlas computes and surfaces a unified diff for your explicit approval before writing any changes to your TensorFlow project files.

Try Atlas in your terminal

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

Install Atlas

Related guides

Migrate a Deprecated API Across Every Callsite with Atlas (2026 Workflow)

How to migrate a deprecated API across every callsite with Atlas in 2026: the lsp tool's findReferences enumerates callers, todowrite tracks them, apply_patch migrates each one.

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.

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.

Audit a TensorFlow Repository with Parallel Subagents in Atlas (2026)

Sweep your TensorFlow and Keras 3 codebase for issues without context window limits. Atlas uses parallel subagents and real tools like pytest and black for efficient, safe audits.

Locate TensorFlow Behavior Implementations with Atlas in 2026

Find the exact file and symbol for TensorFlow behaviors using Atlas. Leverage semantic search, `grep`, and LSP tools to pinpoint code in Keras 3 and `tf.function` contexts.

Document a TensorFlow Module with a README in 2026

Atlas helps TensorFlow developers in 2026 generate accurate READMEs by reading live code, using `lsp` for APIs, and `bash` to verify samples. Ensure your TensorFlow documentation reflects current implementation, not

Onboard to an Unfamiliar Codebase in TensorFlow with Atlas in 2026

Quickly build a mental model of any TensorFlow repository in 2026 using Atlas. Leverage semantic search, safe exploration, and direct interaction with `pytest`, `uv`, and `black`.

Browse this resource hub