How does Atlas ensure it finds every deprecated Kotlin API callsite?

Atlas combines the `lsp` tool's `findReferences` operation, which leverages the Kotlin Language Server's precise understanding of your `build.gradle.kts` project, with a comprehensive `grep` scan. This dual approach ensures both compiler-aware and dynamic/string-based usages of the deprecated Kotlin API are identified, leaving no callsite unaddressed.

Can Atlas handle complex Kotlin projects with multiple Gradle modules?

Yes, Atlas is designed for complex Kotlin projects. It reads your `build.gradle.kts` and `settings.gradle.kts` files to understand module structure. The `lsp` tool integrates with the language server, which is aware of your entire Gradle build, allowing Atlas to accurately find references and apply changes across all modules, including those with coroutine-based code.

What happens if a Kotlin file changes while Atlas is working on it?

Atlas's `apply_patch` tool is designed for safety. It uses context-anchored patches, meaning it expects specific `old_lines` to be present. If a Kotlin file has drifted or been modified concurrently, `apply_patch` will throw a `Failed to find expected lines` error, preventing incorrect changes. Atlas also provides unified diffs for every edit, requiring your approval before writing.

How does Atlas verify the correctness of the migrated Kotlin code?

After each file modification, Atlas uses its `bash` tool to run `gradle test`, executing your `JUnit 5` test suite. The `todowrite` entry for that callsite is only marked complete if all tests pass. This immediate, automated verification ensures that the new Kotlin API functions as expected and prevents regressions.

Does Atlas support Kotlin code formatting standards like ktlint?

Yes, Atlas can integrate with `ktlint`. While Atlas focuses on the migration logic, you can configure `bash` commands within your workflow to run `ktlint` after changes or before committing. Atlas also reads your `git` status and can stage and create commits, allowing you to incorporate `ktlint` into your pre-commit hooks or post-edit verification steps.

How does Atlas ensure my Kotlin code stays private and secure?

Atlas prioritizes privacy and security. It can build its code index with local Ollama embeddings, keeping your Kotlin code off third-party servers. Every Atlas tool call is permission-gated against allow, ask, and deny rules, and it drafts plans in a read-only agent, asking for approval before making any changes to your `.kt` files or `build.gradle.kts`.

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

Migrating a deprecated API across every callsite in a Kotlin codebase in 2026 is a job Atlas excels at, ensuring no caller is missed by leveraging the `lsp` tool's `findReferences` operation, tracking progress with `todowrite`, and verifying changes with `JUnit 5 via gradle test` and `ktlint`.

How Atlas Enumerates All Deprecated Kotlin API Callsites

In 2026, Atlas begins a deprecated Kotlin API migration by comprehensively enumerating all callsites, ensuring no usage is overlooked. It achieves this by integrating directly with the Kotlin Language Server Protocol (LSP) via its `lsp` tool, specifically using the `findReferences` operation.

Atlas leverages its `lsp` tool to query the language server for a complete list of references to the deprecated Kotlin symbol. This is crucial for projects with complex module structures defined in `build.gradle.kts` and `settings.gradle.kts`, as the LSP provides an accurate, compiler-aware view of the codebase. For dynamic or string-based usages that the LSP might miss, Atlas cross-checks with its `grep` tool, scanning the entire project for the deprecated symbol's name. This dual-pronged approach guarantees a robust enumeration, capturing every instance of the deprecated API, whether it's a direct function call in a `.kt` file or a string literal in a configuration.

Tracking Migration Progress for Kotlin Codebases with Atlas

To manage the migration of a deprecated Kotlin API across potentially hundreds of callsites, Atlas creates a `todowrite` entry for each identified instance. This structured approach, vital for large Kotlin projects in 2026, ensures partial progress is visible and no callsite is silently skipped.

After enumerating all callsites of the deprecated Kotlin API, Atlas uses its `todowrite` tool to generate a distinct entry for each one. This transforms the migration into a trackable project, allowing developers to see exactly which files and lines still require attention. For instance, if a deprecated `LegacyHttpClient.sendRequest()` function is used in `src/main/kotlin/com/example/ServiceA.kt` and `src/main/kotlin/com/example/ServiceB.kt`, Atlas will create separate `todowrite` entries for each, making the scope of work transparent. This granular tracking is especially beneficial in Kotlin projects that often involve coroutine-based code, where a single API change might ripple through many asynchronous operations, making visibility paramount.

Applying Changes and Ensuring Safety in Kotlin Migrations

Atlas migrates each deprecated Kotlin API callsite using its `apply_patch` tool, which applies changes as context-anchored patches. This method, critical for maintaining code integrity in 2026, ensures that edits fail explicitly rather than misapplying to a drifted file, protecting your `build.gradle.kts` project.

When migrating a deprecated Kotlin API, Atlas's `apply_patch` tool is designed for precision and safety. Instead of blindly replacing text, it seeks the hunk's context and `old_lines` within the target file. If the expected lines are not found due to a file drift or concurrent modification, `apply_patch` throws a `Failed to find expected lines` error. This prevents erroneous changes from being introduced into your Kotlin codebase. Before any modification, Atlas drafts a plan in a read-only plan agent and asks for approval. Every file edit generates a unified diff, which Atlas surfaces for explicit approval, ensuring developers retain full control over changes to their `.kt` files and `build.gradle.kts` configurations. Atlas also snapshots file changes as git patches, allowing for easy diffing and rollback if needed.

Verifying Kotlin API Migrations with Automated Testing

After each file modification during a deprecated Kotlin API migration, Atlas immediately runs the affected tests using `JUnit 5 via gradle test`. This crucial step, a standard practice in 2026, ensures that the replacement API functions correctly and prevents regressions before marking a `todowrite` entry complete.

Atlas integrates directly with the Kotlin build system to ensure the integrity of each migration step. After `apply_patch` modifies a `.kt` file to replace a deprecated API, Atlas uses its `bash` tool to execute `gradle test`. This command triggers `JUnit 5` tests relevant to the changed module, as defined in `build.gradle.kts`. Only when these tests pass successfully is the corresponding `todowrite` entry marked as completed. This immediate feedback loop is vital for complex Kotlin applications, especially those utilizing coroutines, where subtle changes can have far-reaching effects. If tests fail, Atlas provides the output, allowing the developer to inspect the issue and iterate on the fix, ensuring the new API integration is robust and error-free.

Finalizing and Cleaning Up Deprecated Kotlin APIs

To conclude a deprecated Kotlin API migration in 2026, Atlas performs a final `grep` for the old symbol, confirming zero remaining hits across the codebase. This rigorous verification ensures the deprecated API is fully removed, allowing for its safe deletion from your `build.gradle.kts` project.

Once all `todowrite` entries are marked complete and all tests pass, Atlas performs a final verification step. It uses its `grep` tool to scan the entire Kotlin project for any lingering instances of the deprecated symbol. This includes not just `.kt` files but also configuration files, documentation, or even comments that might still reference the old API. A clean `grep` result confirms that the migration is truly complete. At this point, Atlas can assist in deleting the old implementation, ensuring a clean codebase. Furthermore, Atlas can stage and create commits on your behalf, providing a clear audit trail for the entire migration process, which can be reviewed using standard `git diff` commands.

Step by step

01Run `atlas` in your Kotlin project with a `build.gradle.kts` file to allow Atlas to index your modules and Gradle configuration.
02Use `atlas lsp findReferences <deprecated_kotlin_symbol>` to enumerate all callsites of the deprecated API, cross-checking with `atlas grep <deprecated_kotlin_symbol>` for dynamic usages.
03Execute `atlas todowrite create --from-lsp-references` to generate a trackable task for each identified Kotlin callsite.
04For each `todowrite` entry, use `atlas apply_patch <patch_file>` to migrate the callsite, replacing the deprecated Kotlin API with its replacement. Atlas will present a unified diff for approval.
05After each `apply_patch`, run `atlas bash 'gradle test'` to execute `JUnit 5` tests for the affected Kotlin module. Mark the `todowrite` entry complete only if tests pass.
06Once all `todowrite` entries are complete, run `atlas grep <deprecated_kotlin_symbol>` one final time to confirm zero remaining hits in your Kotlin codebase.
07Delete the old deprecated Kotlin API implementation and use `atlas git commit` to stage and commit the changes, ensuring `ktlint` formatting is applied.

Frequently asked questions

How does Atlas ensure it finds every deprecated Kotlin API callsite?: Atlas combines the `lsp` tool's `findReferences` operation, which leverages the Kotlin Language Server's precise understanding of your `build.gradle.kts` project, with a comprehensive `grep` scan. This dual approach ensures both compiler-aware and dynamic/string-based usages of the deprecated Kotlin API are identified, leaving no callsite unaddressed.
Can Atlas handle complex Kotlin projects with multiple Gradle modules?: Yes, Atlas is designed for complex Kotlin projects. It reads your `build.gradle.kts` and `settings.gradle.kts` files to understand module structure. The `lsp` tool integrates with the language server, which is aware of your entire Gradle build, allowing Atlas to accurately find references and apply changes across all modules, including those with coroutine-based code.
What happens if a Kotlin file changes while Atlas is working on it?: Atlas's `apply_patch` tool is designed for safety. It uses context-anchored patches, meaning it expects specific `old_lines` to be present. If a Kotlin file has drifted or been modified concurrently, `apply_patch` will throw a `Failed to find expected lines` error, preventing incorrect changes. Atlas also provides unified diffs for every edit, requiring your approval before writing.
How does Atlas verify the correctness of the migrated Kotlin code?: After each file modification, Atlas uses its `bash` tool to run `gradle test`, executing your `JUnit 5` test suite. The `todowrite` entry for that callsite is only marked complete if all tests pass. This immediate, automated verification ensures that the new Kotlin API functions as expected and prevents regressions.
Does Atlas support Kotlin code formatting standards like ktlint?: Yes, Atlas can integrate with `ktlint`. While Atlas focuses on the migration logic, you can configure `bash` commands within your workflow to run `ktlint` after changes or before committing. Atlas also reads your `git` status and can stage and create commits, allowing you to incorporate `ktlint` into your pre-commit hooks or post-edit verification steps.
How does Atlas ensure my Kotlin code stays private and secure?: Atlas prioritizes privacy and security. It can build its code index with local Ollama embeddings, keeping your Kotlin code off third-party servers. Every Atlas tool call is permission-gated against allow, ask, and deny rules, and it drafts plans in a read-only agent, asking for approval before making any changes to your `.kt` files or `build.gradle.kts`.

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

In 2026, Atlas empowers Kotlin developers with terminal-native AI coding. It integrates with Gradle and coroutines, offering secure, privacy-focused code assistance with local embeddings and granular control.

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

Catch your own mistakes in uncommitted Kotlin diffs before review or CI with Atlas. Leverage ktlint, JUnit 5 via gradle test, and Gradle for robust self-review in 2026.

Atlas: Documenting Kotlin Modules with READMEs in 2026

Leverage Atlas in 2026 to generate accurate READMEs for your Kotlin modules. Atlas uses Gradle and JUnit 5 to document what your code actually does today, not what it was supposed to do a year ago.

Automate GitHub Issue and Pull Request Triage in Kotlin with Atlas in 2026

Automate GitHub issue and pull request triage in Kotlin with Atlas. Learn how Atlas integrates with Gradle and ktlint to safely manage PRs and issues for trusted users in 2026.

Rename a Symbol Across the Repo in Kotlin with Atlas (2026 Guide)

Rename a Kotlin class or function across every Gradle module with Atlas: lsp findReferences, grep, edit replaceAll, then JUnit 5 via gradle test and ktlint.

Plan a multi-file change before editing in Kotlin with Atlas (2026)

Plan a multi-file Kotlin change in 2026 before editing: Atlas's plan agent denies edit for every path except .atlas/plans/*.md, so build.gradle.kts stays untouched.

Run the test suite and triage the failures in Kotlin with Atlas (2026)

How Atlas runs a Kotlin test suite and triages failures in 2026: bash truncates at 2000 lines, retains the full log, and grep groups 60 red tests into distinct root causes.

Browse this resource hub