Stefan Đokić | .NET

This reality hits: deadlines, new team members, rushed PRs, “we’ll fix it later.” Most #dotnet projects don’t fall apart because of bad developers. They fall apart because nobody decided how things should look when things get messy. At the beginning: ✔ clean structure ✔ good intentions ✔ “we’ll keep it tidy” Then reality hits: • deadlines • new team members • rushed PRs • “we’ll fix it later” And suddenly the codebase starts fighting back. This carousel shows the full curriculum of Pragmatic .NET Code Rules. Not as a syllabus. But as a system. A system that: - removes pointless decisions - enforces consistency automatically - keeps projects clean even when teams grow I made this course for developers who: • are tired of style debates • want predictable projects • care about long-term sanity, not quick wins Already 50+ developers joined during pre-order. And yes, you get access immediately. And yes, you get access to the community. You don’t wait. You apply. You improve your project while the course grows. 40% OFF Preorder price: $59.89 (Only 4 spots left at the price and only today) Original price is $150. 👉 Get it now here: thecodeman.net/pragmatic-dot… Curious, what’s the one rule your current codebase is missing?

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? 👇

My first thought: this is the right size of tool for AI agents. A lot of what an agent needs from the web is a simple yes/no. Does this library support .NET 10? Is this API still free? Does this vendor have an EU region? Running a full research loop for that is overkill. A fast answer with a source is all you need. There's a free MCP version too, so this is going into my Claude Code setup. #ParallelPartner

The hard part of building AI features isn't the AI. It's everything around it: retries, timeouts, cost tracking, prompt injection, evals. Same boring engineering. New failure modes.

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? 👇

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/

Je l vracamo Drzavni Posao? #drzavniposao

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