To onboard to an unfamiliar Elixir codebase with Atlas, start Atlas in any directory containing a mix.exs, then ask codebase_search a plain-language question about the supervision tree or contexts instead of guessing at filenames. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so a question like how are requests authenticated returns ranked snippets with real Elixir file paths under lib/. From there, glob maps the umbrella or single-app layout, read pulls the two or three modules that actually matter, and ExUnit via mix test tells you which behavior is already pinned. Mix and Hex describe the dependency surface, and mix format tells you the house style before you write a line.
How does Atlas explore an unfamiliar Elixir codebase?
Atlas explores an unfamiliar Elixir codebase by starting from meaning, not filenames. In 2026 the first move is codebase_search, which queries the semantic index and returns ranked snippets with file paths. Atlas indexes code by AST declarations using tree-sitter, so a GenServer callback is a unit, not a line window.
Ask codebase_search a plain-language question, for example how requests are authenticated, and Atlas returns ranked snippets pointing at the real modules: a plug pipeline in lib/my_app_web/router.ex, an auth context in lib/my_app/accounts.ex, a token module in lib/my_app/accounts/token.ex. Because Atlas indexes code by AST declarations using tree-sitter, not blind line windows, the snippet you get back is a whole defmodule or def, so a returned Elixir function arrives with its head, its guards, and its body intact rather than sliced across an arbitrary boundary. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, which is why searching for supervision even when the code only ever says Supervisor.start_link still surfaces lib/my_app/application.ex. That is the difference between semantic onboarding and grepping for defmodule.
What Atlas tools map the layout of a mix project?
Atlas maps a mix project with glob before opening anything. Run glob on the top-level directories to see whether you are looking at a single app with lib/ and test/, or an umbrella with apps/*/mix.exs. Two or three glob calls in 2026 replace ten minutes of manual directory browsing.
The Elixir layout convention is strong and glob exploits it. Globbing mix.exs and apps/*/mix.exs immediately tells you if the repo is an umbrella. Globbing lib/**/*.ex separates the domain contexts from lib/*_web/**/*.ex, the Phoenix surface. Globbing test/**/*_test.exs shows you how much of the system already has ExUnit coverage, and config/config.exs, config/dev.exs, config/runtime.exs shows you what is configured at compile time versus at boot. Only after that shape is clear does Atlas call read on the files codebase_search ranked highest: typically mix.exs itself for the Mix and Hex dependency list, lib/my_app/application.ex for the supervision tree, and whichever context module owns the concept you asked about. Atlas reads only the files that actually matter, which is the whole point of onboarding without reading every file.
How do you follow the call graph in Elixir with the lsp tool?
Atlas follows an Elixir call graph with the lsp tool's goToDefinition operation. After read pulls the top-ranked module, every alias and every function call in it becomes a jump. In a 2026 Phoenix app, that walks from router.ex to the controller, to the context, to the Ecto schema, in four hops.
Elixir code hides its structure behind aliases and behaviours, so following imports by eye is slow. Atlas uses the lsp tool's goToDefinition operation to resolve an alias like MyApp.Accounts to lib/my_app/accounts.ex, and to jump from a handle_call clause into whatever it delegates to. That matters most for OTP code, where a GenServer.call in one module lands in a handle_call in a completely different file, and for behaviours, where the implementation of a callback lives wherever @behaviour was declared. Atlas indexes code by AST declarations using tree-sitter, so the declaration boundaries the lsp tool jumps between line up with the way Elixir developers actually think about their code: modules, functions, and callbacks.
Can Atlas explore an Elixir repo without changing anything?
Yes. Atlas delegates wide sweeps of an Elixir repo to the explore subagent through the task tool, and that subagent is defined with a deny-by-default permission set that allows only 6 tools: grep, glob, read, bash, webfetch, and websearch. No edit tool is reachable, so no file under lib/ can change while Atlas looks around.
Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and the explore subagent narrows that set further. When you ask Atlas to survey every context module in a large umbrella, Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, and each of those sessions inherits the read-only permission set. For onboarding this is the correct posture: you want a map of lib/my_app/, not an unrequested refactor of it. If Atlas does later propose a change, Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so the transition from reading Elixir to writing Elixir is an explicit, reviewable step rather than a silent one.
What should you run first in an Elixir repo you just cloned?
In an Elixir repo you just cloned, run mix deps.get and then ExUnit via mix test before you read a single module. A green baseline in 2026 tells you the project builds, the Mix and Hex dependency tree resolves, and the behavior described by the existing test/ directory is currently true.
Atlas runs ExUnit via mix test through bash and reads the result, and a passing suite is the strongest onboarding signal there is: it means the tests in test/ are a live description of the system rather than an abandoned one. Running mix format --check-formatted tells you whether the repo enforces mix format in CI, which is worth knowing before your first patch. Atlas records what it learned as a todowrite list so the open questions survive into the next turn: which context owns billing, why the supervision tree restarts one child with :transient, whether the Hex dependency pinned in mix.exs is the one actually in mix.lock. Those open questions are the real output of onboarding, and Atlas keeps them in the session rather than in your head.
Step by step
- 01Run atlas in a project with a mix.exs so Atlas can index the Elixir source under lib/ and test/.
- 02Ask codebase_search a plain-language question, for example how requests are authenticated; it queries the semantic index and returns ranked snippets with file paths.
- 03Run glob on the top-level directories (mix.exs, apps/*/mix.exs, lib/**/*.ex, config/*.exs) to see the package layout and naming conventions before opening anything.
- 04Read the two or three files codebase_search ranked highest, starting with lib/my_app/application.ex for the supervision tree, then follow aliases with the lsp tool's goToDefinition operation.
- 05Check the dependency surface in mix.exs and mix.lock, which Mix and Hex resolve, so you know which behavior is yours and which is a Hex package.
- 06Run ExUnit via mix test through the bash tool to establish a green baseline before you touch anything.
- 07Run mix format --check-formatted to learn whether the repo enforces mix format, so your first patch matches house style.
- 08Delegate wide sweeps to the explore subagent through the task tool: it is defined with a deny-by-default permission set that only allows grep, glob, read, bash, webfetch, and websearch.
- 09Record what you learned as a todowrite list so the open questions survive into the next turn.
Frequently asked questions
- how to understand a large Elixir codebase quickly
- Ask Atlas's codebase_search a plain-language question rather than grepping for defmodule. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion and returns ranked snippets with file paths, so you read the three modules that matter instead of every file under lib/.
- what does Atlas need to work on an Elixir project
- Run atlas in a project with a mix.exs. Atlas reads your supervision tree, contexts, and deps from there, and can run ExUnit via mix test and mix format through the bash tool once it has the project.
- can an AI coding agent read my Elixir code without changing it
- Yes. Atlas's explore subagent, invoked through the task tool, is defined with a deny-by-default permission set that only allows grep, glob, read, bash, webfetch, and websearch. No edit tool is reachable, so nothing under lib/ can change while Atlas explores.
- how do I find the supervision tree in an unfamiliar Elixir app
- Glob for lib/*/application.ex and ask Atlas's codebase_search how the application starts its children. Atlas indexes code by AST declarations using tree-sitter, so the Application.start/2 callback and its child spec list come back as a whole declaration, not a fragment.
- does Atlas work with Elixir umbrella projects
- Yes. Run glob on apps/*/mix.exs to detect an umbrella, then use codebase_search to search across all apps at once. Atlas can also fan out work to subagents that run in the foreground or in parallel background sessions when the survey is wide.
- can Atlas index my Elixir code without sending it to a third party
- Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, which matters when the lib/ tree you are onboarding to belongs to a client or an internal service.
- how do I know an Elixir repo is healthy before I start working in it
- Run ExUnit via mix test for a green baseline and mix format --check-formatted for style enforcement, both through Atlas's bash tool. A passing suite means the tests in test/ describe the system as it is today, which is the strongest onboarding signal available.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Onboard to an Unfamiliar Codebase with Atlas in 2026
How to onboard to an unfamiliar codebase with Atlas in 2026: use codebase_search, glob, read, lsp, task, and todowrite to build a mental model fast.
Atlas for Elixir in 2026
Adopt Atlas, the terminal-native AI coding agent, for Elixir development in 2026. Enhance productivity with deep code understanding, safety features, and direct integration into mix projects and OTP applications.
Write Unit Tests for Untested Code in Elixir with Atlas in 2026
Learn how Atlas helps Elixir developers in 2026 add robust unit tests to untested modules, matching existing repo conventions using ExUnit via mix test.
Rename a symbol across the repo in Elixir with Atlas in 2026
Effortlessly rename Elixir functions, modules, or constants across your entire codebase in 2026 using Atlas. Leverage `lsp`, `grep`, and `edit` for precise, verified refactoring, ensuring your `mix test` suite remains
Debug a Single Failing Test in Elixir with Atlas (2026)
Fix one red ExUnit test in Elixir in 2026, not the assertion. Atlas isolates it with mix test at a line number, walks the call path with lsp, and edits the real code.
Trace a Runtime Bug From a Stack Trace in Elixir with Atlas (2026)
Trace an Elixir runtime bug from a stack trace in 2026 with Atlas: read each frame at its offset, grep for the error message, findReferences the callers, fix, add ExUnit.
Audit an Elixir Repo with Parallel Subagents in 2026 using Atlas
Sweep your Elixir repository for specific problems without blowing your context window. Atlas uses parallel subagents, ExUnit, Mix, and Hex to audit large Elixir codebases efficiently.
Run the Test Suite and Triage the Failures in Elixir with Atlas (2026)
Triage a red ExUnit suite in Elixir with Atlas in 2026. Run mix test through bash, read the retained log past the 2000-line truncation, and group causes with grep.