You’ve installed Claude Code. You’ve opened your terminal in the root of a .NET solution. The cursor is blinking. Now what?

I remember my first session. I had no idea where to start. Should I ask it something? Give it a task? Explain my project first? It felt like sitting next to a new colleague who knows nothing about your codebase — except this colleague can read your entire project in seconds.

Here’s what I wish someone had told me before that first hour.

Step 1: Let Claude Code explore

Start Claude Code in your terminal:

claude

Then run the /init command. This tells Claude Code to scan your solution and create a CLAUDE.md file — a kind of memory file for your project.

> /init

Claude Code reads your .sln file, discovers the projects, checks the dependencies in your .csproj files, and looks at your folder structure. Within a minute, it has a mental map of your solution.

For a typical solution with a Web API, a domain layer, and an infrastructure project, Claude Code will pick up on all of that. The project references, the NuGet packages, the patterns you’re using — it just reads it.

Step 2: Ask it to explain your project

This is the step most people skip, but it’s the most valuable one for building trust. Ask Claude Code what it sees:

“What does this solution do? What patterns and conventions does it use?”

Claude Code will give you something like:

“This is an ASP.NET Core Web API using Clean Architecture. The Domain project contains entities and interfaces, Infrastructure handles EF Core and external services, and the API project has controllers with MediatR for CQRS. You’re using FluentValidation for request validation and AutoMapper for object mapping.”

If it gets this right — and in my experience, it usually does — you know it understands your codebase well enough to make useful changes. If it misses something, that’s your cue to add context to the CLAUDE.md file.

Step 3: Make your first change

Start small. Don’t ask Claude Code to redesign your architecture on day one. Pick something concrete and low-risk.

A good first task: add a simple health check endpoint.

“Add a health check endpoint at /health that returns the application name and version.”

Claude Code will create the endpoint, respecting the patterns it found in your project. If you use minimal APIs, you’ll get a MapGet. If you use controllers, you’ll get a controller. It adapts to what’s already there.

app.MapGet("/health", () => Results.Ok(new
{
    Status = "Healthy",
    Application = "MyApi",
    Version = typeof(Program).Assembly
        .GetCustomAttribute<AssemblyInformationalVersionAttribute>()?
        .InformationalVersion ?? "unknown"
}));

The key thing here: review the code before you accept it. Claude Code will ask for confirmation before writing files. Read what it proposes. This is the same workflow you’d follow with a human colleague — you don’t blindly merge their PR either.

Step 4: Run the tests

After Claude Code makes a change, ask it to verify:

“Run the tests to make sure nothing is broken.”

Claude Code will run dotnet test and show you the output. If something fails, it reads the test output and tries to fix the problem. This feedback loop — change, test, fix — is where Claude Code really shines.

dotnet test --verbosity normal

If your solution doesn’t have tests yet, that’s actually a great second task:

“Can you add a test for the health check endpoint we just created?”

You’ll get a proper integration test using WebApplicationFactory, following whatever test framework you already have — xUnit, NUnit, or MSTest.

Step 5: Set up your CLAUDE.md

The /init command created a basic CLAUDE.md file. Now it’s time to make it yours. Open the file and add the things Claude Code can’t figure out on its own:

  • How to run the project locally (connection strings, Docker containers, etc.)
  • Naming conventions your team follows
  • Things to avoid (“don’t use Repository pattern, we use CQRS”)
  • The test command and how to run specific test projects
## Commands
- Run: `dotnet run --project src/MyApi`
- Test: `dotnet test tests/MyApi.Tests`
- Database: `docker compose up -d` (starts PostgreSQL on port 5432)

## Conventions
- Use MediatR handlers, not service classes
- All request validation via FluentValidation
- No business logic in controllers

This file is the single biggest lever for getting good results from Claude Code. The more specific you are about your conventions, the better Claude Code will follow them.

Tips for your first session

Do try:

  • Ask Claude Code to explain existing code you’ve been meaning to understand
  • Fix a small bug that’s been sitting in the backlog
  • Add a missing test for an existing feature
  • Generate a DTO or mapping that’s tedious to write by hand

Don’t try (yet):

  • Major architectural changes on day one
  • Asking it to build an entire feature without reviewing intermediate steps
  • Giving vague instructions like “make this better”
  • Ignoring the code it generates — always review

Honest limitations

A few things to know before you start:

Claude Code doesn’t run your application. It can run dotnet build and dotnet test, but it doesn’t start your API and hit endpoints. Integration testing with a running server is still your job.

It can make mistakes. Especially with complex business logic or domain-specific rules it hasn’t seen before. The code it generates is a starting point, not a finished product.

It works best with explicit instructions. “Add a health check endpoint” works better than “improve the API.” The more concrete you are, the better the result.

Large solutions take a moment. If your solution has 50+ projects, the initial scan takes longer. That’s normal. It only needs to do this once per session.

Try it yourself

npm install -g @anthropic-ai/claude-code
cd your-dotnet-solution/
claude

Run /init. Ask it to explain your project. Make one small change. Run the tests. That’s your first hour.

After that, you’ll have a feel for what Claude Code can do — and more importantly, how it fits into the way you already work. It’s not a replacement for your skills. It’s a tool that removes the tedious parts so you can focus on the interesting ones.