And Now I’ve Vibe-Coded a Native Windows 11 App ⭐

The Build 2026 keynote was overly-long, in keeping with tradition. But there was some good news for Windows developers, too, and that’s been unusual in the modern era.

Among that good news was something called Windows Developer Skills, a collection of WinUI agents and AI skills for Windows app development. Depending on where you’re at, that either means something or it doesn’t. And to be fair, I’m still catching up on the ever-evolving language of AI, so it took me a bit to realize the implications here. But the term “skills” indicates that this thing is a way to use AI agents to vibe code a modern Windows app using WinUI.

Interesting timing.

This past April, I completed a years-long coding project called WinUIpad (originally .NETpad) and I was only able to get it over the finish line thanks to AI; in this case Anthropic Claude and Stardock Clairvoyance. And this year has seen the rapid evolution of vibe coding, initially a misunderstood pipe dream, into something that developers and, increasingly, even normal people can use to create custom, personal apps of their own. Two weeks ago, Google announced a major update to AI Studio that lets you create native Android apps using this web-based IDE. I went on to use this tool to create a web-based Markdown app, an Android Markdown app, and then, yes, more Markdown apps of various kinds using AI Studio, Android Studio, and Anthropic Claude.

What can I say, these things excite me. But where Google made its AI Studio announcement alongside approximately 1700 other announcements at Google I/O 2026, the latest installment of its annual developer show, Microsoft announced Windows Development Skills alongside approximately 1700 other announcements at Build 2026, the latest installment of its annual developer show. And as with the Google announcement, I quickly went from curious to distracted and then to needing to try it out, and as quickly as possible.

But first, let me explain what’s happening with Windows Development Skills and, more broadly, with all the vibe coding improvements we’re seeing this year.

2026 is the year of CLIs

Command line interfaces, or CLIs, are making an incredible comeback this year thanks to AI and the ease with each autonomous AI agents can interact with them. To be clear, this isn’t about winding back the clock, as humans will continue to interact with apps and services using GUIs and, increasingly, natural language. It’s part of a broader push industry-wide to get us from the way things are to the way things will be.

Transitions take time. Computer use functionality in AI chatbots is like screen scraping, a low-tech approach to get at the functionality in apps or at data wherever it’s stored. But traditional GUIs on your computers, phones, and other devices, including apps, are evolving to meet the needs of this new era too, and that will eventually diminish if not eliminate the need for computer use in AI. This is the world of so-called “semantic apps,” which I sort of think of as programmatic apps, a way for GUI-based apps to expose individual bits of functionality rather than forcing you, or some AI, to run the whole app and navigate through the interface.

Microsoft is doing this in Windows 11 via App Actions, and for a simple example, you can right-click an image file in File Explorer and then choose AI actions from the context menu to see app-based actions like “Erase objects with Photos” and “Blur background with Paint.” And Google has a similar system for Android it calls AppFunctions. Both of these things are bridges, a way for apps to expose functionality that AI can consume. They are to apps what MCP (model context protocol) is to AI interconnectivity. And they’re required because apps have long been these standalone interfaces used by people.

But back to CLIs. Most of the recent CLI activity, whether it’s Google’s Android CLI, the Microsoft Store CLI, or whatever else, is happening because it’s needed by AI. Yes, you can use the Store CLI to install an app from the command line, but it’s really not for you. And some of the newer CLIs, like the Windows App Development (WinApp) CLI that Microsoft announced this past January, are really about connecting AI directly to lower-level interfaces, like developer-oriented application programming interfaces (APIs) in software development kits (SDKs).

This wasn’t obvious to me at first. When Microsoft announced the WinApp CLI in preview, I didn’t quite get it. It was described as targeting two use cases, developers using cross-platform frameworks and developers working outside of Visual Studio. But it has since improved to support .NET projects for WinUI, WPF, WinForms, and .NET console apps. And now, the WinApp CLI is generally available. And we can see what it’s really for. It’s for AI, and more specifically for AI agents.

It’s also extensible via plugins that provide AI agents with direct access to specific capabilities, including those found in SDKs and APIs. Yesterday, Microsoft announced one such plugin, called Windows Development Skills, with Microsoft vice president Pavan Davuluri describing it as something that “gives agents structured knowledge to build great native Windows apps end-to-end using WinUI3 skills and WinApp CLI.”

Now in early preview, the Windows Development Skills is thus a WinApp CLI plugin specifically designed for CLI-capable, agent-based AI pair coding solutions like GitHub Copilot, Anthropic Claude Code, and OpenAI Codex. It does all kinds of things, among them using the WinApp CLI to install, run, sign, package, and automate the creation of Windows App SDK/WinUI 3 apps. During this process, the WinApp CLI outputs debugging information, which can be read by these agents and then acted on. This is much more seamless than (I know) traditional AI pair coding solutions, which either work inside an IDE (like GitHub Copilot in Visual Studio) or outside an IDE, in which case you need to tell the AI what’s wrong during debugging.

It’s not just that. Whichever AI agent/pair programmer you choose, it will use WinApp CLI to verify that the APIs in the Windows App SDK, Windows SDK, Windows AI SDK, and other APIs it wants to use are, in fact, correct and will work before it even writes any code. Traditional AI pair coding solutions will often confuse APIs–using something, say, from WPF when you mean to use the Windows App SDK, leading to tedious loops of troubleshooting and trying to fix problems the AI introduced into the code base.

In any event, the skills in the Windows Development Skills plug-in understand XAML, Fluent Design, MVVM architectural patterns, and lots more to, in Microsoft’s words, “stay in the WinUI 3 lane end-to-end.” That is, they ground the AI in the correct documentation and other information so that it can solve problems accurately and not just guess based on whatever web-based information, some relevant, some not, that it would otherwise engage with. Given my earlier experiences trying to use GitHub Copilot and Anthropic Claude to help me fix issues with .NETpad/WinUIpad, I instantly understood how important this grounding is.

And that, folks, is why these CLIs exist. It’s for agentic AI pair programming coding solutions.

But how well does it work?

Setting up

Getting started with Windows Development Skill is not for the faint-hearted and this is not a mainstream user solution by any mean. It’s also, as noted, in early preview, so there will be rough edges.

But I made the case in Switcher 2026: The Zen of Linux ⭐ that understanding command line interfaces, or CLIs, is important for anyone who uses a computer, a baseline skill we all need. This is true no matter which platforms you use, be they Linux, Windows, Mac, or ChromeOS. It’s important whether you’re technically inclined or not. But it’s especially important for developers, and even more so in this agentic AI era if you intend to keep up-to-date.

Most mainstream users don’t really think about this. You can access Claude, ChatGPT, and other AI chatbots from the web or you can install apps on desktop and mobile. Less obviously, each also includes a CLI you can install separately. And you will need to install one of these, plus other CLIs, if you want to use the Windows Development Skills. No part of this process can be completed with a GUI. It’s all CLI-based.

Microsoft has instructions for doing this on the GitHub page for the Windows Development Skills, and there are a few different methods, and different instructions for the three AIs it now supports. I’m still paying for Anthropic Claude dating back to that WinUIpad work, so I configured and used it with that. Here’s what I did.

The first step was to figure out whether I had the Anthropic CLI, Claude Code, installed on the PC I used for this. I did have the Claude app for Windows 11 on Arm installed, but when I opened Terminal and tried the claude command, I got an error. So it was time to get that going. With …

winget install –silent Anthropic.ClaudeCode

Then, I restarted Terminal and gave it a shot to make sure it was working.

Using Microsoft’s instructions, then I added Windows Development Skills to the Claude Marketplace.

claude plugin marketplace add microsoft/win-dev-skills

And then installed the plugin.

claude plugin install winui@win-dev-skills

And that’s it. Now it was time to create an app.

The Windows Development Skills vibe-coding experience

When Microsoft first announced what became Copilot in February 2003, Yusuf Mehdi discussed how he was going to Mexico City soon for a wedding and he asked the AI to create a five-day itinerary for the trip. For the next two years or so, I repeated this test on every AI, and every AI update, that I came across because I know the city so well and could gauge how well it was doing and how they all improved over time. Which they did.

For this first experiment with CLI-based vibe coding, I decided to start with something equally familiar. I’ve spent years building various versions of my Notepad clones, .NETpad and WinUIpad, the latter of which is based on the Windows App SDK and WinUI 3, the same technologies that the Windows Development Skill uses. So it made sense to stick with something I know well.

First, you have to ground Claude Code with:

claude /winui-setup

Then, I just typed the simplest prompt imaginable, purposefully not giving it too much to go on.

build me a WinUI 3 app that is identical to Notepad in Windows 11 visually and functionally

Because this was the first time I tried this, I had to install some prerequisites. I already had the .NET 8.0 SDK installed, but Claude Code told me that it would need to install the WinApp CLI and some WinUI templates, and enable Developer Mode (which tells me I never built and ran a Windows App SDK app on this PC yet, as you have to do that the first time).

I gave it my permission to install and enable those things, and after a lot of back and forth, it completed those tasks and I was ready to go. And we were off to the races. Claude Code requested my permission more times than I can count, and I approved them one by one for about 20 minutes before finally giving in and tapping 2 to just allow all edits during the session.

The entire process took over 45 minutes. During this time, Claude Code performed a now-familiar routine in which it appeared to be talking to itself, reasoning out why something didn’t work, trying other things until whatever it was started working, and then repeated the process many, many times. I could see C# and XAML code fly by, disappear, and fly by some more. It created and edited files, made an MVVM structure and views and view models, and, at some point, it finally tried building the app it was making. This failed until it didn’t, and then, magically, at the 48 minute mark, an app appeared on-screen.

It’s … not bad. The Notepad11 app, as Claude named it, supports multiple documents and tabs. It has pretty much all the expected menu items, minus anything related to printing (which the post-creation report explained is not an available API for the Windows App SDK). There’s no settings page, and font selection is via a small dialog and not persistent between app runs.

And I am fascinated that Find/Replace is implemented as panes that appear above the text box, which is precisely the design I created back when I was working with WPF because that framework doesn’t support the native content dialogs that would be preferable; an early vibe coding experiment had created the same UI. This has to have been stolen, or inspired, by my own code in GitHub. Has to.

The app isn’t particularly polished. And I can see why it switches the locations of menus and the tabs (compared to how Notepad works) because doing this correctly is very difficult and something I worked to fix in my own app for months (before succumbing to Claude/Clairvoyance and watching it just use my solution). But it does work. And I could certainly continue “editing” it by interacting with Claude Code and the Windows Development Skills, though I don’t see the point: I already made a more polished and feature complete version of this app, after all.

That said, I am curious whether this app has any useful code I might appropriate because it’s more efficient or elegant, or perhaps solves some problem I did not. So I opened the project associated with the code in Visual Studio and took a look. It compiles and runs fine in both x64 and Arm forms (I did this on a Windows 11 on Arm PC), and it appears to be structured normally.

It will take some time to go through all of this. But what I’ve seen so far makes sense. There’s no native status bar control in the Windows App SDK, so it used a basic grid, just like I did. I create two converters to accommodate data binding, just like I did. It uses MVVM with separate views and view models in their own sub-folders, which I did not do, but it’s straightforward enough. I think the only thing that’s stood out so far is that the code it generated is often more concise but less readable than what I might have written as a non-professional developer. Nothing major.

Given how long this took, I was curious if I had blown through some usage limits and perhaps triggered an additional charge from Anthropic. But looking at Settings > Usage in the Claude app this morning, it says that I’ve only used 1 percent of my weekly limit and that I’ve not used an usage credits. This I cannot explain.

Given my previous experiments vibe-coding Markdown editors for the web and Android, I may do something similar with the Windows Development Skills and see how that goes. Either way, this capability is getting interesting, and I would love to see a general purpose vibe-coding solution that can make truly cross-platform apps, perhaps with Flutter or even React Native. Creating a single app that works everywhere is appealing. But even as-is, it’s impressive, and a step to a future in which apps and not at all like they are today.