How a .NET Engineer Actually Starts with AI

Part of the series AI for .NET Engineers — Chapter 1

Let me guess where you are right now.

You've been writing .NET for five, maybe ten years. You know your way around a controller, you've argued about whether a service should be scoped or singleton more times than you'd like to admit, and you've shipped things that real people use. You're not a beginner. You're good at this.

And yet, every second post on LinkedIn is someone talking about AI agents, RAG pipelines, and prompt engineering, and some quiet part of you is wondering if you're about to become the guy who didn't keep up.

Not because you can't learn it.

Because you don't know where to even start.

Do you pick up a Python course? Do you go read the transformer architecture paper? Do you sign up for six different AI newsletters and hope something sticks?

Here's what I want to tell you, and I want you to actually sit with this for a second:

You don't need to become an AI researcher. You don't even need to learn a new language.

What you need is to start using AI as a tool inside the world you already know, which is .NET, Visual Studio, and the daily grind of shipping code.

And the fastest way to do that isn't a course.

It's a tool that sits right inside your terminal and starts helping you today.

That tool is Claude Code.

And this chapter is about getting it running, understanding what it actually does, and using it to build something real. Not a toy example you'll forget in a week, but an actual small project, built by you, guided by an AI that reads your code the way a very fast, very patient colleague would.

But there's a bigger reason we're starting here. We're not going to spend the next few chapters memorising AI terminology. We're going to build our understanding the same way you've probably learned most of the technology you already know: by building things. We'll start by using AI inside the development workflow you already understand, then move from using AI to build software to building software that uses AI. Along the way, we'll get into models, prompts, structured output, RAG, tool calling, agents, MCP, and eventually the engineering concerns that matter when these systems meet production.

You don't need to learn all of that today.

You just need to take the first step.

Why start here, and not with "AI theory"

I thought about writing this series the traditional way. Chapter one: what is a large language model. Chapter two: what is a token. Chapter three: here's how prompting works. And honestly, that's a perfectly reasonable way to structure a course.

But think about how you actually learned ASP.NET, or Entity Framework, or Azure, the first time. Did you sit down and read the full documentation cover to cover before writing a single line of code? Or did you open Visual Studio, hack together something that barely worked, break it, fix it, and slowly build a mental model of what was happening underneath? Most of us learn by doing first and understanding second, and the concepts stick better once you've felt the problem they solve.

So instead of starting with theory, we're starting with your hands on the keyboard. You're going to install an AI coding assistant, you're going to talk to it in plain English, and you're going to watch it write, edit, and reason about a real .NET project. The "why does this work" conversations will come in the chapters after this one, once you've actually felt what it can do.

There's another reason I want to start this way.

You're not starting from zero

There's a temptation, when entering AI, to think you're starting over.

You're not.

You already understand APIs, dependency injection, authentication, databases, async programming, testing, logging, configuration, deployment, distributed systems, failure handling, and the thousand little decisions that make software work outside a tutorial.

AI doesn't make those skills irrelevant.

In many cases, it makes them more valuable.

The new part is that one of the components in your system is no longer deterministic. Instead of calling a method that reliably returns the same result for the same input, you may now be calling a model that can be probabilistic, expensive, slow, and occasionally wrong.

That's a new engineering problem.

But it's still an engineering problem.

And that's why you're starting from a much stronger position than you probably think.

What Claude Code actually is, in plain terms

Before you install anything, let's remove the mystery. Claude Code is not a chatbot window where you copy-paste code back and forth, it's a command line tool that runs right inside your project folder, on your actual machine, with your actual files. You open a terminal, you start it, and you describe what you want in ordinary English, the same way you'd explain a task to a teammate. It reads your existing code to understand context, and it can create new files, edit existing ones, and run commands like build or test. Critically, it gives you visibility into the work it's proposing before changes are made, so you're not blindly trusting a black box.

Think of it less like "AI writes my code for me," and more like having a very capable junior-to-mid level engineer sitting next to you who can move fast, where your job is to review, guide, and approve their work. That distinction matters more than it sounds. The skill you're building here isn't "how do I get AI to do my job." It's how you direct, review, and collaborate with an AI teammate, and whether you eventually use Claude Code, GitHub Copilot, or whatever comes next, that's the transferable skill.

Getting it installed

Claude Code runs from your terminal, so the setup is refreshingly simple if you've ever installed a global npm package or a CLI tool before. There are two ways to get it on your machine, and either is fine for what we're doing.

Option A: through npm. If you already have Node.js 18 or newer installed:

npm install -g @anthropic-ai/claude-code

Option B: the native installer, if you'd rather not deal with Node versions. On macOS, Linux, or WSL:

curl -fsSL claude.ai/install.sh | bash

On Windows, from PowerShell:

irm https://claude.ai/install.ps1 | iex

Either way, once it's done, open a fresh terminal and confirm it installed correctly:

claude --version

If that prints a version number back at you, you're set. That's genuinely most of the setup, no complex configuration file to write, no environment to provision.

Now, create a fresh, empty folder somewhere on your machine, just so your very first run isn't touching anything important, and open a terminal inside it:

mkdir text-analyzer-api
cd text-analyzer-api
claude

That last command starts your first interactive session. You'll see something similar to this in your terminal:

✻ Welcome to Claude Code!

  /help for help, /status for your current setup

> Try "create a util logging.py that..."

That > prompt is where you'll type in plain English, the same way you'd message a colleague. Don't close this terminal yet, we're about to use it.

A quick note before we continue

Claude Code is a paid product, and you'll get much more out of this series if you can actually use the tool rather than trying to work around its limitations. I'm deliberately not putting a price here, since AI tools and their plans change quickly, and I don't want this chapter to become outdated because of a number on a page. Check Anthropic's current Claude Code plans and choose the option that makes sense for you. The important thing isn't which plan you choose, it's that you actually start using the tool.

Now, let's build something

With Claude Code installed and running, let's use it for what it's actually good at. We're going to build a very small, very real .NET project: a minimal Web API with a single endpoint that takes a piece of text and returns some basic information about it, like word count and character count. Nothing fancy, the point isn't the complexity of the project, the point is watching how the collaboration actually feels.

You're still sitting at that > prompt from the last section, inside your empty text-analyzer-api folder. Now, instead of writing any code yourself, type out what you want, the way you'd explain it to a new team member on your first stand-up call with them:

> Create a new ASP.NET Core Minimal API project in this folder. Add one endpoint,
a POST to /analyze, that accepts a JSON body with a "text" field, and returns the
word count and character count of that text as JSON.

Hit enter, and watch what happens. Claude Code may respond with something along these lines before making changes:

I'll create a Minimal API project with a POST /analyze endpoint.

Plan:
1. Run `dotnet new webapi -minimal` to scaffold the project
2. Add a TextAnalysisRequest and TextAnalysisResponse record
3. Add the POST /analyze endpoint in Program.cs
4. Build the project to confirm it compiles

Proceed?

This is the part that surprises most experienced .NET developers the first time. It's not simply spitting out a code block for you to paste, it's reasoning about the task, working in your actual project folder, proposing a sequence of actions, and giving you the opportunity to review what it's going to do.

And this is exactly the moment where your five-plus years of .NET experience becomes your superpower, not something AI replaces. You're not blindly accepting output, you're reading the plan the way you'd read the description on a pull request before you've even opened the diff. Does the approach match what you asked for? Is anything missing, or is it introducing something unnecessary? Would you have designed it differently? You approve, you ask for changes, or you push back, exactly the muscle you've already developed from years of code reviews.

Once you approve, it'll create the files and show you the actual code it wrote, something close to this in Program.cs:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapPost("/analyze", (TextAnalysisRequest request) =>
{
    var wordCount = request.Text.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
    var charCount = request.Text.Length;
    return Results.Ok(new TextAnalysisResponse(wordCount, charCount));
});

app.Run();

record TextAnalysisRequest(string Text);
record TextAnalysisResponse(int WordCount, int CharCount);

Read that the way you'd read any teammate's code. Would you have named charCount differently? Would you validate that request.Text isn't null? Is splitting on a simple space actually sufficient for the requirements? Say so, right there in the same session. For example:

> Add validation so that a missing or empty text value returns a 400 Bad Request
instead of trying to analyze it.

Claude Code will update the same file and show you the revised endpoint:

app.MapPost("/analyze", (TextAnalysisRequest request) =>
{
    if (string.IsNullOrWhiteSpace(request.Text))
    {
        return Results.BadRequest("Text field cannot be empty.");
    }

    var wordCount = request.Text.Split(' ', StringSplitOptions.RemoveEmptyEntries).Length;
    var charCount = request.Text.Length;
    return Results.Ok(new TextAnalysisResponse(wordCount, charCount));
});

Notice what just happened. You didn't open the file, find the right line, and type the fix yourself. You reviewed the output like a senior engineer reviewing a PR, spotted a gap, said so in plain English, and got back a corrected version in seconds.

That back-and-forth, not the first draft, is the actual skill this chapter is trying to build in you.

The first AI engineering loop

Look at what you just did. You didn't simply ask AI to write some code, you followed a loop:

Describe → Review → Direct → Verify

You described the outcome you wanted. AI proposed an implementation. You reviewed it using the engineering judgment you've already developed. You directed it when something was wrong or incomplete. Then you verified the result by actually running the application.

That's the first mental model I want you to carry through this entire series.

AI doesn't remove the engineering loop. It changes where the work happens inside it.

You'll see this idea again and again as we move from coding assistants to AI-powered applications, RAG, agents, and production systems. The better you become at describing intent, reviewing output, identifying gaps, and verifying behaviour, the more useful these tools become.

And notice something else. The AI didn't replace your engineering judgment, it depended on it.

Now verify the work

Once you're happy with the implementation, run the project the normal way you always have:

dotnet run

And in a separate terminal, or with Postman, hit the endpoint:

curl -X POST http://localhost:5000/analyze \
  -H "Content-Type: application/json" \
  -d '{"text": "Claude Code just built my first endpoint"}'

You should get something back along these lines:

{ "wordCount": 7, "charCount": 43 }

The exact output may vary depending on the implementation and the text you use, and that's fine. The important thing is that you now have a running application.

Sit with that for a second. You didn't write the boilerplate yourself, you described an outcome, reviewed the proposed implementation with the same judgment you've developed over years, gave feedback, and verified the result. That's the entire point of this first exercise, not that AI writes code, but that AI, directed by someone who already knows what good software looks like, can dramatically accelerate the engineering loop.

A quick word on GitHub Copilot

If your workplace already has GitHub Copilot rolled out, and many enterprise .NET shops do, you might be wondering why I didn't start there instead. Fair question, and I'll be honest with you about it rather than pretend there's one obvious right answer.

Copilot lives mostly inside your editor, offering inline suggestions as you type and a chat experience for questions and assistance, which makes it feel like a natural extension of the IDE you already live in. Claude Code takes a different approach, operating more like an AI collaborator that can work across your project, reason about multi-step tasks, and execute actions from the terminal. That difference makes Claude Code particularly useful for the first exercise in this series, because I want you to experience what it feels like to delegate an engineering task to AI, rather than simply accept an autocomplete suggestion.

But neither approach is objectively superior. Depending on where you work, you may end up using one, the other, or both. What I'd ask you to take away from this chapter isn't that Claude Code is the only right choice, it's the underlying skill:

Describe intent clearly. Review AI-proposed changes critically. Give precise feedback. Verify the result. Stay in the driver's seat.

That skill transfers completely, whether the tool in front of you is Claude Code, Copilot, or whatever your company adopts next year. We'll come back to Copilot specifically, and how the same instincts apply there, once you've got a few more of these hands-on chapters behind you.

Where we go from here

You've now done something a lot of experienced .NET developers keep putting off. You've actually sat down and built something with an AI coding assistant instead of just reading about the idea of it.

That's step one.

And it's the one most people never take because they're waiting to "understand AI properly first."

You don't need to.

You can start where you are.

You already know how to build software. Now you're learning how to work with a new kind of collaborator and, soon, a new kind of dependency.

The next chapter is where the direction changes. Right now, you used AI to help you write code. Starting from the next chapter, you'll learn how to build AI directly into the applications you create. We'll start looking underneath the hood: what actually happens when your .NET application sends a request to an AI model, how the model sees your input, what comes back, and what you need to think about as an engineer when that model becomes part of your application.

That's where using AI starts turning into engineering with AI.

For now, though, sit with what you just did.

You installed something new.

You gave it a real engineering task.

You reviewed its work.

You corrected it.

And you verified the result.

You didn't stop being the engineer.

You changed the way you engineer.

And that's where this journey begins.

That's Chapter 1 of AI for .NET Engineers done.

If you want the next chapter the moment it's out, subscribe to this series. No spam, just the series as it comes out.