# Extract a Shared Helper from Duplicated Axum Code in 2026 > Atlas helps Axum developers collapse duplicated logic into one tested helper by semantically searching for copies and automating the refactoring process. To extract a shared helper from duplicated code in your Axum application, Atlas leverages semantic search with `codebase_search` to identify near-identical logic, even with differing variable names. It then uses `write` to create the new helper module and `apply_patch` to replace each duplicate with a call, ensuring your `cargo nextest` suite passes and `rustfmt` maintains code style throughout the process. This workflow helps Axum developers maintain clean, efficient codebases. ## Key takeaways - Atlas uses semantic search to find duplicated Axum code that `grep` would miss. - Refactoring is performed with reviewable, file-specific patches for safety and control. - Your `cargo nextest` test runner and `rustfmt` formatter are integrated into the workflow. - Atlas keeps your Axum code local by building its code index with Ollama embeddings. - Every Atlas tool call is permission-gated, ensuring you approve all code modifications. ## How to Find Duplicated Axum Logic with Semantic Search Finding duplicated logic in Axum handlers is a critical first step, and Atlas's `codebase_search` tool excels here by using semantic retrieval, not just keyword matching. This means it can identify 10 instances of the same behavior across your codebase, even if variable names or minor structural elements differ, a task `grep` would typically miss. Traditional text-based search tools like `grep` often fail to identify functionally identical code blocks when variable names, comments, or whitespace vary. For Axum developers, this is particularly relevant in `async fn` handlers or `tower::Service` implementations where the core logic might be identical but wrapped in different `Extractor` arguments or `State` types. Atlas's `codebase_search` overcomes this by indexing your code using AST declarations via tree-sitter and combining it with local Ollama embeddings for hybrid semantic and keyword retrieval. You can ask Atlas to 'find Axum handler logic for user authentication' or 'show me implementations of request validation' to surface near-duplicate implementations across files like `src/handlers/user.rs` and `src/admin/mod.rs`. This semantic understanding is crucial for identifying all instances of a behavior that should be collapsed into a single, tested helper. ## Creating a New Axum Helper Module for Shared Logic Once duplicated Axum logic is identified, creating a new shared helper module is the next logical step. Atlas's `write` tool allows you to draft this new Rust file, for example, `src/utils/auth_helpers.rs`, and review the full diff before it's created. This ensures the new module adheres to your project's structure and contains the 100% correct shared functionality. After confirming that several code blocks are genuinely equivalent and suitable for extraction, you'll use Atlas's `write` tool to create the new Rust module. For an Axum project, this might involve creating a new file like `src/utils/request_validation.rs` or `src/middleware/auth_extractor.rs`. The `write` tool presents a unified diff of the proposed file creation, allowing you to inspect every line before it's written to disk. This is vital for ensuring the new helper function correctly handles common Axum patterns, such as accepting `State` or `Extractor` arguments, and returns an `impl IntoResponse` for error handling. If the helper requires new dependencies, you would manually update `Cargo.toml` and then let Atlas proceed with the file creation, ensuring the new module is ready to be called by your existing Axum handlers. ## Replacing Duplicates with Helper Calls in Axum Handlers Replacing each instance of duplicated Axum code with a call to your new helper is a precise operation, and Atlas's `apply_patch` tool handles this with granular control. It generates one reviewable patch per file, allowing you to approve each swap independently. This ensures that a change in `src/handlers/user.rs` is reviewed separately from `src/admin/dashboard.rs`, providing maximum safety and clarity for 2026 development teams. With the shared helper module in place, the next step is to refactor your existing Axum handlers. Atlas's `apply_patch` tool is designed for this. Instead of a single, monolithic patch, Atlas creates a distinct, reviewable patch for each file where a duplicate is replaced. For example, if `src/handlers/user.rs` and `src/admin/mod.rs` both contained the duplicated logic, Atlas would generate two separate patches. This allows you to meticulously review how the original `async fn` handler logic, potentially involving `Extractor` arguments or `State` access, is replaced by a clean call to your new helper function. This granular approach minimizes risk, making it easy to revert a single file's changes if an issue arises, without affecting other successful refactorings. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, giving you full control. ## Ensuring Axum Code Quality and Test Coverage Post-Refactoring Maintaining the integrity of your Axum application is paramount during refactoring, which is why Atlas integrates directly with your existing toolchain. After every `apply_patch` operation, Atlas can run `cargo nextest run` to execute your test suite and `rustfmt` to ensure code style consistency. This proactive approach catches regressions immediately, ensuring your 2026 Axum project remains robust and well-formatted. A critical aspect of any refactoring is verifying that the changes haven't introduced regressions or style violations. Atlas addresses this by allowing you to execute arbitrary `bash` commands after each `apply_patch` operation. For Axum projects, this means you can immediately run `cargo nextest run` to execute your comprehensive test suite. If any tests fail, Atlas will surface the output, allowing you to address the issue before proceeding. Furthermore, you can run `rustfmt src/path/to/file.rs` to automatically format the modified file, ensuring it adheres to your project's coding standards. This iterative process,replace, test, format, approve,ensures that each step of extracting the shared helper maintains the high quality and reliability expected in a production Axum codebase. Finally, a `grep` for any surviving copies of the original logic provides a final verification step. ## Steps 1. Ask Atlas to semantically search for the behavior you want to extract, for example: `atlas codebase_search "Axum handler logic for validating user input"`. 2. Read each `codebase_search` hit using `atlas read src/handlers/user_create.rs` to confirm the code blocks are genuinely equivalent and suitable for a shared helper. 3. Create the new shared helper module using `atlas write src/utils/validation_helpers.rs`, reviewing the full diff before the file is created. 4. Replace the first duplicate with a call to the new helper using `atlas apply_patch src/handlers/user_create.rs`, reviewing the file-specific patch. 5. Run your Axum test suite and formatter: `atlas bash "cargo nextest run && rustfmt src/handlers/user_create.rs"` to ensure no regressions and maintain style. 6. Replace the next duplicate in another file, for example: `atlas apply_patch src/handlers/admin_update.rs`, reviewing its independent patch. 7. Repeat the test and format step for the newly patched file: `atlas bash "cargo nextest run && rustfmt src/handlers/admin_update.rs"`. 8. Finish by grepping for any surviving copies of the original logic: `atlas grep -r "original_validation_logic_pattern" src/`. ## FAQ ### How does Atlas find duplicated Axum code that `grep` misses? Atlas finds duplicated Axum code by indexing your codebase using AST declarations via tree-sitter and combining it with local Ollama embeddings for hybrid semantic and keyword retrieval. This allows it to understand the meaning and structure of code, identifying functionally identical blocks even if variable names, comments, or `Extractor` arguments differ, which `grep` cannot do. ### Can Atlas handle Axum handlers with different `State` types or `Extractor` arguments? Yes, Atlas's semantic understanding allows it to recognize the core logic even when Axum handlers use different `State` types or `Extractor` arguments. When creating the shared helper, you can define its signature to accept generic parameters or specific types as needed, and Atlas will assist in correctly replacing the calls, ensuring trait bounds are satisfied. ### What if the extracted helper needs new dependencies in `Cargo.toml`? If your new Axum helper requires new dependencies, you would manually add them to your `Cargo.toml` file. Atlas focuses on code modification and creation. After updating `Cargo.toml`, you can then proceed with using `atlas write` to create the helper and `atlas apply_patch` to integrate it, ensuring `cargo nextest` can compile and run your tests. ### How does Atlas ensure the refactored Axum code still passes tests? Atlas ensures code integrity by allowing you to run your `cargo nextest run` command after every `apply_patch` operation via the `atlas bash` tool. This immediate feedback loop catches any regressions introduced by the refactoring, allowing you to address them before committing changes. You approve each step, ensuring the test suite remains green. ### Is it safe to let Atlas modify my Axum codebase? Yes, Atlas is designed with safety in mind. Every Atlas tool call is permission-gated, requiring your explicit approval before execution. It drafts a plan in a read-only agent, computes a unified diff for every file edit, and surfaces it for approval before writing. Additionally, `apply_patch` creates one reviewable patch per file, making changes granular and easily revertible. ### Can I roll back changes if the refactoring introduces issues in my Axum project? Absolutely. Atlas snapshots file changes as git patches, so edits can be diffed and rolled back easily. Since `apply_patch` creates one reviewable patch per file, you can revert individual file changes without affecting other successful refactorings. This granular control, combined with `git` integration, provides robust rollback capabilities for your Axum project. --- Canonical HTML: https://runatlas.sh/resources/stacks/extract-a-shared-helper-from-duplicated-code-in-axum Source of truth: aeo_pages row `/resources/stacks/extract-a-shared-helper-from-duplicated-code-in-axum` (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.