Developers, Developers, Developers! ⭐

Like its predecessors, Build 2026 unleashed a tsunami of news, most tied to Microsoft’s strategy of the era. For many years–well over a decade, I’m trying to block this out–that strategy was all about Azure and cloud computing. And that’s a topic so thoroughly uninteresting to Windows fans and other technology enthusiasts that Build became a tedious slog of trying to find a proverbial needle in a haystack each year. But then things change, as they do.

From cloud to AI to AI agents

Microsoft moved us all decidedly into a new era, the AI era, when it announced a set of services that it would later rename as Copilot in February 2023. AI is interesting for all kinds of reasons. For Microsoft, it was a chance to reassert its influence on the industry and take advantage of the cloud infrastructure it built out for Azure in expansive new ways. But where Windows was largely ignored during Microsoft’s cloud era, and thus wasn’t a hot topic at Build during that time, AI marks a comeback for our favorite operating system. Windows, suddenly, is important again.

This is good and bad.

As I’ve said so many times, Microsoft didn’t just ignore Windows for many years, it often undermined the platform be engaging in what we now call enshittification, a process by which Windows 11, in this case, was made worse for users through a series of bad, user hostile behaviors like forced telemetry, tracking usage and selling that information to advertisers, bundled crapware, forced Microsoft account (MSA) sign-ins, forced Microsoft Edge usage, and a lot more. The problem got so bad that I ultimately wrote a book, De-Enshittify Windows 11 to collect all the ways in which we, as human beings and customers, can make this thing work the way we want.

But Microsoft’s newfound need to drive AI to the client in ways it can at least partially own and control triggered a rethinking about how Windows 11 fits into the grander scheme of things. At first, Microsoft’s need to jam AI down its customers’ collective throats was nothing more than further enshittification, seen more obviously in a painful episode in late 2023 when it delivered the first version of Copilot for Windows 11 alongside dozens of other new features in a normal monthly cumulative update ahead of a major (version 23H2) OS upgrade that would have typically delivered those changes. Microsoft did that specifically to prevent its corporate customers from skipping the 23H2 release and delaying the rollout of Copilot for another year. And it has since changed how it releases new features into Windows 11 to ensure that slow-moving companies can no longer purposefully stick with older OS versions to avoid getting those new features.

Many have theories about the changes we’re seeing this year. My bet is on corporate customers, Microsoft’s most important customers, finally pushing back on the enshittification, most especially the low quality of the chaotic feature updates that Microsoft was forcing on them every single month. But customers not adopting Copilot was perhaps as big a problem. As AI evolved from chatbots and generative AI to agents that can interact with apps and services in more sophisticated, hands-off ways, Microsoft started needing a more solid foundation for this work in its core client platform. And if it could offload as much AI activity as possible from expensive cloud datacenters to no-cost AI that’s locally installed on PCs, all the better.

Whatever the reasons, by the time 2025 was coming to a close, we had a newly more powerful Pavan Davuluri reorganizing the Windows organization so that it could turn things around and do something it had not done at this scale since Windows 7, a product that was kicked off internally almost exactly 20 years ago. It would focus on quality but addressing the pain points that customers had been complaining about for years. The missing features. The poor performance and latency of apps and core UI surfaces. Even some of the enshittification.

And then something bizarre happened. As this new and newly energized Windows organization began engaging with enthusiasts online, via the Windows Insider Program blog and on social media, one overly-enthusiastic project lead declared that Microsoft, which had made Windows 11 a big tent melting pot of apps of every kind imaginable, was working on “100 percent native” Windows apps. This seemed far-fetched to me, given that there is no such thing as native apps in Windows any more, not really, while Microsoft’s most recent and modern app development framework, the Windows App SDK, is terrible in so many ways. Like Windows 11 itself, it was run by C-teamers (not even B-teamers) with no power to change anything and no ability to improve things for developers. People would make promises to “fix” the Windows App SDK. And then they would quietly leave Microsoft because it was impossible to do that under the old system and nothing would change.

But something did change. Davuluri’s reorg brought changes to Windows app development too. And that mean that the Windows App SDK and its WinUI 3 UI framework would get attention, just like Windows 11. Microsoft began plotting to fix the pain points with “native” Windows app development–I hate calling it that, but you can’t fight the language of its makers–and in the same way. That is, it’s not releasing a new thing, in this case yet another Windows app development framework. It’s fixing the current thing. It’s going to improve the Windows App SDK and WinUI 3 by addressing developer pain points and adapting these framework for the AI era.

How we got here

When I think about the work Microsoft is doing to improve Windows 11 for its users, I am reminded of my role as a canary in this coalmine. Back in December, months before Pavan Davuluri made any public promises about address pain points, I noticed that Microsoft had taken steps to address the forced OneDrive Folder Backup issue that became my central issue with enshittification in Windows 11. To this day, Microsoft has never formally discussed that work, but it’s there, and by the time Davuluri started speaking vaguely about focusing on quality in 2026, I could see all kinds of hints of change, many of which are tied to security and reliability.

Since then, Davuluri went public with the changes his team was planning and then it just started implementing those changes, with some low-level reliability and performance changes already appearing in stable and bigger features, like redesigned Windows Update, Start, and Taskbar experiences, now making their way through the Insider Program. I’ve already written about all that many times. But it’s a new era, and it’s mostly very good news.

I am not a software developer. And yet, thanks to years of work on software development projects, many of which are Notepad clones like .NETpad and WinUIpad, I feel like I have played a similar role as canary. When Microsoft announced that it was bringing WPF, still my favorite Windows app framework, back from the dead and modernizing it for Windows 11, I could not have been happier. I immediately set out to modernize .NETpad and then spent the next several months doing so. And continued that work into 2024 before realizing that there were some modern features that simply would never work in WPF. And so I switched to the Windows App SDK and WinUI, renamed the app to WinUIpad, and spent the next year or more working on that.

Which was difficult. Because the Windows App SDK is terrible. Modern, yes. But convoluted and missing too many basic features from past framework (like printing) to count. It’s been frustrating, which I assume is a key component of the Windows/.NET developer experience for most real developers too. Actually, I don’t have to assume that. Microsoft has acknowledged this many times, just as it’s promised to fix issues, in part by open-sourcing this framework so that the community everyone was relying on anyway could play a more formal role in its evolution and future.

Build 2026 and the future of modern, native Windows apps

Earlier this year, Microsoft made some quiet Windows App SDK-adjacent moves related to the news that just came out of Build 2026. There was the Windows App Development (WinApp) CLI that Microsoft announced this past January, and then the Microsoft Store CLI, which initially seemed like a superfluous alternative to the Windows Package Manager (winget).

And then we had the several Windows developer announcements during the Build 2026 keynote, some tied to Terminal, some tied to the Windows Subsystem for Linux (WSL), and some tied to even more new CLIs, or command line interfaces. But they all have one thing in common, AI. Microsoft is expanding access to what were previously Copilot+ PC exclusive APIs to PCs with powerful CPUs and GPUs, too. And it is delivering on its promise to integrate AI agents into Windows, though now we know this will be done securely thanks to the Microsoft Execution Containers (MXC) SDK.

One of the CLIs Microsoft announced, the Windows Developer Skills, was so interesting that I dove headfirst into that same day. This is essentially a plugin for GitHub Copilot, Claude Code, or ChatGPT Codex, and any other compatible AI-based pair programmer agent that grounds the AI in the Windows App SDK and WinUI and lets you vibe-code a new, modern Windows 11 app right from the command line. Which is exactly what I did: In less than one hour, I used this thing to create a reasonable facsimile of the .NETpad/WinUIpad apps it had taken me–again, not a real programmer–years to make.

This is all very exciting. But I want more details on all of.

For example, that API thing I mentioned above is obviously tied to the new Nvidia Arm-based hardware that was also announced this week, with first-party and third-party PCs coming later this year. And though Microsoft vaguely admitted to making some platform-level changes for this, it never explained how/if this will change Copilot+ PC as a brand or designation.

On the developer front, I could see that the combination of the Windows Developer Skills, which relies on the WinApp CLI in the background, and whatever AI pair programmer solution (I happened to use Claude Code) was a bit piece, but still just a piece, of a bigger puzzle. And as the first day of Build 2026 drew to a close, I began wondering what we might learn the next day via whatever sessions. There is always more information in the Build sessions.

On Wednesday, day two of Build, I brought up the event website and searched for Pavan Davuluri to see whether he would appear at the show, as he wasn’t in the keynote like I had expected. After all, his appearance at Ignite 2025 in November was excellent, and though the topic, adding agentic AI to Windows 11, was controversial, what he and the team announced makes sense and doesn’t seem threatening or whatever. But he didn’t come up in the search of Build 2026. So I got on with the day, my afternoon dominated by a three-hour Windows Weekly recording, and earmarked some Windows-related sessions to watch later.

As Windows Weekly was winding down, I saw a notification in my tech feed for yet another new Microsoft CLI called Build CLI. Like the Windows Developers Skills I used to vibe-code yet another Notepad clone, this is a plug-in for GitHub Copilot, meaning it will also work with Claude Code and ChatGPT Codex, that grounds the AI in the content from Build 2026 (and Build 2025 and Ignite 2025) so you find information you want from a command line.

Hm. This seemed vaguely silly to me, since you can easily search the Build website for sessions and download relevant videos, transcripts, and presentations. But then again, AI is often used to summarize, and I could see where asking it for the best sessions to learn about whatever topics could be useful. Also, you can connect a software project to the Build content via this CLI and then ask it questions that are relevant to the work you’re currently doing.

And whatever, I love CLIs, so I had to try it.

To get started, I first had to connect the Build CLI to Claude Code. So I ran the following two commands from a Terminal window.

claude plugin marketplace add microsoft/Build-CLI

claude plugin install microsoft-events@microsoft-events-marketplace

Then, I ran Claude Code with this command line to ground it only in the Build content.

claude /microsoft-events:microsoft-build

Not that it matters, but the documentation on the Build CLI page on GitHub is wrong when it comes to Claude Code and it omits that last step, which is obviously crucial. But that’s how you really do it. (You can also just start Claude Code and ask it about Build, and it will ask if you want to load that skill.)

After an annoying series of confirmations, it finally spit out a nice list of the major announcements, sorted by topics like Windows, Copilot & GitHub, and whatever else, and asked me if I wanted to “dig into any of these announcements, pull session details, or search Learn docs for technical depth on a specific topic.”

Nice.

My first request was perhaps overly-broad.

Can you show me more about the Windows sessions?

Claude Code went through the familiar machinations, requiring further confirmations, and then spent over 2 minutes perambulating or whatever before finally returning a lengthy list of things, nicely laid out with text-based boxes.

The conclusion was good, though: “The big themes across all Windows sessions: Agents on Windows (Windows 365 for Agents, Aion, MCP, OpenClaw/Claws runtime), Local AI (Foundry Local, Windows ML, 2-bit models), WSL/Containers, and Arm/Snapdragon migration tooling. Want me to pull the full description for any specific session?”

No. So far this is information I could have mostly gotten with a simple (and faster) search on the Build website. But since I was here, I decided to narrow the search.

how about any sessions about the Windows App SDK and WinUI

This one didn’t take quite as long, about 28 seconds, though it, too, would have been faster from the web. But what it came up with was still useful.

And that’s when I saw it. Chris Anderson. A living legend. Surely, this could not be the same Chris Anderson who stood on a stage at PDC 2003 with Don Box and hand-coded Avalon UI code–what became WPF and XAML–to create the first live demos of real, running Longhorn apps using nothing more than Notepad and a command line window. This remains the greatest single live coding demo in the history of Microsoft and probably the entire industry.

Well, it is the same Chris Anderson. Somehow, incredibly, he’s still at Microsoft. And though his session, a prerecorded video, is less than 30 minutes long, it is predictably an excellent watch and well worth your time. Anderson, a vice president of software engineering at Microsoft, starts off in the most humble fashion imaginable by describing himself as “an engineer on the WinUI team,” as if he were a college intern and not the voice of experience and expertise. And then he lays it down. What he provides, in essence, is clarity and surety. It’s a message beleaguered Windows developers need to hear.

Here are the key points, as arranged by my brain and not AI.

WinUI is it. There’s no new framework coming down the pike. WinUI is the modern UI framework for Windows and Windows App SDK is its underlying app framework. Microsoft has “no intention of building a new framework.”

Now it’s literally called WinUI. Microsoft is “dropping the number,” so WinUI 3 is gone, and now it’s just WinUI.

WinUI is coming to more of Windows 11. As Microsoft already explained (and in other places, hinted), it is integrating WinUI into the Windows 11 shell “at a much faster rate.” Per the “100 percent native app” pledge, “you’re going to see a lot of the first-party features coming from Microsoft being built on top of WinUI.”

Microsoft is addressing the pain points. Microsoft is fixing low-level issues with WinUI–“performance, fundamentals, quality, fixing a lot of bugs”–and looking at feedback and adding missing features so that developers can be “be productive on top of WinUI.” But it’s also addressing “feature gaps.” It announced two new controls, DataGrid and Charting, at Build, but there are “just a ton of feature gaps in the platform, everything from what are you doing on system tray … to limited use of windows.” Microsoft is addressing those too, so developers won’t need to turn to third-party libraries to address missing features.

Microsoft is improving the migration experience. Which will be interesting, since there is no way to easily migrate from older frameworks like WPF to Windows App SDK/WinUI today. Among other things, it will make it easier to add bits of WinUI to older frameworks like WinForms while also doing the opposite. Ditto for WPF.

This work is happening now, in public, with transparency. Microsoft has moved into a new phase in its transition to fully open sourcing the Windows App SDK and WinUI, and though it is already publishing the changes it’s made to the GitHub repository so developers can use them in Experimental preview, it will soon work openly with the repository in stable too.

The improvements to Windows App SDK/WinUI will be driven to some degree by how AI has changed the development process. “AI has changed the way I write software,” he says. “I rarely type semicolons anymore. I’m almost always using AI to drive most of the code that I’m writing. I use it for code reviews, for writing tests.”

Microsoft is bringing React-style declarative UI development to WinUI. Today, WinUI apps (like WPF) use the XML-based XAML language to declare what app UIs look like. But newer frameworks, like React, Jetpack Compose, and SwiftUI use a more modern way to write declarative UI code using the same programming languages developers use for logic code (JavaScript, Kotlin, and Swift, respectively). This method is more flexible and responsive than XAML. And it integrates better with the CLI-based coding tools I’ve written about here and elsewhere. And so Microsoft is adding this style of UI development to WinUI: You will be able to write declarative C#-based UI code instead of XAML (and, no, XAML is not going away). It is testing this new system now publicly (a reader tipped me off to this last Friday; I had never heard of it). But this is not just an experiment, it’s happening. A big chunk of this session is Anderson using this style of coding to create and edit demo apps.

In other words, yes, Microsoft is doing with Windows App SDK/WinUI what it’s doing with Windows (and, less related, Xbox). How long this will take–or last, one always questions these things–and how far it goes remain an open question. But just seeing that Chris Anderson is involved here is invigorating and a welcome sign that this work is real and not just fan service.

My central position on native Windows app development is unchanged: Few developers should even consider creating a new app that runs only on Windows, and few would. But this is a far better approach to modernizing existing apps and codebases than the WPF modernization effort that fell of a cliff after a few months of activity two years ago. (It’s notable that the next two .NET releases, .NET 10 and 11, have offered basically no improvements to this work.) And one can make the argument that doing this work so Microsoft’s developers can finally adopt WinUI more broadly is likewise valuable to some degree, similar to the argument that keeping the money-losing Surface PC business around might make sense if only so Microsoft employees can use a laptop with a Microsoft logo on it on-stage during industry events. Eating your own dogfood, as we used to call this, says more to the outside world than just talking about it does.

This is just one of many developer advances announced at Build, and many of these things are evolving in real time and will ship somewhere down the road. I expect to dive into some other related topics soon, given how important this work is to the platform and thus to everyone who uses it, and not just developers. The more you know, the more you know.