How do I get an AI agent to explain an unfamiliar C# codebase?

Ask codebase_search a plain-language question such as how requests are authenticated. Atlas queries a semantic index built from AST declarations and returns ranked snippets with file paths across your .sln, then follows the chain with the lsp tool's goToDefinition.

Can an AI agent explore my .NET solution without changing anything?

Yes. Atlas delegates wide sweeps to the explore subagent through the task tool, and that subagent is defined with a deny-by-default permission set that only allows grep, glob, read, bash, webfetch, and websearch. No edit tool is available to it.

How does Atlas map the project structure of a C# solution?

With glob. Globbing **/*.csproj returns the whole project graph with folder locations, and **/*Tests.csproj reveals the test surface, so you can see which assemblies exist and how they are named before opening any .cs file.

Can Atlas trace dependency injection in an ASP.NET Core project?

Yes. Atlas uses the lsp tool's goToDefinition operation to cross from an interface in Company.Domain to its implementation in Company.Infrastructure to its registration in Program.cs, which a text search across .csproj boundaries cannot do reliably.

Does Atlas run dotnet test while exploring a C# codebase?

The explore subagent's permission set includes bash, so it can run xUnit via dotnet test to see what the team actually covers. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so you decide what is allowed.

How do I keep an AI agent's findings about a codebase between sessions?

Record them as a todowrite list. Atlas keeps entries such as confirm whether OrderService is scoped or singleton across turns, so the open questions about the C# solution survive rather than disappearing when the context window rolls over.

Can Atlas read a private C# codebase without uploading it?

Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, and codebase_search, glob, read, and the lsp tool all work the same way against a locally embedded .NET solution.

Onboard to an Unfamiliar C# Codebase with Atlas (2026)

Atlas onboards you to an unfamiliar C# codebase by starting from meaning rather than filenames. Ask codebase_search a plain-language question, such as how requests are authenticated, and the semantic index returns ranked snippets with real file paths from across your .sln. glob maps the project layout so you can see the .csproj boundaries and namespace conventions before opening anything. read pulls only the files that matter, the lsp tool follows project references, and heavy fan-out is delegated to the explore subagent, which is permissioned read-only so it cannot change a line of C# while it looks around.

How do you get oriented in an unfamiliar C# solution?

Start with a question, not a directory listing. Atlas's codebase_search takes a plain-language query such as how requests are authenticated and queries the semantic index, returning ranked snippets with file paths. In a .NET solution that lands you in the middleware or the handler, not in the 3rd .csproj you happened to expand.

A .NET solution with fifteen projects presents an onboarding problem that a file tree cannot solve. The names tell you the layering (Company.Api, Company.Domain, Company.Infrastructure) but not where anything actually happens. Atlas skips the browsing phase. codebase_search runs against a semantic index built from AST declarations parsed with tree-sitter, and the hybrid semantic and keyword retrieval it uses, fused by reciprocal rank fusion, means a query about authentication reaches the middleware registration in Program.cs and the handler class in Company.Api even though neither one contains the word you searched for. Ranked snippets come back with file paths attached, so the next move, opening the right file, is obvious. Nothing about the search touches your NuGet packages or your build.

How does glob map the structure of a C# project?

Atlas runs glob over the top-level directories to see the package layout and naming conventions before opening any file. In a .NET repository, globbing for .csproj and .sln files in 1 call gives you the whole project graph: which assemblies exist, how they are named, and where the test projects live.

Structure in C# is expressed through project files, and glob reads that structure directly. Glob for **/*.csproj and the answer is a list of assemblies with their folder locations. Glob for **/*Tests.csproj and the test surface appears, which tells you whether the team runs xUnit via dotnet test across every layer or only against the domain. Glob for appsettings*.json and the configuration story becomes visible. Doing this before reading any C# source is deliberate, because the project graph tells you what to expect: a Company.Domain with no NuGet dependencies is a real domain layer, and one that references an ORM package is not, and knowing that changes how you read every file afterwards. Atlas's glob is cheap and fast enough to run several times as your mental model sharpens.

What is the explore subagent and why is it read-only?

The explore subagent is how Atlas fans out across a large C# solution without risk. Delegated through the task tool, the explore subagent has a deny-by-default permission set that allows only 6 tools: grep, glob, read, bash, webfetch, and websearch. No edit tool exists there, so it cannot change a line of C# while it looks around.

Onboarding involves a lot of reading, and reading a fifteen-project solution serially fills a context window with material you will not need. Atlas fans out that work to subagents that can run in the foreground or in parallel background sessions, and for exploration it uses the explore subagent specifically. The permission design is the point. Deny-by-default means the subagent starts with nothing and receives exactly the read tools it needs, so an exploratory sweep of Company.Infrastructure cannot accidentally rewrite a repository class or run dotnet format across the tree. What comes back is a summary with file references rather than the raw contents of forty .cs files. You keep the conclusions and spend your context on the two or three classes that actually matter.

How does Atlas follow project references and namespaces in C#?

Atlas follows C# project references and using directives with the lsp tool's goToDefinition operation. When Company.Api calls an interface defined in Company.Domain and implemented in Company.Infrastructure, goToDefinition crosses those .csproj boundaries in 1 hop, which reading the file tree by hand does not.

Dependency injection makes C# codebases pleasant to work in and hard to read cold. The controller depends on IOrderService, and the concrete OrderService is bound somewhere in a service registration in Program.cs, possibly through an extension method in a different assembly. Text search does not follow that chain reliably; the language server does. Atlas's lsp tool exposes goToDefinition, so tracing from the interface to the implementation to the registration is three jumps, not thirty minutes. Read the two or three files codebase_search ranked highest, then follow the imports with goToDefinition and you have a working model of the request path. Combine that with the project graph glob already gave you and the assembly boundaries stop being abstract, because you can see which .csproj each hop landed in.

How do you keep what you learned about a C# codebase?

Record it as a todowrite list. Atlas persists open questions and findings across turns, so the 6 things you did not understand about the Company.Infrastructure project on day one survive into the next session instead of evaporating when the context window rolls over.

Onboarding produces two outputs: what you now understand, and what you still do not. The second one is the valuable one, and it is the one people lose. Atlas's todowrite list holds it. Entries read like real questions: confirm whether OrderService is registered as scoped or singleton, find out why the integration tests skip the Company.Api project, check whether the NuGet package pinning in Directory.Packages.props is intentional. When you come back, the list is the agenda. The verification loop is available the whole time, because the explore subagent can run bash: build the solution to confirm your mental model compiles against reality, run xUnit via dotnet test to see what the team actually covers, and run dotnet format if you eventually contribute so your first pull request does not fight the repo's style rules.

Step by step

01Start atlas in the solution root, the directory that holds the .sln, so the index covers every .csproj, namespace, and project reference.
02Ask codebase_search a plain-language question such as how requests are authenticated; it queries the semantic index and returns ranked snippets with file paths.
03Run glob over the top-level directories, for example **/*.csproj and **/*Tests.csproj, to see the project graph and naming conventions before opening anything.
04Read the two or three C# files codebase_search ranked highest rather than browsing the tree.
05Follow the dependency chain with the lsp tool's goToDefinition operation, crossing from an interface in Company.Domain to its implementation in Company.Infrastructure.
06Delegate 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, so it cannot edit your C#.
07Run xUnit via dotnet test through bash to see what the team actually covers, and check which NuGet packages each project pulls in.
08Record what you learned and what is still open as a todowrite list so the questions survive into the next session, and run dotnet format before your first contribution.

Frequently asked questions

How do I get an AI agent to explain an unfamiliar C# codebase?: Ask codebase_search a plain-language question such as how requests are authenticated. Atlas queries a semantic index built from AST declarations and returns ranked snippets with file paths across your .sln, then follows the chain with the lsp tool's goToDefinition.
Can an AI agent explore my .NET solution without changing anything?: Yes. Atlas delegates wide sweeps to the explore subagent through the task tool, and that subagent is defined with a deny-by-default permission set that only allows grep, glob, read, bash, webfetch, and websearch. No edit tool is available to it.
How does Atlas map the project structure of a C# solution?: With glob. Globbing **/*.csproj returns the whole project graph with folder locations, and **/*Tests.csproj reveals the test surface, so you can see which assemblies exist and how they are named before opening any .cs file.
Can Atlas trace dependency injection in an ASP.NET Core project?: Yes. Atlas uses the lsp tool's goToDefinition operation to cross from an interface in Company.Domain to its implementation in Company.Infrastructure to its registration in Program.cs, which a text search across .csproj boundaries cannot do reliably.
Does Atlas run dotnet test while exploring a C# codebase?: The explore subagent's permission set includes bash, so it can run xUnit via dotnet test to see what the team actually covers. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so you decide what is allowed.
How do I keep an AI agent's findings about a codebase between sessions?: Record them as a todowrite list. Atlas keeps entries such as confirm whether OrderService is scoped or singleton across turns, so the open questions about the C# solution survive rather than disappearing when the context window rolls over.
Can Atlas read a private C# codebase without uploading it?: Yes. Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, and codebase_search, glob, read, and the lsp tool all work the same way against a locally embedded .NET solution.

Try Atlas in your terminal

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

Install Atlas

Related 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 C# in 2026

Atlas is a terminal-native AI coding agent for C# and the .NET SDK in 2026. Run it in a solution with a .csproj or .sln and approve every diff before dotnet build.

Trace a Runtime Bug from a Stack Trace in C# with Atlas (2026)

Go from a production C# stack trace to the responsible line with Atlas in 2026, without a debugger attached, then lock the fix in with xUnit via dotnet test.

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.

Debug a single failing test in C# with Atlas (2026)

Debug one failing xUnit test in C# in 2026 with Atlas: isolate it with a dotnet test filter, walk the call path with the lsp tool, and fix the code, not the assertion.

Self-Review Your Working Diff Before Committing in C# with Atlas (2026)

Self-review a C# working diff in 2026 with Atlas: read the full diff and every changed file, grep for leftovers, revert from a snapshot, then run xUnit via dotnet test.

Audit a C# Repo with Parallel Subagents in Atlas (2026)

Sweep a C# solution for a class of problem in 2026 using Atlas parallel subagents: one read-only explore task per .csproj, findings merged and fixed with edit.

Plan a Multi-File Change Before Editing in C# with Atlas (2026)

Design a C# refactor across many files in 2026 before touching one line. Atlas plan mode denies every edit tool, writes a plan, then hands off with plan_exit.

Browse this resource hub