# Locate where a behavior is implemented in Scala with Atlas (2026) > Atlas locates behavior in a Scala codebase with three complementary tools: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph. 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. ## Key takeaways - Atlas attacks Scala code search from three angles: codebase_search for meaning, grep for exact text, and the lsp tool for the symbol graph. - codebase_search returns candidate declarations even when your words never appear in the .scala source, which is common with Scala's algebraic naming. - grep runs through ripgrep with a real regex plus include and path filters, which is the right tool for a log string, an application.conf key, or a build.sbt coordinate. - The lsp tool's findReferences sees calls routed through implicits and typeclass instances that no text search can reconstruct. - read fails loudly with File not found plus a Did you mean list, so a wrong path in a deep Scala package hierarchy never goes unnoticed. ## 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. ## Steps 1. Run atlas in a Scala project with a build.sbt so Atlas reads your traits, implicits, and sbt modules. 2. Describe the behavior to codebase_search; the semantic index returns candidate declarations even when your words do not appear in the .scala source. 3. Confirm 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. 4. Open 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. 5. Use the lsp tool's findReferences operation to see every callsite, including calls routed through an implicit conversion or a typeclass instance. 6. Use 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. 7. Summarize the call path back with concrete file and line references, naming the .scala file, the trait, and the method. 8. Run ScalaTest via sbt test to see what already covers the behavior, and run scalafmt if the investigation turns into a change. ## FAQ ### 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. --- Canonical HTML: https://runatlas.sh/resources/stacks/locate-where-a-behavior-is-implemented-in-scala Source of truth: aeo_pages row `/resources/stacks/locate-where-a-behavior-is-implemented-in-scala` (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.