Milan Jovanović

I just launched Katabench, a practice platform for .NET developers. Most coding practice stops when the output is correct. Katabench grades the engineering qualities a green checkmark misses.

45,000+ developers use my Clean Architecture template. The most common question I get about it now is how to make AI write code that fits it. So I made it a first-class feature. My Clean Architecture template now ships with 4 agent skills: /add-feature turns one sentence into a full vertical slice. Command or query, handler, validator, minimal API endpoint, unit and integration tests. /add-entity wires a new entity through every layer. Error catalog, domain events, EF configuration, migration. /add-tests reads an existing use case, lists every outcome, then covers each failure path and the happy path. /ca-review checks your pending changes before you commit. Layer violations, missing auth, cache invalidation, test gaps. I type "/add-feature snooze a todo until a given date" and get the command, the validator, the handler with an ownership check and a domain event, the endpoint, and 9 tests. Built and verified, in the same shape as every other feature in the solution. Each skill is a plain Markdown file. Renamed your layers or swapped your test stack? Edit the skill once and every future feature follows suit. It's your team's conventions doc, except it executes. Get it here: milanjovanovic.tech/templates/clau…

You should never return null collections in C#. I've said this many times already. But what's the problem with returning null collections? You will typically iterate over a collection in a loop. But if your method returns null collections, this can lead to potential errors. Your code must handle the null case and check for null before accessing any collection elements. Adding a null check every time can make the code harder to read. It's even worse if the calling code doesn't handle the null case. Things will blow up at runtime, which is challenging to diagnose. You could argue that a null value expresses some intent. But I still prefer avoiding null in my code as much as possible. I think it's a best practice to return: - a new List() - Enumerable.Empty - Array.Empty - C# 12 collection expressions → [] This way, your code can safely iterate over the collection without worrying about null checks.

@zajkowskimarcin How could this go wrong

One of many upcoming.

@zajkowskimarcin Sol is amazing at driving things to completion with minimal intervention

@mjovanovictech 🙋🏼 especially when talking to Fable or Sol. I let more casual models write code these days ;)

I can relate...

@DanielGlejzner funny how lots of us come to the same ideas

@mjovanovictech Same, too many times lol

@MladenMacanovic at least they still listen, for now

@mjovanovictech Several times today...

@DriverGear slow down there buddy

@mjovanovictech 💯 it’s too enthusiastic at times lol

@AntonMartyniuk how often will it actually matter?

Note: These four options are not identical on performance. Enumerable.Empty() and Array.Empty() return a cached instance, so no allocation happens. A new List() always allocates a new object, even when empty. For hot paths, prefer Array.Empty() or Enumerable.Empty() over a new list.

@petarivanovv9 makes for less error conditions, so easier to reason about

@mjovanovictech I've noticed code reviews get smoother when collections are always non-null. The mental overhead drops and folks can focus on actual logic instead of defensive patterns everywhere.

@pavle_dav always will be

@mjovanovictech Waiting for "why not old way" comments 😁

@AntonMartyniuk @TheCodeMan__ @csharpfritz seems like there's more to it

@TheCodeMan__ @csharpfritz There is a big possibility that there will be no .NET Conf in 2026

I'm kind of happy for the .NET Community. Good luck man! @csharpfritz

𝗪𝗵𝗮𝘁 𝗶𝘀 𝗮𝗻 𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆? An API gateway is the "front door" to your backend services and APIs. It acts as an intermediary layer, handling client requests and routing them to the appropriate destinations. The key characteristics of an API gateway are: - Request routing and composition - Authentication and Authorization - Load balancing - Rate limiting - Monitoring - Caching An important role of API gateways is security. You can implement authentication at the gateway level, and only authenticated requests can be proxied to the backend services. A popular proxy library in .NET is YARP, which integrates with the built-in authentication and authorization components.

I've been thinking about where software actually gets written, and I don't think it stays on our PCs much longer. My prediction: the inner loop of development moves into the cloud. Not the deploy step. We did that years ago. The writing step. For most of my career, the cloud was where code ran. The writing stayed local: editor, runtime, git. Agents break that. Once an agent can write code, run the tests, and open a PR on its own, the bottleneck stops being me at the keyboard. It becomes how many agent loops I can run at once. And I can't run many on a PC. Two or three and it chokes. It's also the worst place to run them: ambient credentials, full network access, one hallucinated rm -rf running with my permissions. So the loop has to move to where the compute and guardrails already live. That's what got me looking at Coder. Coder Agents runs that loop on infrastructure you control, whether that's your VPC, on-prem, or even air-gapped. Underneath, the open-source Workspaces platform spins up a sandboxed workspace per agent and throws it away when the work is done. My PC goes back to being where I review the work, not where it happens. I had the same objection you probably do: doesn't "cloud" mean my code leaves the building? Not if it's your infrastructure. With Coder, the model key never sits in the workspace with your code. Only the control plane makes the model call. And you pick the boundary: a self-hosted model and nothing leaves your network, or an endpoint in your own cloud. It's model-agnostic, too. I'm not betting my whole workflow on whoever's ahead this quarter. Coder got the order right: Workspaces first, Agents on top. Not an agent with infrastructure bolted on after. The agents will keep changing. Where they run is the decision that doesn't. So I don't think the question stays "which agent is smartest". It becomes "where do your agents run". Here's how Coder Agents approaches it: fandf.co/4dZwi9l Curious whether you're seeing it the same way. Let me know in the comments. Thanks to @coderhq for collaborating with me on this post.

@orcdev Probably harder

is it harder or easier to get a dev job today than it was a few years ago? really hard to tell

@ZohanD32951 surprise: devs also produce slop

@mjovanovictech Yes but with caveats - needs clear business requirements - needs robust technical documentation - needs constant vetting and manual intervention And let's be honest most tech companies dont really have that, so in many cases AI agent just produce slop

actually, vibe coding can look like the right (whatever that is) if you are using it like a software engineer (and not vibing)

@AntonMartyniuk Traefik is nice, using it via Dokploy for my SaaS Easy to configure also

@mjovanovictech Gateway choices you have: - Cloud Gateways offered by Azure, AWS, GCP - Traefik - Envoy - YARP (best ASP .NET Core integration, fast but fewer features than those above) - Nginx (super fast, but hard to configure) - Apache (hell to configure)