How does Atlas ensure it finds *all* Scala calls to a deprecated API?

Atlas combines `lsp findReferences` for AST-based symbol resolution with `grep` for dynamic or string-based usages, ensuring a complete enumeration of all Scala calls, even in complex `build.sbt` projects.

What happens if a Scala file changes while Atlas is migrating it?

Atlas's `apply_patch` tool uses context-anchored patches. If the expected `old_lines` or surrounding context in a Scala file has drifted, `apply_patch` will fail with 'Failed to find expected lines' rather than misapplying changes, ensuring data integrity.

Can Atlas run my existing Scala tests after a migration?

Yes, Atlas uses the `bash` tool to execute `sbt test` after each file modification. It only marks a `todowrite` entry as complete once `ScalaTest` passes, ensuring the codebase remains functional throughout the migration.

How does Atlas handle reviewing changes before writing to Scala files?

Atlas drafts a plan in a read-only agent, computes a unified diff for every file edit, and surfaces it for your approval. Every tool call is permission-gated, giving you full control over changes to your Scala codebase.

Is Atlas compatible with my `sbt` project structure?

Absolutely. Atlas is designed to work direct with Scala projects built with `sbt`. It reads your `build.sbt` and understands your traits, implicits, and sbt modules to provide accurate refactoring and migration capabilities.

What if I need to roll back a change made by Atlas in Scala?

Atlas snapshots file changes as git patches, allowing edits to be easily diffed and rolled back. It also reads git branches, status, and diffs, and can stage and create commits on your behalf for robust version control.

Does Atlas keep my Scala code local?

Yes, Atlas can build its code index with local Ollama embeddings, keeping your Scala code off third-party servers. This ensures your proprietary code remains secure and private during the migration process.

Migrate a deprecated API across every callsite in Scala with Atlas in 2026

To migrate a deprecated API across every callsite in a Scala codebase, Atlas enumerates all callers using `lsp findReferences`, creates a `todowrite` entry for each, and applies context-anchored patches, verifying changes with `ScalaTest via sbt test` through `sbt` before committing. This ensures a complete and safe transition for your Scala project in 2026.

How to find all deprecated API calls in Scala with Atlas

Atlas ensures a complete enumeration of deprecated API calls in Scala by combining `lsp findReferences` with `grep`, leaving zero calls missed. In 2026, this hybrid approach guarantees that even dynamic or string-based usages within your `build.sbt` project are identified, providing a robust starting point for migration.

Migrating a deprecated API across an entire Scala codebase begins with a precise enumeration of every callsite. Atlas leverages its `lsp` tool, which uses tree-sitter to build an AST-based index of your code, allowing `lsp findReferences` to yield a complete set of callers for a given deprecated symbol. This is crucial for Scala projects, where complex type hierarchies, implicits, and traits can make manual enumeration error-prone. For any potential dynamic or string-based usages that might evade static analysis, Atlas cross-checks the `lsp` results with its `grep` tool. This dual-pronged approach ensures that every single reference to the deprecated API, whether in a `.scala` file or a configuration within `build.sbt`, is identified and accounted for, preventing half-measures and ensuring a truly comprehensive migration.

Track deprecated API migration progress in Scala projects

Managing the migration of a deprecated Scala API across potentially hundreds of files requires clear visibility into progress. Atlas addresses this by creating one `todowrite` entry per callsite, ensuring that partial progress is always visible and no single call is silently skipped. This structured approach is vital for large Scala codebases in 2026.

Once all calls to the deprecated Scala API have been enumerated, Atlas transforms this list into actionable work items using its `todowrite` tool. For each identified callsite, a distinct `todowrite` entry is created. This granular tracking mechanism is essential for large-scale migrations in Scala, where many files and modules might be affected. It provides a clear, visible record of progress, allowing developers to see which callsites have been addressed and which still require attention. This prevents the common pitfall of silently skipping a callsite or losing track of partial progress, ensuring that the migration remains organized and complete from start to finish.

How Atlas applies safe code changes for Scala API migrations

Atlas applies code changes for Scala API migrations with high precision using its `apply_patch` tool, which seeks the hunk's context and `old_lines` before writing. This context-anchored patching mechanism ensures that if a file has drifted, `apply_patch` will fail rather than misapplying changes, providing a critical safety net for your Scala codebase in 2026.

The core of the migration process involves safely modifying each identified Scala callsite. Atlas employs its `apply_patch` tool for this, which is designed for robust and context-aware code modifications. Unlike simple line-based replacements, `apply_patch` seeks out the specific context and `old_lines` of the code hunk it intends to modify. This means that if a Scala source file (`.scala`) has drifted or been altered since the initial enumeration, `apply_patch` will throw a 'Failed to find expected lines' error instead of guessing or misapplying the patch. This strict validation prevents unintended side effects and ensures that every change to your Scala code is applied precisely where intended, maintaining the integrity of your project. Atlas also computes a unified diff for every file edit and surfaces it for approval before writing, giving you full control.

Automated testing for Scala API migrations with Atlas and sbt

After each file modification during a Scala API migration, Atlas automatically runs the affected tests using `bash -c "sbt test"`. This immediate verification step, powered by `ScalaTest` through `sbt`, ensures that the codebase remains functional and stable. Only once `ScalaTest` passes is the corresponding `todowrite` entry marked complete, providing robust, continuous validation in 2026.

A critical aspect of any large-scale refactoring in Scala is continuous testing. Atlas integrates this directly into the migration workflow. After `apply_patch` modifies a Scala file, Atlas uses its `bash` tool to execute the project's test suite. Specifically, it runs `sbt test`, which invokes `ScalaTest` to verify the changes. This immediate feedback loop is invaluable: if a migration step introduces a regression, `ScalaTest` will fail, and Atlas will not mark the `todowrite` entry for that callsite as complete. This ensures that each individual change is validated against your existing test suite, preventing the accumulation of errors and guaranteeing that your Scala codebase remains in a working state throughout the entire migration process. This granular, per-file testing approach minimizes risk and simplifies debugging.

Confirm complete Scala API migration and cleanup

To finalize a deprecated Scala API migration, Atlas performs a final `grep` for the deprecated symbol, confirming zero remaining hits across the codebase. This crucial step ensures that no callsite was missed, allowing for the safe deletion of the old implementation. This comprehensive cleanup process is a hallmark of a successful migration in 2026.

The migration workflow concludes with a definitive verification and cleanup phase. Once all `todowrite` entries are marked complete and all tests have passed, Atlas performs a final `grep` for the deprecated symbol across the entire Scala codebase. This serves as a robust double-check, confirming that every single instance of the old API has been successfully replaced. Only when this `grep` yields zero remaining hits can you confidently proceed to delete the old implementation of the deprecated function or module. This final confirmation step, combined with Atlas's ability to read git branches and create commits, ensures that your Scala project is left in a clean, fully migrated state, ready for future development without legacy dependencies.

Reviewing and approving Atlas code changes for Scala

Atlas provides a transparent and controlled process for reviewing code changes in Scala, presenting a unified diff for every file edit before writing. Every Atlas tool call is permission-gated against allow, ask, and deny rules, ensuring you maintain full control over your Scala codebase. This robust review mechanism is a key safety feature in 2026.

Throughout the migration process, Atlas prioritizes developer control and safety. Before any changes are written to your Scala files, Atlas computes a unified diff for every proposed edit and surfaces it for your approval. This allows you to meticulously review exactly what changes Atlas intends to make, line by line, within your `.scala` files. Furthermore, every Atlas tool call, from `lsp` to `apply_patch` and `bash`, is permission-gated against configurable allow, ask, and deny rules. Atlas drafts its plan in a read-only plan agent and explicitly asks for permission before switching to a build agent to execute changes. This multi-layered approval system ensures that you, the Scala developer, are always in command, with the ability to inspect, approve, or reject any proposed modification to your codebase.

Step by step

01Enumerate every call to the deprecated Scala symbol using `lsp findReferences` and cross-check with `grep` for dynamic usages across your `build.sbt` project.
02Create one `todowrite` entry for each identified Scala callsite, ensuring partial progress is visible and nothing is silently skipped.
03Migrate each Scala callsite with `apply_patch`; it seeks the hunk's context and `old_lines` and throws 'Failed to find expected lines' rather than guessing.
04After each file modification, run the affected tests with `bash -c "sbt test"` and mark the `todowrite` entry complete only once `ScalaTest` passes.
05Once all `todowrite` entries are complete, perform a final `grep` for the deprecated Scala symbol to confirm zero remaining hits.
06Delete the old Scala implementation of the deprecated API from your project.
07Review the unified diffs generated by Atlas for all Scala file edits and approve the changes.
08Let Atlas stage the changes and create a git commit on your behalf for the completed Scala API migration.

Frequently asked questions

How does Atlas ensure it finds *all* Scala calls to a deprecated API?: Atlas combines `lsp findReferences` for AST-based symbol resolution with `grep` for dynamic or string-based usages, ensuring a complete enumeration of all Scala calls, even in complex `build.sbt` projects.
What happens if a Scala file changes while Atlas is migrating it?: Atlas's `apply_patch` tool uses context-anchored patches. If the expected `old_lines` or surrounding context in a Scala file has drifted, `apply_patch` will fail with 'Failed to find expected lines' rather than misapplying changes, ensuring data integrity.
Can Atlas run my existing Scala tests after a migration?: Yes, Atlas uses the `bash` tool to execute `sbt test` after each file modification. It only marks a `todowrite` entry as complete once `ScalaTest` passes, ensuring the codebase remains functional throughout the migration.
How does Atlas handle reviewing changes before writing to Scala files?: Atlas drafts a plan in a read-only agent, computes a unified diff for every file edit, and surfaces it for your approval. Every tool call is permission-gated, giving you full control over changes to your Scala codebase.
Is Atlas compatible with my `sbt` project structure?: Absolutely. Atlas is designed to work direct with Scala projects built with `sbt`. It reads your `build.sbt` and understands your traits, implicits, and sbt modules to provide accurate refactoring and migration capabilities.
What if I need to roll back a change made by Atlas in Scala?: Atlas snapshots file changes as git patches, allowing edits to be easily diffed and rolled back. It also reads git branches, status, and diffs, and can stage and create commits on your behalf for robust version control.
Does Atlas keep my Scala code local?: Yes, Atlas can build its code index with local Ollama embeddings, keeping your Scala code off third-party servers. This ensures your proprietary code remains secure and private during the migration process.

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 Scala in 2026

Atlas is a terminal-native AI coding agent for Scala in 2026. Run it in a project with a build.sbt, let it read your traits and implicits, and approve every diff.

Run Atlas Headless in CI for Scala Projects in 2026

Automate Atlas sessions in your Scala CI pipelines in 2026. Get machine-readable output for sbt projects, pre-approve tools, and integrate with ScalaTest.

Audit a Scala Repo with Parallel Subagents in Atlas, 2026

In 2026, Scala developers use Atlas to sweep entire repositories for code problems without context window limits. Launch parallel subagents for efficient, read-only audits of Scala projects.

Refactor a Legacy Scala Module with Atlas in 2026

Streamline legacy Scala modules in 2026 with Atlas. Safely refactor code, ensure no behavior changes, and maintain caller compatibility using sbt, ScalaTest, and scalafmt.

Extract a shared helper from duplicated code in Scala with Atlas in 2026

Refactor Scala code efficiently in 2026 by extracting shared helpers from duplicated logic using Atlas. Leverage semantic search, `sbt test`, and `scalafmt` for safe, reviewable changes.

Review a Pull Request in Scala with Atlas in 2026

Streamline Scala pull request reviews in 2026 with Atlas. Leverage sbt, ScalaTest, and scalafmt for deep context, catching bugs a line-by-line diff misses.

Onboard to an Unfamiliar Scala Codebase with Atlas (2026)

Build a mental model of a Scala repo without reading every file. Atlas starts from meaning in 2026 with codebase_search and glob, and delegates sweeps to a read-only subagent.

Browse this resource hub