why does Atlas use one apply_patch per file instead of one big patch?

One patch per file keeps each swap independently reviewable and revertible. A single large patch is approved as a lump, which is not a real review. With apply_patch scoped to a file, the diff you approve is the deleted copy, the new import, and the new call.

how do I undo a bad helper extraction in Atlas?

Atlas snapshots file changes as git patches, so edits can be diffed and rolled back. A swap that turns out to be wrong is restored from the snapshot rather than reverted by hand across every caller you touched.

when should I run the tests during a deduplication refactor?

Run the suite with bash after every apply_patch swap, not once at the end. Testing per swap attributes a failure to the exact callsite that caused it. Running once after twelve swaps tells you only that something in the batch broke.

how do I confirm every copy of the duplicated logic is gone?

Finish the workflow with a grep for the old code's fingerprints, such as a distinctive constant or a rare method call the duplicated block used. Zero hits means the collapse is complete. Any remaining hit means a copy was never confirmed or never swapped.

can Atlas plan a refactor before it changes anything?

Yes. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, so you can see the full extraction sequence, including which files write and apply_patch will touch, before any file is modified.

Extract a Shared Helper from Duplicated Code with Atlas (2026 Workflow)

To find the same logic copy-pasted across several files and collapse it into one tested helper with Atlas, ask codebase_search for the behavior rather than the exact code, because duplication is a semantic problem, not a textual one: the copies usually differ in variable names. Read each hit to confirm the copies are genuinely equivalent, create the shared helper with write, then replace each duplicate with a call using apply_patch, one file per patch. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so no swap lands without you seeing it. Finish by running the suite with bash after every swap and grepping for any surviving copy.

How does Atlas extract a shared helper from duplicated code?

Atlas extracts a shared helper in 5 documented steps: codebase_search finds the near-duplicate implementations by behavior, read confirms they are genuinely equivalent, write creates the new shared module, apply_patch swaps each copy for a call, and bash runs the suite after every single swap.

The order matters because each step de-risks the next. Asking codebase_search for the behavior instead of the exact duplicated code produces a candidate set of copies. Reading each hit turns that candidate set into a confirmed set of true duplicates, which is the only set worth collapsing into a shared helper. Only then does write create the helper, and only then does apply_patch begin swapping the duplicated copies for calls. Atlas is permission-gated and diff-reviewed by design, so the human sits at every write and every patch. The deduplication never runs ahead of the person approving it.

Why codebase_search finds duplicates that grep misses

Duplicated code usually differs by variable name, so a grep for an exact string finds 1 copy and misses the other 4. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, and codebase_search asks for the behavior, surfacing near-duplicate implementations a literal pattern match would never rank.

Atlas indexes code by AST declarations using tree-sitter, not blind line windows, so a codebase_search hit comes back as a whole duplicated function rather than an arbitrary slice of lines that happened to contain the token. That is what makes a duplication query answerable: you describe what the copied logic does, such as normalizing a phone number or retrying a request with backoff, and codebase_search returns the declarations that do it, whatever their local variable names happen to be. Grep still has a job in a deduplication refactor, but it comes at the end, not the start.

How Atlas creates the shared module with the write tool

Atlas creates the shared module with the write tool, and write shows the full diff in the permission prompt before the file is created. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so the new helper file in 2026 exists only after you approve it.

The helper Atlas writes is assembled from the confirmed copies you read, so its signature has to cover the union of what the callers actually needed, not the narrowest case. Review the write diff for exactly that: the parameter list, the default behavior, and whether the helper quietly changed semantics for one of the callers. Rejecting the write costs nothing and no file is created. Approving it creates one file, and the swaps that follow are separate approvals.

How apply_patch replaces each duplicate one file at a time

Atlas replaces each duplicate with a call to the new helper using apply_patch, one file per patch, so each of the 5 or 50 swaps is independently reviewable and revertible. Atlas snapshots file changes as git patches, so any single swap can be diffed and rolled back without unwinding the rest.

One patch per file is a deliberate constraint. A single mega-patch across a dozen callers is approved or rejected as a lump, and a lump is not reviewable. With apply_patch scoped to one file, the diff in front of you is small enough to actually read: the deleted copy, the new import, the new call. Atlas runs the suite with bash after every swap, so a break is attributed to the swap that caused it instead of surfacing at the end of a batch of twelve.

Where do you approve Atlas's changes during a helper extraction?

Atlas gives you 2 approval points during a helper extraction: every tool call is permission-gated against allow, ask, and deny rules before it runs, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing. Nothing in the extraction lands silently.

In practice, codebase_search, read, and grep are the cheap read-only steps most people put on allow, since they cannot change anything. The write that creates the helper and each apply_patch that swaps a caller are the steps worth an ask rule, because those are the steps that mutate the repo. The bash runs that execute the test suite are the third category, and they are usually where teams draw their own line. Atlas can also draft the whole extraction in a read-only plan agent and ask before switching to a build agent.

How do you verify no duplicate copies survive the refactor?

After the last swap, Atlas runs the suite with bash and then greps for any surviving copy of the duplicated logic. The final grep is the check that matters: one stale copy left behind in 2026 means the new helper is simply a fourth implementation rather than the only one.

The tail grep looks for the fingerprints of the old code: a distinctive constant, a magic string, a rare method call that only the duplicated block used. Zero hits means the collapse is complete. Non-zero hits means codebase_search surfaced a copy you did not confirm, or a copy exists in a file type the search skipped. Because Atlas snapshots file changes as git patches, an extraction that turns out to be wrong is rolled back from the snapshot rather than hand-reverted file by file.

Step by step

01Ask codebase_search for the behavior, not the exact code, so it surfaces near-duplicate implementations that grep would miss because the copies differ in variable names.
02Read each hit with the read tool and confirm the copies are genuinely equivalent before collapsing them, since a near-duplicate that is not actually equivalent is a bug waiting to be introduced.
03Create the shared helper with the write tool, which shows the full diff in the permission prompt before the file is created, and approve or reject it there.
04Replace each duplicate with a call using apply_patch, one file per patch, so each swap is independently reviewable and revertible.
05Run the suite with bash after every swap, so a failure is attributed to the swap that caused it rather than to the batch.
06Finish by grepping for any surviving copy of the old logic, and confirm zero hits before you call the extraction done.

Frequently asked questions

how do I find duplicated code that grep can't catch: Use Atlas's codebase_search and describe the behavior rather than the literal code. Atlas searches with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so it surfaces near-duplicate implementations even when the copies use different variable names.
does Atlas edit files without asking during a refactor?: No. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing. The write that creates the helper and every apply_patch that swaps a caller are both approval points.
why does Atlas use one apply_patch per file instead of one big patch?: One patch per file keeps each swap independently reviewable and revertible. A single large patch is approved as a lump, which is not a real review. With apply_patch scoped to a file, the diff you approve is the deleted copy, the new import, and the new call.
how do I undo a bad helper extraction in Atlas?: Atlas snapshots file changes as git patches, so edits can be diffed and rolled back. A swap that turns out to be wrong is restored from the snapshot rather than reverted by hand across every caller you touched.
when should I run the tests during a deduplication refactor?: Run the suite with bash after every apply_patch swap, not once at the end. Testing per swap attributes a failure to the exact callsite that caused it. Running once after twelve swaps tells you only that something in the batch broke.
how do I confirm every copy of the duplicated logic is gone?: Finish the workflow with a grep for the old code's fingerprints, such as a distinctive constant or a rare method call the duplicated block used. Zero hits means the collapse is complete. Any remaining hit means a copy was never confirmed or never swapped.
can Atlas plan a refactor before it changes anything?: Yes. Atlas drafts a plan in a read-only plan agent and asks before switching to a build agent, so you can see the full extraction sequence, including which files write and apply_patch will touch, before any file is modified.

Try Atlas in your terminal

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

Install Atlas

Related guides

Extract a Shared Helper from Duplicated C# Code with Atlas (2026)

How Atlas collapses duplicated C# logic into one tested helper in 2026: codebase_search finds semantic copies, apply_patch swaps each callsite, xUnit via dotnet test proves it.

Extract a Shared Helper from Duplicated Code in Django with Atlas in 2026

In 2026, Django developers use Atlas to find and refactor duplicated logic into shared helpers. Leverage semantic search, automated patching, and `pytest-django` for safe, efficient code consolidation.

Extract a Shared Helper from Duplicated Express Code in 2026 with Atlas

In 2026, use Atlas to find and refactor duplicated logic in your Express services. Consolidate copy-pasted code into a single, tested helper, ensuring robust middleware and error handling.

Extract a Shared Helper from Duplicated Code in Three.js with Atlas in 2026

Refactor your Three.js codebase in 2026 by extracting duplicated logic into a single, tested helper using Atlas. Prevent GPU memory leaks and improve performance.

Extract a Shared Helper From Duplicated C++ Code With Atlas (2026)

Duplication in C++ is semantic, not textual. Atlas finds near-duplicate logic with codebase_search, writes one header, and swaps each copy with apply_patch.

Extract a Shared Helper from Duplicated Rust Code with Atlas (2026)

Extract a shared helper from duplicated Rust code with Atlas in 2026. Find near-duplicates with codebase_search, add a module, swap each copy with apply_patch, run cargo test.

Extract a Shared Helper From Duplicated Code in Ruby With Atlas (2026)

How to use Atlas, the terminal-native AI coding agent, to find copy-pasted Ruby logic and collapse it into one tested module backed by RSpec, Bundler, and RuboCop.

Extract a Shared Helper from Duplicated PowerShell Code with Atlas in 2026

Streamline your PowerShell modules in 2026 by extracting duplicated logic into a single, tested helper using Atlas. Leverage Pester and PSScriptAnalyzer for robust refactoring.

Browse this resource hub