How a .NET Engineer Actually Applies AI to Real Applications

The next step in learning AI with .NET is seeing it inside an application that looks like the ones you build every day.

Let us take stock of where you are.

Step one: use AI. In Chapter 1, you installed Claude Code and let AI help you write .NET. Why it mattered: you learned the working loop of describing, reviewing, directing, and verifying.

Step two: call AI. In Chapter 2, your own code called a model through an Application Programming Interface (API). Why it mattered: you saw that it is an integration you already know how to build, with one new property, a non-deterministic response.

Step three: understand AI. In Chapter 3, you learned what models, tokens, context, caching, and temperature actually are. Why it mattered: you can now read an AI bill and predict an AI response.

Step four: run AI on Azure. In Chapter 4, you met Microsoft Foundry, deployments, and identity instead of secret keys. Why it mattered: AI stopped being a separate island and became another dependency on a platform you already know how to run.

Now step five.

Step five: see it inside a real application.

I want to be honest about something. So far, the examples in this series have been small on purpose. A text analyzer. A summarizer. A few commands in a terminal. They were the right size for learning one idea at a time.

But there is a question that probably sits at the back of your mind, even if you have not said it out loud.

I understand tokens, context, deployments, and identity. But what does a real AI feature actually look like inside an application? And where would I even put one in the systems I work on?

This chapter answers that question with two small applications. There is no new tool or code to learn. The goal is to help you recognize where a model fits, and where ordinary application code is the better choice.

The goal is not that you go and build these two applications. The goal is that you finish this chapter, look at the systems you already work on, and think: I know exactly where AI could fit here.

Two applications, two shapes

Here is something that makes AI features much easier to reason about. Almost every one you will be asked to build is one of two shapes.

The first shape is a conversation. Remember Chapter 3: the model forgets everything the moment it answers, so your application hands it the whole transcript again on every turn. It is like talking to someone who must read the minutes of the meeting aloud before they can reply.

The second shape is a one-shot task. Text goes in, better text comes out, and nothing carries over to the next request. It is a drop box, not a dialogue.

Our two applications are one of each.

The mock interview is the conversation. A candidate pastes in a job description, answers questions one at a time, gets brief feedback after each answer, and receives a report at the end.

The daily status tracker is the one-shot task. A team member writes rough notes about the day, and the application turns them into clear task descriptions.

In both, the model receives text and returns text. It does not search company data, call your functions, or take actions. Your application stays in charge of the flow and the business rules.

Application one: the mock interview

What it does

The candidate pastes a job description and picks a few settings, such as experience level and number of questions. The application asks one question at a time. After each answer, it gives short feedback and asks the next question. At the end, it produces a report with strengths, gaps, and topics to review.

What is under the hood

Five pieces, and none of them exotic.

• A web front end that displays questions and collects answers.
• An ASP.NET Core API that owns the rules: when the interview starts and ends, which question number is next, and what gets saved.
• An interview service behind an interface. It is the only part of your code that knows a model exists.
• A session store holding the job description, settings, question count, and transcript. Azure SQL or Cosmos DB both work. It must live outside web-server memory if your API runs on several instances, because any instance might receive the next answer.
• Two Foundry deployments: a smaller one for quick feedback and questions, and a larger one for the final report. Keep their names in configuration, so you can change the model behind a job without rewriting the application.

Here is the principle worth carrying out of this chapter: your application owns the flow, and the model owns the language. The model never decides when the interview ends. Your code does.

One turn, step by step

1. The candidate submits an answer. The API checks that the session exists, the answer is not empty, and it is within a length limit.
2. The interview service builds the request: the standing instructions, the job description, the conversation so far, the new answer, and a line your code adds, such as "This is question 4 of 10." Your code does the counting, not the model.
3. It calls the smaller deployment and asks for brief feedback plus one next question.
4. Only after a successful response does the API save the answer and the reply and advance the count.
5. The browser shows the feedback and the next question.

After the final answer, the service sends the full transcript to the larger deployment, with instructions to base every observation on what the candidate actually said.

The timeout trap

A request can time out after the model has already answered. The browser cannot tell. If it simply retries, you could record the same turn twice and pay for two calls.

The fix is ordinary distributed-systems engineering. Give each submitted turn a request identifier (ID) and store it with the result. A retry with the same ID returns the recorded result instead of repeating the work. And keep the candidate's answer on screen until the API confirms the turn is saved.

What it costs

Every turn resends the earlier ones, so each request is heavier than the last. A ten-question interview with its report comes to roughly 46,000 tokens, assuming a 1,500-token block of instructions and job description, 200-token answers, 250-token replies, and an 800-token report. These are illustrative estimates, not a quote. Real numbers depend on the tokenizer, the conversation, and retries, so measure them.

Cost grows faster than the number of questions, because the transcript keeps being resent. Limit the number of questions and the answer length. For longer sessions, replace older turns with a carefully prepared recap, and keep the original transcript in your store.

The repeated block of instructions at the start may qualify for prompt caching on supported models and deployments. But repetition alone does not guarantee a cache hit. Check the current Foundry documentation and monitor cached-token usage before counting any savings.

Where it can go wrong

Job descriptions and candidate answers are untrusted text. Telling the model to treat them as context, not instructions, may reduce off-task replies, but it is not a security boundary. What protects you is the design: the model can only generate text and has no tools, and authorization and business rules stay in code.

Test the flow with the interview service mocked: question limits, session state, saving, and the end condition. Test the model's behavior with saved sample interviews, and check properties, not exact wording. Does the feedback refer to what the candidate actually said? Does the next question fit the job description? Does the report avoid inventing details?

Application two: the daily status tracker

What it does

A team member types rough notes, such as "fixed login bug, waiting on QA for payment change, two hours in migration meetings." The application suggests concise task descriptions. The person reviews, edits, and approves. A manager sees entries by person and date, who has not submitted, and a weekly summary.

What is under the hood

A web application with company sign-in, a database, a polishing service behind an interface, and a scheduled job for weekly summaries. The application calls Foundry with its own identity.

Notice how little of this is AI. Sign-in, access control, saving entries, grouping by date, reminders, and dashboards are all ordinary code. The model has two narrow jobs: rewrite rough notes, and summarize approved entries.

Two design decisions matter here. The human stays in the loop, because the person is the only one who knows whether the polished text is true. And you store the original notes as well as the approved text, so you can regenerate entries if you improve the instructions or change the model later.

Guarding the rewrite

Each request is a short instruction plus one person's notes. The instruction asks the model to preserve names, identifiers, numbers, hours, and statuses, to add nothing, and to return only the rewrite.

Then your code checks the result. It flags ticket IDs or numbers that are missing from the rewrite, and numbers that appear in the rewrite but not in the notes. This is a heuristic, not proof. It will miss a subtle change of meaning, such as "waiting on QA" becoming "QA completed", and it may flag harmless changes like "two" becoming "2". That is exactly why the person approves before anything is saved.

Add a database uniqueness rule for each person and date, plus request IDs for retries, so repeated requests never create duplicate entries. And keep one rule above all the others: the polish is a convenience, never a blocker. If the model is unavailable, people can still submit their raw notes.

Weekly summaries in two stages

On Friday, a scheduled job summarizes each person's approved entries. A second step summarizes those per-person summaries for the team. Two small steps are cheaper and easier to check than one giant prompt with everything in it.

What it costs

Suppose twenty people each submit one entry on twenty-two workdays, and each request averages 250 input tokens and 150 output tokens. Daily polishing then uses about 176,000 tokens a month. With the weekly summaries, the whole application comes to roughly 280,000 tokens a month.

Now set that beside the interview. One mock interview with its report is about 46,000 tokens. So a team's entire month of status updates costs about as much as six mock interviews.

That is the lesson of this chapter in one number. Cost follows how much context each request carries, not how many requests you make. A small stateless feature can run thousands of times and stay cheap. A conversation gets expensive because of what it drags along.

Same caveat as before: these figures depend on assumptions, so measure real usage and check current pricing before planning a budget. Caching is unlikely to be the main lever here, because each request is mostly new text.

The two applications side by side

Five questions to ask before adding AI to any application

Does this task need a model? If ordinary code can do it deterministically, cheaply, and clearly, use ordinary code. Reserve the model for language work, such as judging a free-text answer or rewriting shorthand.

Which model and deployment fit the job? Start with the smallest tier that meets your quality and response-time needs. Test it with realistic examples, then move up only if the results justify it.

What context does each request need? A conversation resends its history and grows. A one-shot task stays small. Estimate with explicit assumptions, then measure real token usage.

Where do identity and access live? Users authenticate to your application, and the application authenticates to Foundry. For Azure-hosted .NET applications, Microsoft documents Microsoft Entra authentication with managed identities and role assignments. Check the current guidance for your endpoint and Software Development Kit (SDK).

How will you test and recover? Test properties that should hold, not exact phrasing. Plan for timeouts, retries, duplicate submissions, outages, and human review wherever a wrong answer matters.

The risk of a wrong answer should shape the checks around it. A clumsy meeting summary may be harmless. A changed figure in a financial report may not be. Decide what your application does when a result is uncertain, and make that behavior visible to the person using it.

Where could AI fit in your applications?

Look for free-text work that people currently read and judge by hand: support tickets, feedback, incident reports, customer emails. Could a model classify or summarize it? Look for repetitive, low-risk rewriting: release notes, meeting notes, short document summaries. These are usually the one-shot shape.

Then ask whether the feature needs to remember earlier messages. If it does, such as an internal assistant that answers follow-up questions, it is the conversation shape, and you need session storage and a plan for growing context.

Finally, ask whether code can do the job, what happens if the result is wrong, and whether the data is allowed to go to the model service you selected. The point is not to add AI everywhere. It is to recognize where it earns its place.

Try it yourself

This chapter has nothing to deploy. Each exercise takes about fifteen minutes.

1. Run the five questions on a real system. Pick an application you already work on and find one place where a person reads free text today. Decide its shape. Split the ordinary-code parts from the language parts. Name the model tier you would start with, estimate the context, and write down what should happen when the model is unavailable. One page is enough.

2. Do the token arithmetic. Take that feature and write down your assumptions: input tokens, output tokens, and requests per month. Multiply. Then paste a realistic input into Claude Code, as in Chapter 3, and check /context and /cost to see how close your guess was.

3. Try to catch the rewrite out. Write three deliberately messy status notes, each with a ticket number, an hour count, and one vague blocker. Ask Claude to polish them, using the instruction from this chapter. Then check every fact yourself. Did anything change? That is the check your code would automate, and any change it cannot catch is the reason a person approves.

Where this leaves you

You have now seen two ordinary applications through the eyes of an engineer. One carries a conversation. The other transforms a small piece of text. In both, your application owns the flow, identity, storage, and rules. The model handles the language.

If you remember only a few things from this chapter, remember these:

• Separate ordinary-code work from language work, and use a model only where it helps.
• Keep conversational memory in your application, and account for the context sent on every turn.
• Treat token estimates as estimates. Measure real usage, and verify caching support before counting savings.
• Use request IDs and saved state, so retries do not create duplicate turns or entries.
• Test what must be true, keep people involved when accuracy matters, and plan for model failure.

You did not need to become a different kind of engineer to get here. You used the skills you already have to decide where AI belongs, and where it does not.

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

If you want future chapters the moment they're out, subscribe to the series.