Stop wasting the first 3 days of every project setting up boilerplate. I built a free, production-ready Clean Architecture template to handle the setup for you. It's already used by 40,000 developers. Here is what's inside the latest version: - 𝗨𝗽𝗱𝗮𝘁𝗲𝗱 𝘁𝗼 .𝗡𝗘𝗧 𝟭𝟬 - 𝗡𝗲𝘄 .𝘀𝗹𝗻𝘅 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗙𝗼𝗿𝗺𝗮𝘁 - CQRS (no MediatR dependency) - Structured Logging & Validation - JWT Authentication & RBAC - Docker Compose support It saves you hours of setup time. Download it for free here: milanjovanovic.tech/template… 💡 Why the shift to .slnx? The new Solution format in .NET is a game-changer. It replaces the old bloated syntax with a clean XML syntax. It makes merge conflicts in your solution file a thing of the past.

I burned 7,000 GitHub Copilot credits in one afternoon. Same prompt, same model in Claude Code: faster, and way more usage per dollar. Full breakdown: youtu.be/VBmhUmDVMuk

My first useful AI app did not need an agent. It did not need a chat UI either. I had years of blog posts on many topics: → Architecture → Cloud → Security → DevOps → Programming But no good way to sort them. So I built a small app that reads a blog post and puts it into the right group using AI. The interesting part? The full app took less than an hour to build. With GitHub Models and .NET Aspire, I did not need to spend time setting up a model provider by hand. I could treat the AI model like another app resource: → Choose a model → Connect it to the app → Send the content → Get back a category → See the full request trace in the Aspire Dashboard This is the kind of AI feature I find useful. Before building a complex AI feature, try finding one boring manual step in your app. Sorting content. Summarizing text. Extracting details. Classifying support requests. That is often the best place to start. I built one of these features in .NET and explained the full setup here: milanjovanovic.tech/blog/bui…

Those who know Those who don't know

A few years ago, I was rewriting a 40-year-old project. A big challenge was keeping the legacy and new databases in sync. We decided to build a two-way sync process. But it was more complex than initially anticipated. Like any estimate, right? Here's why we couldn't use CDC solutions like Debezium: 1. Complex transformations: Many legacy tables required data from multiple new tables. This wasn't a simple one-to-one mapping that CDC tools excel at. 2. Business logic sync: The sync process needed to apply business rules during transformation. This went beyond what most CDC tools provide. Here's what we ended up doing. We built a custom solution that uses RabbitMQ for message transport. Many engineering hours went into this component to make it stable. The unfortunate part is that it should stop working once the migration is complete. What's your experience with legacy systems? P.S. If you're curious, I wrote more about this legacy rewrite here: milanjovanovic.tech/blog/wha…

At least I got some good usage out of Fable 5 while it was available

Hardcoded model="claude-fable-5" in 47 places across my codebase. Thanks for the heads up, looking forward to my weekend now.

All of us right now

Wrote about building Dapr workflows using Aspire: milanjovanovic.tech/blog/bui…

It was fun while it lasted. Goodbye Fable 5

Every abstraction in your .NET app has a cost. An interface. A repository. A service wrapper. A mapper around a mapper. Each one can make sense. But each one also gives the next developer one more place to look before they find the real logic. The problem is not abstractions. The problem is adding them out of habit. Wrapping a payment provider? That can be useful. External systems change. You may need to swap one provider for another. Adding a service that only passes calls to a repository? That may only make the code harder to follow. Before adding another layer, I like to ask: → What change is this protecting me from? → Do I have a real need for more than one version? → Does this hide useful details, like how a query runs? → Would the code be simpler without it? Clean code is not the code with the most layers. It is the code where every layer has a reason to exist. I have added abstractions too early before. These are the rules I now use to decide which ones earn their place, and which ones should go: milanjovanovic.tech/blog/the…

Most AI agents don't fail because they're dumb. They fail because they can't find the right data. The model is smart. But the data it needs is spread out. Some sits in your database. Some in a ticket system. Some in an old doc no one has opened in months. So the agent guesses. And you get a bad answer. If you've built an app like this, you know the pain. The data lives in five places. None of it talks to each other. And now we're asking AI to make sense of all of it, live. Here's what I keep coming back to: this is a tooling problem, not a brains problem. If we want AI to work at scale, we need better plumbing under it. That's why Redis Iris caught my eye. It's a "context engine". Think of it as a layer that sits between your agent and your data. Its one job is to feed the agent the right context, fast. A few things it does: - Pulls live data from your systems, so nothing goes stale - Gives the agent a clean path to your data, so it stops guessing - Remembers past chats, so it doesn't start from zero each time - Caches repeat answers to save time and tokens What I like most: it's built on Redis. The same tool a lot of us already trust for caching. So it's not one more strange thing to learn. We're still early in all of this. But better tools like this are how AI agents go from "cool demo" to "I trust it in production". Curious how it works? Take a look here: fandf.co/3Qan56b Thanks to @Redisinc for sponsoring this post.

Your .NET app has three services, a database, and a message queue. A request is slow. Where is the performance problem? Was it the API? A database query? A call to another service? A failed message handler? Logs alone often do not give you the full picture. This is where the Aspire Dashboard is useful. And you do not need to move your app to Aspire orchestration to use it. You can run the dashboard as a standalone container next to your existing setup. Then send OpenTelemetry data from your services to it. You get: → Structured logs in one place → Traces across service calls → Metrics for requests and errors → A much faster way to find slow parts of the system There is one important limit: The standalone dashboard stores data in memory (persistence when?!). That makes it great for local development and debugging. Not for production monitoring. So, when I need to understand what a distributed .NET app is doing on my machine, this is one of the simplest tools I can add. I wrote a short guide showing how to connect the Aspire Dashboard to an existing .NET setup: milanjovanovic.tech/blog/sta…

Aspire, not .NET Aspire

I made it to Today's News on X

There's a big difference between AI writing your code AND you knowing what you want to accomplish, versus just driving blind and hoping the AI does a good enough job. If you can steer LLMs in the right direction, they are an incredible force multiplier.

My design patterns ebook isn't an ebook anymore. It's a written course. I rebuilt Design Patterns That Deliver: thecodeman.net/design-patter… from the ground up. Here's what you get now: → 10 production patterns instead of 5. Builder, Decorator, Strategy, Adapter, Mediator. Plus Result, Pipeline, Specification, Factory, and State. → Every chapter goes from a real problem to working C# code. Unit tests. Async. Trade-offs. And an honest "when NOT to use this." → A web reader to read it all online, with real copyable code. → A free Pattern Picker that tells you which pattern fits your problem in seconds. → An AI tutor, "Ask the Book," that answers from the book itself, cited by chapter. Not generic internet code. And it keeps growing. Coming soon: → more free AI tools → in-browser C# playground where you edit and run pattern code with no install, powered by .NET WebAssembly. Here's the part that matters if it's been on your list: The price is still $32.99. With everything that just went on, it's going to go up soon. Buy now, and you lock in today's price and get every future update free. The full Builder chapter is free to read first. The Pattern Picker is free too. Link in the comments. Check it out here: thecodeman.net/design-patter… Which of the 10 patterns do you reach for most in real projects?

Can you implement Clean Architecture without the layers? Yes. Here's how. The main idea behind Clean Architecture is managing the direction of dependencies. All dependencies should point to the center - the application core. In .NET, it's common to achieve this by separating code into projects. Why? Separate projects make it easier to control dependencies. But it's really just folders on the file system and compiler rules. What's stopping you from having one project with all the "layers"? Nothing. Except... Now it becomes easy to "break" the rules of Clean Architecture. If your team is disciplined and knows what they're doing, no problem. But most teams need the safeguard that project separation provides. I talked about architecture tests in the past. Architecture tests can help you enforce the direction of dependencies. What do you think about this idea?