Aspire 13.3 introduces WithBrowserLogs, an extension that attaches a tracked Chromium browser to an endpoint-capable resource. Console logs and network activity stream back into the Aspire dashboard alongside your backend traces. For anyone debugging a frontend that talks to a distributed backend, this is the hop you've been making manually for years.

Linux Consumption is going away, and Microsoft's migration guidance points at Flex Consumption. But is Flex actually the right destination for your apps, or are the other paths Azure Functions on Azure Container Apps, Container Apps Jobs, AKS with KEDA, or plain ACA worth a closer look?

Can't use Microsoft Foundry because of compliance or an Azure bill that doubles during an AI development spike, but still want the best AI debugging experience in Aspire? Here's how to keep the full GenAI chat-log sparkles while Ollama and Gemma 4 run locally.

You're debugging an issue and ask your AI agent to write a quick script that checks your database state. It hands you Python or JavaScript. You can read it, sure, but you can't review it at a glance the way you can with C. With .NET 10's dotnet run file.cs, there's no reason to leave your main coding language anymore for the utility scripts your agent writes during development.

You've discussed the feature with your AI agent, it wrote the code for it, but then what? You start the app, open the browser, click around, look for bugs, find one, describe it back to the agent. You're doing all the boring manual labor of verifying that what was built actually works. With Aspire's CLI overhaul in 13.2 and its new skills combined with Playwright CLI/skills the agent can manage and monitor your distributed app, open the browser, test the feature, and debug it. The tedious verify-and-fix loop becomes the agent's job, not yours.

We've all been there. You open your repository on Monday morning and there are a dozen dependency update PRs waiting. Some are patch updates, some are minor, one is a major version bump buried in the middle. CI is green on all of them. You merge them. What could go wrong?

Most teams write documentation after the feature ships. By then the context is stale, the pressure to move on is high, and the ADR nobody wrote is already forgotten. The agentic dev workflow treats docs as something you generate alongside the code, not something you backfill when someone complains the wiki is out of date.

Most code quality checks exist in three places: a CI pipeline that runs after you push, a mental checklist you may or may not remember, and post-commit hooks that hit you with a wall of failures right when you thought you were done. The agentic workflow collapses all of these into a single command that runs before the PR, covers both .NET and Angular, and pairs automated scanning with reasoning about what the results mean.

Skills are the most powerful part of any agentic workflow, and they're also the easiest to get wrong. This post covers the full lifecycle: writing a skill from scratch, finding and adopting skills from the community, and closing the loop so your skills improve over time.

Everyone has opinions about how tests should look. Naming conventions, structure patterns, which mocking library to use. The problem with AI coding assistants is that they have collected opinions for their learnings too, and they're usually not yours.