An AI engineering roadmap for .NET developers: from first API call to agents

Short answer: AI engineering is building reliable software on top of large language models (LLMs) that you call through an API. Learn it in this order: the LLM API itself (tokens, context, structured output), then retrieval-augmented generation (RAG), then the Model Context Protocol (MCP), then agents that call tools in a loop, and finally evals, the tests that tell you whether any of it works. Each stage builds on the previous one, and each has a small project that proves you've got it.

Why a backend developer is already halfway there

Most of the work in an AI feature is not the model. It's the code around it: reading and cleaning data, calling an external API that is slow and sometimes fails, validating what comes back, logging, retries, cost limits, and tests. That is everyday backend work.

What is new is that the external API is non-deterministic. The same input can produce different output, and "correct" is often a judgement rather than an equality check. The roadmap below is ordered so that you learn to control that uncertainty step by step instead of meeting all of it at once.

Stage 1: the LLM API

Learn: what a token is, the context window, system prompts, structured output (JSON that matches a schema), streaming, stop reasons, and how usage turns into cost.

Build: a support-email classifier that returns typed JSON your code can trust.

This stage is the foundation. If you can't get predictable, typed output from one call, nothing later will be reliable. Details and runnable C#: LLM API basics for .NET developers.

Stage 2: RAG (retrieval-augmented generation)

Learn: why a model doesn't know your private data, chunking, embeddings and vector search, and how to make the model answer only from what you retrieved and cite it.

Build: "ask the docs" over your own product documentation or internal wiki.

RAG is the most common pattern in real products, because it connects a general model to specific, current data without training anything. See RAG in .NET.

Stage 3: MCP (Model Context Protocol)

Learn: the open protocol that lets AI apps (the AI agent, IDE assistants and others) discover and call tools and data you expose, the difference between tools, resources and prompts, and the stdio and HTTP transports.

Build: an MCP server in C# that exposes one read-only query over your database.

MCP turns "integrate my system with an AI app" from custom glue per app into one server that every MCP client can use. See building an MCP server in C#.

Stage 4: agents and tool calling

Learn: the tool-use loop (the model asks for a tool, your code runs it, the result goes back), error results, limits on the number of turns, and keeping a human in the loop for anything irreversible.

Build: a support assistant that looks up an order and drafts a reply, but never sends or refunds on its own.

Agents are powerful and easy to over-use; start with a fixed workflow and add autonomy only where it pays. See AI agents and tool calling in .NET.

Stage 5: evals and production

Learn: building a small set of real test cases, grading outputs with code checks where possible and with a model only where you must, tracking cost and latency, and logging prompts and responses safely.

Build: an eval for one of your earlier projects that you run before every prompt change.

Evals are the unit tests of AI engineering. Without them, every prompt change is a guess.

Your first call, in C#

Every stage starts from the same request. Create a console app with dotnet new console, add the official SDK with dotnet add package Anthropic, set the ANTHROPIC_API_KEY environment variable, and replace Program.cs:

using Anthropic;
using Anthropic.Models.Messages;

AnthropicClient client = new(); // reads ANTHROPIC_API_KEY

var response = await client.Messages.Create(new MessageCreateParams
{
    Model = "claude-opus-5",
    MaxTokens = 1024,
    System = "You explain backend concepts to .NET developers in three sentences or fewer.",
    Messages = [new UserMessageParam { Content = "What is a context window?" }],
});

foreach (var text in response.Content.Select(b => b.Value).OfType<TextBlock>())
{
    Console.WriteLine(text.Text);
}

Console.WriteLine($"stop: {response.StopReason}, tokens in/out: {response.Usage.InputTokens}/{response.Usage.OutputTokens}");

Three things to notice already:

• The system prompt sets the rules; the user message carries the input. Keep them separate.
• MaxTokens caps the length of the reply, not the input. If the reply hits it, StopReason says so and the answer is cut off.
• Usage is reported on every response. Log it from day one; it is your cost.

What to skip at the beginning

• Training or fine-tuning models. Most product problems are solved by better context (RAG) and better instructions, not by training.
• Big agent frameworks. Learn the tool loop by hand first; it's about a hundred lines. Then you'll know what a framework does for you.
• Chasing every new model. Pick one, learn its behaviour, and build evals. Switching models is cheap once you can measure the difference.

Pros and cons of learning in this order

Pros

• Every stage produces something that works on its own, so you can stop at any point and still ship value.
• Reliability skills (structured output, grounding, evals) come before autonomy, which is where most failures happen.
• It reuses what backend developers already know: APIs, databases, testing.

Cons

• Evals come last in the list, but they're useful from stage 1; once you have a few real examples, start writing them early.
• It focuses on building with hosted models. If your work requires running open models on your own GPUs, you'll need an extra stage on deployment and inference.

Want an AI feature added to an existing .NET system, with the boring parts done properly? See how I can help.