Stefan Đokić | .NET

My Claude Code setup was one CLAUDE. md file. For months. And I kept re-explaining the same project conventions in every session, wondering why the output was hit or miss. Turns out there's a whole project structure under .claude/ that almost nobody uses. CLAUDE .md (or AGENTS .md today) is just the entry point, the "project brain" that loads at session start with your stack, architecture, and commands. • The rules/ folder is where it gets good. Instead of one giant file, you split instructions by topic: code-style .md, testing .md, api-conventions .md. They can even target specific paths in your repo. • commands/ holds repeatable workflows as slash commands. I run /review and /fix-issue daily. • skills/ load only when the task needs them, so your main context stays small. • agents/ are sub-agents with their own isolated context. A code reviewer that doesn't pollute your main conversation. • hooks/ run before or after tool calls. Mine blocks anything unsafe before it executes. • And .mcp.json wires up external tools and lives in Git, so the whole team shares the same setup. I made a visual of the full structure; it's below. If you set up just one thing from this, make it the rules/ folder. And if you want to go deeper into agents, skills, and practical AI for .NET developers, join the group here: skool.com/ai-for-dotnet-deve…

Everyone wants to rewrite the legacy .NET app. Almost everyone who tries it fails. The rewrite is a trap: 18 months, a feature freeze, and a new system that still doesn't do what the old one quietly did in production. Here's the workflow I use to modernize legacy .NET with Claude - as a workflow, not a "rewrite" button: 1. Assess (read-only). Point read-only AI agents at the codebase to produce a sequenced roadmap - ordered by risk and business value, not vibes. 2. Build a safety net. Write characterization tests that capture what the code does NOW (bugs included). You can't refactor what you can't verify. 3. Fix debt first, on the old framework. SQL injection, missing transactions, leaks - fix correctness and security while the tests hold behavior steady. 4. Carve seams, then upgrade. Introduce DI boundaries, then move one major framework version at a time, verifying between each hop. The division of labor that makes it work: AI does the mechanical grind (tests, parameterizing queries, API swaps). You keep the architectural judgment and keep the build green the whole way. Full workflow: thecodeman.net/posts/refacto… Rewrite or incremental - where do you land on legacy systems? 👇 #dotnet #ai #claude #legacycode #refactoring

5 Claude Code skills every .NET dev should build. A "skill" is just a folder with a SKILL.md that turns a repeated prompt into a reusable tool. Here are the 5 I'd set up first: 1. Integration test writer "Write an integration test for this endpoint using xUnit + Testcontainers, our way." Never hand-write the boilerplate again. 2. EF query reviewer Auto-checks changed queries for N+1s, missing AsNoTracking, and IEnumerable-vs-IQueryable traps. 3. Minimal API scaffolder Give it a feature name, get a full vertical slice: endpoint + handler + validation + request/response. 4. PR reviewer (as an agent) Explores the diff on its own and flags correctness, naming, and missing tests before a human looks. 5. Release notes generator Turns merged PRs since the last tag into clean, human-readable release notes. The pattern: anything you prompt more than 3 times should be a skill. Build it once, it triggers itself forever. I share my actual .NET skill files (50+) inside the AI for .NET Developers community - 7-day free trial: skool.com/ai-for-dotnet-deve… Which of these would save you the most time? 👇

I deleted my architecture diagram. Then I let an AI agent redraw it, from the code itself. Here's what happened 👇 I connected my AI coding agent to Miro using the Miro MCP server. Two lines of config, one login, now the agent can read and write my Miro boards directly. Then I pointed it at a normal .NET solution (Clean Architecture + EF Core) and asked for three things: • An architecture diagram → it read the project references and drew every layer + its dependencies. Instantly showed whether the dependency rule was actually respected. • An ER diagram → straight from my EF Core DbContext. Tables, keys, relationships. Generated from the code that runs in production, so it can't drift out of sync. • A sequence diagram → "trace the Create Order request." Controller → handler → repository → DB, drawn out end to end. A few minutes. Empty board → living map of the whole system. And because it's all on Miro, the team can refine it together instead of me explaining the architecture verbally for the 100th time. The part I like most: when the code changes, you re-run the prompt and the board updates. Diagrams that finally keep up with reality. Full video - every prompt, every diagram appearing live: 👉 youtu.be/UUO5heMgS34?si=UpFY… Huge thanks to Miro for sponsoring this one. The MCP server is free to set up with your AI coding tool. Try the Miro MCP Server here: miro.pxf.io/en2e3z Have you tried generating diagrams from your codebase yet? 👇

FunctionInvokingChatClient in .NET allows up to 40 model round trips per request by default. One confused agent, 40 paid calls for a single question. Set MaximumIterationsPerRequest to what your flow actually needs.

Your API endpoint takes 5 minutes to respond. That's not an endpoint. That's a hostage situation. 😅 - The user stares at a spinner. - Your server holds a thread for the whole time. - A load balancer quietly kills the request after 60 seconds. - The client retries, and now the same report is being built twice. A faster endpoint won't save you here. A different shape will. Here's the flow (follow the numbers on the visual): 1. Client sends POST /reports 2. API answers in ~20 ms with 202 Accepted + a Location header pointing to /reports/42 3. API drops the job into a queue - nothing heavy happens in the request 4. A background worker picks it up and does the 5-minute work 5. Client polls GET /reports/42 and gets "Running" 6. Client polls again and gets "Done" + the result URL What you get: → Request threads are free in milliseconds, not minutes → No more proxy timeouts, because no request lives longer than a few ms → Workers scale independently of the web tier - 10 workers, 2 API instances, your call → Retries are safe, because the client asks for the status of job 42 instead of starting a new one Two small details that make it production-ready: → Return a Retry-After header, so clients know how often to poll → Swap polling for SignalR or a webhook when you need push instead of pull The mental shift: long-running work is a resource you create, not a response you wait for. How do you handle long-running work in your APIs today - polling, webhooks or SignalR? Join 25k+ engineers to learn more every week: thecodeman.net/

Most teams that move to microservices don't have a scaling problem. They have an organization problem, and they pick a distributed system to solve it. Start with a modular monolith. Extract a module when it really needs to scale on its own.

I tried to commit a file, and git said no. An AI read my staged diff, found a hardcoded Stripe key, and blocked the commit (Headless agent). ~10 lines of PowerShell: claude -p + --json-schema + a pre-commit hook. Fail closed. Full video: youtube.com/watch?v=x-Wik3HH… #ClaudeCode #dotnet

An AI agent in .NET is a loop: IChatClient sends the message + tools -> the model asks for a tool -> FunctionInvokingChatClient runs your C# method -> the result goes back -> repeat. The model never touches your database. It only asks.

An AI reviewed my .NET pull request on a whiteboard and caught 3 real bugs hidden in a 60-file diff - before I hit merge. Full walkthrough, every prompt: youtube.com/watch?v=1kBiCImY…