Finding where a behavior lives in a Scala codebase is a retrieval problem, and Atlas attacks it from three angles at once. codebase_search finds code by meaning, so you can describe what the software does without knowing what the trait is called. grep finds exact text through ripgrep with a real regex plus include and path filters. The lsp tool gives you the symbol graph, with findReferences for every callsite and workspaceSymbol to jump to a declaration by name. The three are complementary, which is why Atlas ships all three rather than one fuzzy search box, and in a Scala project built with sbt, where behavior hides behind implicits and typeclass instances, you need all three.
How do I find where a behavior is implemented in Scala when I do not know the class name?
Describe the behavior to codebase_search. In 2026 the semantic index still returns candidate declarations even when your words do not appear in the source, which is the normal case in Scala, where the trait implementing your retry behavior may be called Resilient and never contain the word retry at all.
Scala naming conventions make this the default situation, not an edge case. Abstractions get named for their algebra rather than their effect, so the code that debounces a stream, the code that retries a failed effect, and the code that validates a request may all be named after the typeclass rather than the behavior. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so a plain-English description gets semantic weight and any distinctive identifier you do know gets keyword weight. Atlas also indexes code by AST declarations using tree-sitter, not blind line windows, so the hit is the trait, object, or def declaration itself rather than a 40 line slab of a .scala file.
When should I use grep instead of codebase_search in a Scala repo?
Use grep when you have exact text: a log message, a config key in application.conf, a dependency coordinate in build.sbt, a case class name. In 2026 Atlas grep takes a real regex plus include and path filters and runs through ripgrep, so scoping a sweep to src/main/scala is one call.
grep is the confirmation pass after codebase_search, and it is the primary pass when the string is literal. In a Scala project, the strings worth grepping are specific: an error message that appears in production logs and must exist verbatim in a .scala source, a key read from application.conf, a module name declared in build.sbt, an sbt task name. Semantic search is the wrong tool for those, because you already know the exact text and you want every occurrence, not the most similar ones. Running grep after codebase_search also validates the semantic hit: if the candidate file really implements the behavior, the strings it emits should be there.
What happens if Atlas reads the wrong Scala file path?
Atlas opens the best candidate with the read tool, and in 2026 a wrong guess fails loudly with File not found plus a Did you mean list. A misremembered path like src/main/scala/com/example/Retry.scala does not silently return nothing, so a bad path never goes unnoticed during a Scala investigation.
Silent empty results are the enemy of retrieval. If read returned nothing for a path that does not exist, an agent would conclude the file is empty or the behavior is absent, and the investigation would take a wrong turn with no signal that anything went wrong. Atlas fails loudly instead: File not found, plus a Did you mean list of near-miss paths, which in a deep Scala package hierarchy under src/main/scala/com/example/ is usually enough to land on the right file immediately. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so reads are explicit actions with explicit results.
How do I find every callsite of a Scala trait or method?
Use the lsp tool's findReferences operation to see every callsite, and workspaceSymbol to jump to the declaration by name. In 2026 a Scala method can still be reached through an implicit conversion or a typeclass instance, so the language server sees relationships that neither codebase_search nor grep can reconstruct from text.
The symbol graph is the third angle and it is the one that handles Scala's indirection. An extension method provided by an implicit class, a typeclass instance summoned by the compiler, an override in a trait mixed into three classes: none of those are textual relationships, and all of them are real references. findReferences enumerates them from the language server. workspaceSymbol works in the other direction, jumping straight to a declaration when you already know its name but not its file, which beats guessing at the package path under src/main/scala. The three tools together, semantic search, exact text, and the symbol graph, are what turn a behavior description into a file and a line.
How do I report the result of a Scala code investigation?
Summarize the call path back with concrete file and line references. A Scala investigation that ends with the sentence the retry logic is in the effects layer is worthless. One that ends with a named .scala file, a named trait, and a line number is something a teammate can act on in 30 seconds.
The concrete summary is the deliverable of the whole workflow. Name the file under src/main/scala, the trait or object, the method, and the callers findReferences returned. Once you have that, the next actions are obvious: run ScalaTest via sbt test to see what already covers the behavior, or change it and run scalafmt so the diff shows the logic and not formatting. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so an investigation that turns into a change stays reviewable, and Atlas snapshots file changes as git patches so edits can be diffed and rolled back.
How do I set Atlas up on an sbt project before searching for a behavior?
Run atlas in a project with a build.sbt. In 2026 Atlas reads your traits, implicits, and sbt modules, which is exactly the context that makes the lsp tool's findReferences meaningful in Scala, where a call can be routed through an implicit that the source text never names.
The build.sbt file declares the modules, and the module layout is what makes a symbol resolvable across the project rather than only within one source root. With it loaded, you can have Atlas refactor to typeclasses or add ScalaTest cases and review the diff, and the search workflow runs on the same understanding: codebase_search for meaning, grep for exact text, read for the file, the lsp tool for the graph. If your Scala codebase is private, Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, so the semantic index over src/main/scala is built locally.
Step by step
- 01Run atlas in a Scala project with a build.sbt so Atlas reads your traits, implicits, and sbt modules.
- 02Describe the behavior to codebase_search; the semantic index returns candidate declarations even when your words do not appear in the .scala source.
- 03Confirm with grep, which takes a real regex plus include and path filters and runs through ripgrep, scoped to src/main/scala or to application.conf and build.sbt when the string is a config key.
- 04Open the best candidate with the read tool; a wrong guess fails loudly with File not found plus a Did you mean list, so a bad path under src/main/scala/com/example/ does not go unnoticed.
- 05Use the lsp tool's findReferences operation to see every callsite, including calls routed through an implicit conversion or a typeclass instance.
- 06Use the lsp tool's workspaceSymbol operation to jump to the declaration by name when you know the trait or object but not its package path.
- 07Summarize the call path back with concrete file and line references, naming the .scala file, the trait, and the method.
- 08Run ScalaTest via sbt test to see what already covers the behavior, and run scalafmt if the investigation turns into a change.
Frequently asked questions
- how do I find which Scala class implements a behavior when I do not know its name
- Describe the behavior to Atlas's codebase_search. The semantic index returns candidate declarations even when your words do not appear in the source, which is normal in Scala where a trait is often named for its algebra rather than its effect. Confirm the hit with grep and walk the callers with the lsp tool's findReferences.
- codebase_search vs grep in Scala, which should I use
- Use codebase_search when you know what the software does but not what the code is called. Use grep when you have exact text such as a log message, an application.conf key, or a build.sbt coordinate. Atlas ships both plus the lsp tool because they answer different questions.
- how do I find all usages of a Scala trait including implicit conversions
- Use the lsp tool's findReferences operation. In Scala a method can be reached through an implicit class, a typeclass instance summoned by the compiler, or a trait mixed into several classes. None of those are textual relationships, and all of them are real references the language server can enumerate.
- what happens if Atlas reads a Scala file path that does not exist
- The read tool fails loudly with File not found plus a Did you mean list of near-miss paths. A silent empty result would let an investigation conclude the behavior is absent, so Atlas makes the bad path an explicit error, which in a deep package hierarchy under src/main/scala is usually enough to land on the right file.
- does Atlas understand sbt projects
- Yes. Run atlas in a project with a build.sbt and Atlas reads your traits, implicits, and sbt modules. That is what makes the lsp tool's symbol operations resolve across modules, and it is why Atlas can refactor to typeclasses or add ScalaTest cases and show you the diff to review.
- how do I jump to a Scala declaration when I know the name but not the file
- Use the lsp tool's workspaceSymbol operation. It jumps straight to the declaration by name, which beats guessing at the package path under src/main/scala/com/example/. findReferences then works in the other direction, showing every callsite of that symbol.
- can Atlas search a private Scala codebase without uploading it
- Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, so the semantic index over src/main/scala is built locally and codebase_search still works on a closed-source sbt project.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Locate Where a Behavior Is Implemented with Atlas in 2026
How to locate where a behavior is implemented with Atlas in 2026: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph.
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.
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.
Run the Test Suite and Triage the Failures in Scala with Atlas (2026)
Atlas runs ScalaTest via sbt test with a generous timeout, retains the full log when output truncates at 2000 lines, and turns red output into a todowrite list.
Diagnose a hanging or long-running command in Scala with Atlas (2026)
Is your sbt build slow or blocked on stdin? Atlas races every command against a timeout and tells you which. A 2026 guide for Scala teams using sbt and scalafmt.
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.
Rename a symbol across the repo in Scala with Atlas in 2026
Refactor Scala code with Atlas in 2026. Safely rename functions, classes, or constants across your entire sbt project, ensuring all references, including comments and strings, are updated accurately.