Last month, we announced the general availability of the GitHub Copilot app, a desktop application for agent-driven development. The Copilot app is a game changer for productivity, integrating natively with GitHub, so your repositories, branches, and CI pipelines work out of the box. It’s designed for workflows where you direct several agents in parallel, each in its own isolated workspace, rather than doing all of the work yourself.

On July 16, join us virtually at “Let’s Learn GitHub Copilot App” to upskill on this new tool – no experience required! If you’ve been curious about the GitHub Copilot app, or you’ve heard the buzz and wondered how this tool can actually help you work smarter, this free virtual training is your perfect starting point.

What This Event Is

Let’s Learn GitHub Copilot App is a live, instructor-led virtual training that walks you through the GitHub Copilot app experience. This session blends explanation, demonstration, and guided practice so you can follow along and learn by doing. You’ll learn how the GitHub Copilot app works, how it can help you manage your projects, and how to apply it in a hands-on workshop.

Schedule: Register in Your Language

The event will run in multiple languages and time zones. Register using the links below:

Who This Event Is For

Whether you’re a developer, a technical professional, or simply someone who wants to boost productivity with AI, this event will give you the clarity, confidence, and practical skills you need.

This training is designed for:

• Developers of all levels — from students to senior engineers
• IT pros and technical teams exploring AI-powered tooling
• Anyone curious about AI assistance and how the GitHub Copilot app can help them work faster and better

No prior GitHub Copilot app experience is required.

What You’ll Learn

During this session, you’ll get a clear, practical understanding of:

• What the GitHub Copilot app is and how it works
• How to install and set up the GitHub Copilot app
• How the GitHub Copilot app assists with coding and manages the code review process
• How to get the most out of the GitHub Copilot app by setting up custom instructions and adding MCPs
• Automating the pull request merge process with Agent Merge
• Using Canvases to track your work

What You Need Before You Join

To get the most out of the training, make sure you have:

• A GitHub account
• A stable internet connection
• A laptop or desktop where you can follow along

You can get a head start by downloading the GitHub Copilot app. We will also walk through the installation process during the event.

Register, we’ll see you there!

This free training is your chance to learn directly from experts, ask questions, and get hands-on experience in a friendly, supportive environment.

The post Let’s Learn GitHub Copilot App – Free Virtual Training Event appeared first on Microsoft for Developers.

Explore the .NET 11 updates available now in .NET MAUI, including map enhancements, long press recognition, animation improvements and more.

Oh yeahhh!! .NET 11 for .NET MAUI is here!

And, as always, my recommendation is to stay up to date with every new release. What changed? What’s new? What has been improved? Keeping up with these updates helps us build better apps and keeps our code inline with the latest recommendations from the Microsoft team.

For .NET 11, the team’s main focus has been improving the overall quality of .NET MAUI, making it faster and easier for us as developers, to build amazing applications. In this article, you’ll discover some of my favorite improvements that Microsoft has introduced for .NET MAUI in .NET 11!

1. Maps Improvements

This is one of my favorite updates in .NET 11! Let’s start by exploring the Map control, which has received some really nice improvements. Here are some of the highlights!

Pin Clustering

For educational purposes, this image was generated with AI

Imagine you’re building a restaurant app where users can view nearby restaurants on a map. You may have 300, 400 or even more locations to display. If the user opens the map while zoomed out, it could look something like this:

This quickly becomes overwhelming because many pins overlap, making it difficult to select a specific location.

With .NET 11, you can simply use this property:

IsClusteringEnabled="True"

And with that, .NET MAUI will automatically group nearby pins into clusters. So instead of displaying multiple overlapping pins like , users will see something like (5), indicating that five locations are grouped together.

As users zoom in, those clusters gradually split into individual pins, creating a much cleaner experience and making it much easier to interact with the map.

Using it in .NET MAUI is incredibly simple:

<maps:Map IsClusteringEnabled="True"

    ClusterClicked="OnClusterClicked" />

Custom Location Markers

For educational purposes, this image was generated with AI

Yay!! Another great addition is the ability to customize your map markers.

Instead of using the default pin for every location, you can now display a custom image for each marker, making your maps much more intuitive and visually appealing.

For example, imagine you’re building a healthcare app. You could use one icon for hospitals and a different one for pharmacies, allowing users to quickly identify each type of location without even reading the labels.

This is possible by simply setting the ImageSource property on the pin.

Here’s what it looks like in code:

var pin = new Pin
{ 
    Label = "Custom pin", 
    Location = new Location(18.4861, -69.9312), 
    ImageSource = ImageSource.FromFile("hospitals.png") 
};

JSON Map Style (Android)

Google Maps allows you to customize the map using a JSON file. This means you can change colors, switch between light and dark mode, customize labels and much more.

Previously, this was much more complicated in .NET MAUI. Now, all you have to do is assign your JSON file to the MapStyle property, and you’re done!

2. Cancel Animations with CancellationToken

This improvement may seem small, but it’s actually a very useful one, especially when you have multiple animations running at the same time.

Before .NET 11, if you started an animation and later wanted to stop it, your only option was to do something like this:

image.CancelAnimations();

However, there was a small problem. This method canceled every animation running on that control.

Imagine your image is running two animations simultaneously: a rotation animation and a fade animation. If you only wanted to stop the rotation while keeping the fade animation running, that simply wasn’t possible.

Starting with .NET 11, the animation methods now optionally accept a CancellationToken. This means you can cancel a specific animation without affecting the others.

For example:

var cts = new CancellationTokenSource();

await image.FadeToAsync( 
opacity: 0, 
cancellationToken: cts.Token);

And when you want to stop that animation:

cts.Cancel();

That’s it! Only the animation associated with that CancellationToken will be canceled, while any other animations on the same control will continue running normally.

Methods Without Async Are Now Obsolete

Another important change is that animation methods without the Async suffix have now been marked as obsolete. Methods such as FadeTo(), RotateTo() and ScaleTo() are now marked as [Obsolete]. Instead, Microsoft recommends using their asynchronous counterparts:

• await FadeToAsync(…);
• await RotateToAsync(…);
• await ScaleToAsync(…);

Of course, these methods also support the new CancellationToken, giving you much greater control over your animations.

3. LongPressGestureRecognizer

Have you noticed that some actions in mobile apps are only triggered when you press and hold a control for some seconds? Thanks to .NET 11, .NET MAUI now includes the LongPressGestureRecognizer, making it easy to detect this gesture.

It provides several useful features:

• Detects long-press gestures
• Configurable press duration
• Movement threshold to cancel the gesture if the finger moves too far
• Gesture state tracking through GestureState
• Support for Command and CommandParameter

Using it is as simple as this:

<Image Source="flower.png"> 
<Image.GestureRecognizers> 
<LongPressGestureRecognizer 
    Duration="500" 
    LongPressed="OnLongPressed"/> 
    </Image.GestureRecognizers> 
</Image>

The event:

void OnLongPressed(object sender, LongPressGestureRecognizerEventArgs e) 
{ 
    if (e.State == GestureState.Completed) 
    { 
    // Your code goes here 
    } 
}

4. We Can Finally Use Gradients in BoxView!

BoxView is a super useful control that gives us a lot of flexibility when building UI. However, before .NET 11, it had one important limitation: it could only display a solid color. So, if you wanted a gradient, you had to rely on other controls or custom solutions.

With .NET 11, BoxView now includes the Fill property, which is of type Brush. This means you can finally apply gradients directly to a BoxView! And don’t worry, if you only need a solid color, you can continue using the BackgroundColor property as before.

Here’s a simple example:

<BoxView HeightRequest="260"> 
    <BoxView.Fill> 
    <LinearGradientBrush> 
    ... 
    </LinearGradientBrush> 
    </BoxView.Fill> 
</BoxView>

5. Trimmable CSS

I don’t know if you knew this, but .NET MAUI has supported CSS for quite some time. The problem was that even if your application didn’t use CSS, .NET MAUI still had to include all the infrastructure required to support it, increasing the final size of your app.

With .NET 11, that’s no longer the case. If your application doesn’t use CSS stylesheets, the CSS infrastructure is automatically removed during the publishing process. In short, if you don’t use CSS, your application becomes smaller without you having to do anything.

6. Material 3 on Android

Previously, some .NET MAUI controls on Android were not fully aligned with Material 3. Starting with .NET 11 Preview 4, several Android handlers now use Material 3 by default. This applies to controls such as:

• ImageButton
• DatePicker
• Entry
• Slider

In short, it was common to find controls that didn’t fully follow Android’s modern design guidelines. With .NET 11, that changes. These controls are now much more aligned with Material 3, resulting in a more modern, consistent look that feels fully integrated with the Android ecosystem.

Image obtained from the official documentation

Conclusion

And that’s it! I hope this article helps you discover some of the exciting new features coming to .NET MAUI with .NET 11.

Throughout this article, we explored some of my favorite improvements, including the new LongPressGestureRecognizer, Map enhancements, BoxView gradients, animation improvements and Android Material 3 support.

Of course, these are just a few of my favorites! I encourage you to explore the article “What’s new in .NET MAUI for .NET 11” from the official documentation to discover even more improvements and enhancements included in this release.

I also encourage you to keep experimenting with these new features and continue learning something new every day.

See you in the next article! ‍♀️

I’ve built a machine, that builds machines, that build large pieces of software. One of them ran for 39 days building a preliminary proof-of-concept copy of Word, most features largely there, mostly on its own. It got a lot of things right—though the ruler and margin controls you’d expect at the top of the page were conspicuously absent. More on that later. 

This isn’t “AI helped me code” autocomplete. It’s a bespoke agentic loop I call a “dev machine.” It wakes up, reads a state file, picks the next thing to build, builds it, tests it, commits it, and goes back to sleep. Over those 39 days, my dev machine ran 565 sessions, made 3,706 commits, and produced about 350,000 lines of TypeScript. And the most interesting thing I learned had nothing to do with whether the code worked (it did). The interesting part is what broke—and why. 

Let’s talk about how I got this to work: four failures (which is why the project is called “word4”). 

Four tries to get one loop

The first attempt, which I charmingly named “wordbs” because I thought it was a nonsense idea at the time, was 150,000 lines of trying to build everything at once: an OT engine, canvas rendering, OOXML parsing, mail merge. It drowned in its own complexity before anything usable existed. The second attempt that counts, word3 (there was something in between that actually worked, but aimed at a different target, hence the jump), was the opposite: clean, about 8,000 lines, 486 passing tests, genuinely nice architecture. But it was just a single-user app because I hadn’t “coached” the model and it quietly decided to skip that part. Trying to bolt CRDT-based collaboration onto it afterward broke the working editor. 

Word4 v1 had the right instinct (CRDT first, validation gates, specs up front), and then nobody executed it. There was no orchestrator, no loop: just a folder full of good intentions. 

What actually changed things came from a different project. I was building a terminal UI with a technique that was a proto-dev-machine, and I told it, “If you run out of things to do, just keep adding features that make sense.” Then I went away for the weekend. I’d set this one up, almost by accident, so that a) it was more careful with both design and the task list, b) it had a robust test environment, and c) the main thread acted only as an orchestrator. Those ingredients let it run for 38 hours on its own, spawning 440 sub-agents across 167 commits (RIP my token budget). 

I set out to formalize those ingredients in a system I call “the dev foundry.” This is the machine-that-builds-machines.  

There are three core things a dev machine loop needs (aside from a good enough model). First, it requires the ability to build specs “progressively,” in machine-readable form, so it never really gets lost building something and can design as it goes. Second, it needs a robust event/task stack that keeps context clean. The main loop did nothing but orchestration on that stack, spinning up a fresh sub-agent with fresh context for each new task, and keeping tasks at a scale a single sub-agent could actually finish. Finally, it needs a good test environment, robust, with a target it can understand and write tests against as it designs features. These combine into a “machine” that never gets lost. It just grinds away. The more formal dev machines add one last thing: maintenance tasks in the list, so the machine remembers to do refactoring, run CI/CD pushes, and even take bugs from me on the live site and push fixes (then deploy them) automatically, as long as the loop is running. 

A “dev machine” is a bespoke loop for one specific project. A “dev foundry” is the agent and process that builds dev machines. The foundry creates machines. I like this technique—it’s a good way to build leverage. One way to think about it is that, for a given model, there’s a “radius” of problems it can solve independently. The dev foundry sets it up to break the larger problem into problems of that size (and if you’re lucky, the problem of decomposition is itself a problem of that size, and the model can do almost all of the work). Machines build software. The foundry is skeptical, on purpose: It runs a six-step admissions gate that checks whether the problem you have will actually fit the dev-machine pattern, including repeating back the downstream implications of your stated goals and making you agree with them before it will build anything. 

The dev machine loop

Here is the entire loop: 

That’s it. The spec is the product. The machine is just a loop that executes specs. Every session starts with a clean context and gets its instructions entirely from files on disk, because the alternative (one long session holding everything in its head) doesn’t work. The word4 architecture spec was 947 lines written in about an hour of conversation, and it paid compound interest: 621 commits in the first week, 1,351 by week six. That initial hour was the highest-leverage hour in the whole project. 

(There’s a guardrail I’ve grown to love. Every generated project ships an AGENTS.md that tells any human who opens an AI session in the repo: Do NOT implement directly, run the recipe. Because a well-meaning human editing files by hand bypasses the state machine and causes exactly the drift you built the machine to avoid. The machine has to protect itself from us.) 

The part where it went wrong

Now the good part: After 534 sessions, the machine proudly reported 1,111 features completed. And when I actually looked, a lot of those “features” were the machine mapping obscure OOXML properties one at a time (each one counting as a feature), plus writing tests for code that already worked. Meanwhile, a basic ruler—the margin control at the top of every word processor you’ve ever used—had been sitting in the candidate list for 22 straight sessions and had never once been picked. Zero lines of ruler code existed after 25 days. 

Why? Because the OOXML property work was deterministic. It was always available, it always passed review, and it always incremented the counter. The ruler was ambiguous and hard and might fail. So the machine, handed a choice between “reliably produce a green checkmark” and “do the valuable but risky thing” chose the checkmark every single time. The test-to-source ratio drifted to 4:1 against a 2:1 target. Staging deploys sat “overdue” for a hundred sessions and never escalated.

This is priority inversion, and it is not a bug in the model. The machine did exactly what I asked: It faithfully wrote down every problem in its state file, including the ones it was busy creating. It just had no judgment about which work was worth doing. It optimized the metric it could see. That’s the real finding, and it’s why “unsupervised” is the wrong word for any of this: The machine is honest, but it isn’t strategic. Strategy is still my job, and if I don’t show up to do it, I get 1,111 features and no ruler. 

Scar tissue

A few things I’d tell you if you tried this yourself. Robustness is not incremental. You can’t arrive at it gradually. Every new machine I’ve generated fails its first overnight run, always in the gap between the template and the specific reality of the project. Word4’s first night died in a 514-attempt retry loop, because Cloudflare’s bot detection started challenging the Anthropic API during a long unattended run (I fixed it partly by putting the container on network_mode: host, so the bridge NAT stopped looking like a bot). I now run a three-layer recovery stack: an entrypoint retry loop, a host watchdog, and a host monitor, each catching failures the others miss. That is not elegance. That is scar tissue. 

And once you have more than one machine, they start to entangle. I’ve generated machines for word4 and a few other projects now, and the shared operational patterns kept getting tangled up with the per-project customization, so I borrowed the Docker base-image model: a foundry-owned base layer, a machine-owned project layer, and one script to push improvements across the whole fleet at once. 

If you want to build your own dev machine 

The good news is you don’t have to start from my scar tissue. All of this is open source and built on Amplifier, the agent framework underneath everything I’ve described. Amplifier is the substrate—the modules, agents, recipes, and orchestration primitives: github.com/microsoft/amplifier. The foundry itself—the admissions gate, the STATE.yaml loop, the AGENTS.md guardrail, the progressive specs, the recovery stack—ships as an Amplifier bundle: github.com/ramparte/amplifier-bundle-dev-machine. Clone that and you have the loop this whole piece is about. 

Two things I’d tell you before you run one overnight. The highest-leverage hour is still the spec, not the code—spend it on the architecture doc and a test target the machine can check itself against, because that’s what the loop compounds on. And budget for the machine having no judgment: It will honestly, tirelessly hand you 1,111 features and no ruler unless you show up to say which one matters. The tooling gives you the loop. The strategy is still yours—and I think it’s going to stay that way for a while. 

The post How my dev machine built 1,111 word-processing features and forgot to add a ruler  appeared first on Command Line.

I’m the technical leader and founder of the “Critter Stack” tools (Marten, Polecat, Wolverine, and Weasel) and the greater JasperFx organization on GitHub. After 15+ years of OSS community work of varying degrees of technical and project adoption success, I’ve got a few things to share that I think have helped us be more successful. Just know though, that there was plenty of iteration, friction, pain, and flat out failures in the rear view mirror before we arrived at most of the things I’m sharing as “positives” here — and of course, plenty of people would argue with me that at various times we’ve done things badly for them.

First for some soft, non technical things. If you can possibly get to this, having a community invested in the success of your tools and the community succeeding as well is immeasurably valuable. I think we’ve actually got that for the Critter Stack and it shows from the sheer number of contributions we’ve gotten in the past couple years. I won’t lie and say I know how to create that from scratch. The only concrete things I can recommend is to try to be as responsive as possible as a maintainer and at least acknowledge user requests or issues as they come in. We pride ourselves on being responsive and not letting issues linger, and we also try to aggressively improve our tools based on user feedback. I think this has quite clearly improved once I was able to work full time on the Critter Stack from the founding of JasperFx Software. The rise of AI tools has also made it much easier to stay on top of incoming issues and turn around fixes quickly.

Living Documentation

Just know that we’ve had hundreds of complaints over the years about the documentation, but much, much less over time as we’ve adapted and improved. Or maybe just because many people are only using our LLM friendly version of the docs through an AI agent. I’m still taking credit for the apparent reduction in complaints though!

You do not have an OSS project of much value unless you have a documentation website of some sort that helps people know what your project is and how to effectively use your published tools. As a maintainer, it’s also your first line of defense against people needing more of your time than you can afford to give.

First off, make your documentation be user centric. Try to organize the flow of content in terms of what users are needing to do and their use cases. Try to avoid the temptation to organization your documentation around the technical concepts or APIs in your system because that’s an awfully fast way to create an unusable website. One thing that I think has helped us more recently is investing in something like Martin Fowler’s “Duplex Book” idea from years ago where you have top level, prose style tutorials that link to pages with more specific information on various capabilities. Having tutorials that talk about use cases or sample applications that again link to separate pages with API details are also very helpful, if more time consuming for us the maintainers. And you’re likely to do that wrong anyway, so see my later comments about continuous improvement and adaptation in your documentation.

Just use Markdown for all your content now. GitHub and I assume other shells happily render it for you from web browsing anyway, many developers already know how to use it, tools like Vitepress already expect it for static website creation, and anyway, you pretty well have to know Markdown now for AI prompts anyway. I’m explicitly stating this because I remember trying to write documentation websites in straight up HTML or earlier competitors to Markdown that don’t seem to be common any more.

Colocate your documentation with your code. As a default, try to put your documentation content in the same code repository as the code it’s documenting. Again, not everybody does that, but I’ve found that to be hugely valuable compared to older approaches. If you’re using markdown, GitHub by itself helps render the raw doc content in a reasonably usable way.

Invest in some kind of quick automation to update your documentation website. Babu has us fully automated to build and publish our documentation websites built with Vitepress to Netlify via GitHub actions so we’ve got quick a 1-2 click process to update docs. Unsurprisingly, it turns out that if you make it mechanically cheap to republish your documentation, you’re much more likely to make improvements much more frequently.

Try to be responsive to what your users are being tripped up by and continuously evolve and improve your documentation structure, wording, samples, and explanations based off feedback from your users. And do a better job of staying on top of that than I do sometimes!

From bitter experience, it’s very easy for code samples in technical documentation to drift away from the tool’s public API, especially with a long lived project. To that end, I very strongly recommend using some kind of tool like MarkdownSnippets that can extract code samples from code that you know is compiling and runnable. That enables us to decorate sample code snippets from within either test projects or sample applications in the main .NET solution like this:

And have that code inserted live into our Markdown documentation files and on our documentation site. You can see that code snippet above in action here.

Make it as easy as possible for external contributors to suggest or make improvements to the documentation. Having Markdown files directly in your GitHub repository with enough README explanation to know how to edit those files certainly helps. We embed a footer on all of our pages like this with a direct link to fork and create a pull request for the current page:

And every little pull request improving wording or (sorry) grammatical or spelling errors adds up over time. One defensive thing I started doing that turned out to be very helpful over time is to try to defang people up in arms about your documentation by asking them how they would suggest improving the documentation for whatever it was that wasn’t working for them. Some people just want to blow off steam at you, but often enough that’s led to a new contributor pitching in and contributing improvements to our documentation.

When someone complains about your documentation, ask them what they think should change or what would have helped them find the information they needed or how something should be explained differently. Some people just want to gripe, but I’ve found that just asking for feedback or even asking for pull requests to improve the documentation has actually led to quite a few improvements for us. And sometimes it even gets someone to stop yelling at you online, which is frequently my main goal as an OSS maintainer:)

Actually, let me generalize that to say that simply asking someone complaining about your tools what they think we should do instead has been very helpful to either eliminate some friction with the tools or at least defuse the situation.

One last, very important note about your technical documentation. Try very hard to clearly describe how you think your tools are meant to be used and what the intended idioms are for your OSS tools. At this point, I think most of the problems we deal with from users are coming from folks who try to use the tool non-idiomatically (or are just hitting permutations or scenarios we didn’t anticipate of course). You can theoretically head off some of those issues by describing and providing samples of “this is how you should use our tool.” That advice might be more germane to an application framework than a library that has much more limited usage patterns though.

For the record, we have frequently been told that we have much better documentation than most of our competitors. I will tell people that I think that Marten is the most capable event sourcing tool for .NET developers — but at one point the one tool I think might be in the running with us in capability has never invested enough in their documentation to prove it.

Ruthlessly Eliminate Friction in your Getting Started Story

My good friend, fellow OSS maintainer, and even a groomsman for me Dru Sellers once gut punched me by comparing an older project of mine to Bowser in Super Mario Kart — slow to get going, but really fast once he gets there!

Ouch.

Every since then I’ve put a lot of focus on making any OSS tool I’m a part of as easy to start with as possible. Let’s take Marten as an example. Here’s the absolute easiest way to add Marten to a .NET system that’s ready to roll (assuming that you have a PostgreSQL database, which is conveniently enough very cheap to spin up in a Docker container):

// This is the absolute, simplest way to integrate Marten into your
// .NET application with Marten's default configuration
builder.Services.AddMarten(options =>
{
    // Establish the connection string to your Marten database
    options.Connection(builder.Configuration.GetConnectionString("Marten")!);
    // If you want the Marten controlled PostgreSQL objects
    // in a different schema other than "public"
    options.DatabaseSchemaName = "other";
    // There are of course, plenty of other options...
});

With that minimal bit of documentation, you can literally start persisting and saving documents (entities) with Marten’s services. Let’s say you’ve got this little class you want to be persisted:

public class User
{
    public Guid Id { get; set; }
    public required string FirstName { get; set; }
    public required string LastName { get; set; }
    public bool Internal { get; set; }
}

And now, here’s a working Minimal API endpoint that happily persists a new User on the very first usage with our setup from up above with no explicit configuration, no database schema migrations, or scripts, or anything but a working connection to a database:

app.MapPost("/user",
    async (CreateUserRequest create,
    // Inject a session for querying, loading, and updating documents
    [FromServices] IDocumentSession session) =>
{
    var user = new User {
        FirstName = create.FirstName,
        LastName = create.LastName,
        Internal = create.Internal
    };
    session.Store(user);
    // Commit all outstanding changes in one
    // database transaction
    await session.SaveChangesAsync();
});

So, a couple things and then I’ll talk about the concepts underneath the code above:

• We’ve tried to adopt an attitude of “it should just work” toward our tools. As a prime example of that, Marten in its default mode will happily make sure that the database schema is exactly what the Marten configuration needs it to be at runtime for you. That leads to a much faster getting started story than it is without that. Likewise, Wolverine can configure message brokers for you for the same experience with Rabbit MQ or Azure Service Bus. Please chill out a little bit if you’re thinking that you’ve personally had trouble with Marten and Wolverine because I specifically said the word “try.”
• I’m going to claim that we judiciously use some Sensible Defaults. Look up above at the User type and notice that it has a property called “Id.” Without any explicit configuration, Marten will happily decide that’s the identity for the User type. That also tells Marten to use sequential Guid values for assigning identity if one isn’t assigned by the user
• Marten and Polecat both support a pretty efficient “upsert” for documents that’s yet another way to remove friction and repetitive code. We’ve had that so long I’d really kind of forgotten about that, but I always miss that when I’m forced to use EF Core instead:)
• A little bit of “Convention over Configuration”, but that one works really well for some folks, and not so much for others, so you can’t take that as a globally applicable strategy

My kids love Jack Black after he was Bowser in the Super Mario Brothers movies and the Minecraft movie.

Technical Things

Just a potpourri of things that I think have contributed to whatever success we’ve had as an OSS community:

Semantic Model. Wolverine, Marten, and Polecat all use the Semantic Model approach to framework configuration. This allows us to accommodate a mix of conventions and explicit configuration while providing much more diagnostic information about our tools than anything else out there in .NET land. This strategy is also key to Wolverine’s composable middleware strategy that allows you to control the application and ordering of middleware on a handler by handler basis. I wrote much more about this recently in Wolverine Middleware and Some Random Observations, but see the section on “Wolverine’s Configuration vs Runtime Model”

Compliance Tests. Wolverine has a library of reusable “compliance” test suites for our message durability (think transactional outbox et al), messaging “transports”, and leadership election that try to cover every basic scenario you need to say that an integration to a new technology works correctly with Wolverine. Once we refactored those test suites out and made them reusable, that opened the door to add a lot more capabilities to Wolverine. At this point, Wolverine actually supports more message broker technologies than our much older competitors, and I attribute plenty of that to the compliance tests. Moreover, several of our supported options (GCP Pubsub, Redis, NATS.io) came from community contributors rather than core team members. Likewise, the compliance tests for message persistence enabled us to expand from our earlier PostgreSQL / SQL Server duality to Oracle, MySql, Sqlite, RavenDb, and CosmosDb now.

Orthogonal Code. All this means is that the internal code is relatively well factored and types have well defined responsibilities such that they can be composed in new ways. That’s a lot of gobbledygook, but the very real impact is that Wolverine’s internals allow us to support every possible type of message error handling strategy for every possible messaging technology that Wolverine supports without duplicating much code. As an example, one of our older competitors just added the ability to do delayed message retries when using Kafka. Because of the way Wolverine’s internals are structure, we support that capability for every single transport option and not just Rabbit MQ (but liek every other messaging tool, the Rabbit MQ integration is much more heavily used than everything else). As another example, Wolverine can mix and match its transactional inbox and outbox support for every supported database and every supported messaging transport.

Diagnostics. If you try to build out any kind of application framework like Wolverine or configuration intensive libraries like Marten or Polecat, you better damn well have diagnostics left and right to explain what, how, and why the tools are doing what they’re doing. CritterWatch is well underway, but even without that, we build in command line diagnostics pretty early and we’ve continued that investment. That turned out to be very advantageous for AI usage, but even before that, that helped us quite a bit in user support as is.

Standardizing Test Automation. In Marten we’ve built a couple shared test harness recipes over the years that help (especially me) contributors and yes, AI agents, fall into consistent and optimized patterns for automated tests. Here’s an example of using our OneOffConfigurationContext recipe for testing any kind of non-default Marten configuration:

public class event_statistics : OneOffConfigurationsContext
{
    [Fact]
    public async Task fetch_from_empty_store()
    {
        await theStore.Advanced.Clean.DeleteAllEventDataAsync();
        var statistics = await theStore.Advanced.FetchEventStoreStatistics();
        statistics.EventCount.ShouldBe(0);
        statistics.StreamCount.ShouldBe(0);
        statistics.EventSequenceNumber.ShouldBe(1);
    }
    [Fact]
    public async Task fetch_from_non_empty_event_store()
    {
        await theStore.Advanced.Clean.DeleteAllEventDataAsync();
        theSession.Events.Append(Guid.NewGuid(), new AEvent(), new BEvent(), new CEvent(), new DEvent());
        theSession.Events.Append(Guid.NewGuid(), new AEvent(), new CEvent(), new DEvent());
        theSession.Events.Append(Guid.NewGuid(), new AEvent(), new BEvent(), new CEvent(), new DEvent());
        theSession.Events.Append(Guid.NewGuid(), new BEvent(), new CEvent(), new DEvent());
        theSession.Events.Append(Guid.NewGuid(), new AEvent(), new BEvent(), new CEvent(), new DEvent());
        await theSession.SaveChangesAsync();
        var statistics = await theStore.Advanced.FetchEventStoreStatistics();
        statistics.EventCount.ShouldBe(18);
        statistics.StreamCount.ShouldBe(5);
        statistics.EventSequenceNumber.ShouldBe(18);
    }
}

This base type recipe helps in a couple ways:

1. It enforces some standardization that makes tests easier to read once you’re experienced with the codebase
2. Notice the usage of theStore and theSession? The test fixture base class is lazily giving you access to a document store and a document session based on your configuration in a declarative way. I think this helps make tests be more terse and declarative since there’s less junk code for setting up scenarios.
3. It handles resource clean up for you
4. It’s quietly helping keep the test harnesses isolated from each other and “parallelizable” by using database schema names based on the actual class type name

Ask for reproduction code for bug reports. This obviously won’t help for every project, but at least for the Critter Stack tools we’ve been hugely successful at simply asking users reporting problems to either build a reproduction project on GitHub that demonstrates the problem or better yet, asking them to submit a pull request with failing tests. Not every issue requires that, but man, that’s been so helpful to myself and other maintainers in addressing issues fast. For whatever reason, our community is just absolutely fantastic about doing that for us.

AI can generate UI quickly, but fast output isn’t always usable output. Developers often still need to correct component choices, fix API usage, complete configuration, refine styling, and align the generated code with project standards before it becomes usable in an enterprise application.

In this webinar, Syncfusion® Software Engineer Prabhavathi Kannan demonstrated how the Syncfusion Agentic UI Builder helps developers move from a natural-language prompt to a complete, responsive, and interactive React dashboard built with real Syncfusion components.

If you missed the webinar or would like to revisit the session, the recording has been uploaded to our YouTube channel and embedded below.

At a glance

This session explored how the Syncfusion Agentic UI Builder makes AI-assisted UI development more practical for enterprise applications. Instead of producing isolated snippets, the Builder uses embedded Syncfusion Agent Skills and an eight-stage workflow to create structured, responsive, and maintainable UI inside a real project environment.

The demo focused on creating a modern React admin dashboard that combined sidebar navigation, a top bar, summary cards, a task-completion trend chart, recent activities, and an interactive projects grid.

The challenge

AI-generated UI can be fast, but enterprise applications require more than quick code generation. The UI must be structured, responsive, accessible, maintainable, and aligned with the application’s architecture and design standards.

Common challenges include:

• Incorrect component or API usage.
• Partial UI instead of a complete screen.
• Missing modules or incomplete configuration.
• Inconsistent layout, spacing, or styling.
• Code that does not follow project architecture or standards.
• Extra cleanup that reduces the time saved by AI generation.

A smarter approach with agentic AI workflows

An agentic workflow helps AI move through UI generation step by step instead of jumping directly from prompt to code. It can analyze the request, understand the project structure, map requirements to suitable components, generate code, validate the output, and insert the final UI into the project.

This approach helps reduce trial and error, minimize cleanup, improve consistency, and create a smoother path from prompt to usable interface.

Introducing the Syncfusion Agentic UI Builder

The Syncfusion Agentic UI Builder helps developers create structured enterprise UI using real Syncfusion components instead of generic code. It is designed to support responsive layouts, maintainable architecture, and enterprise-grade UI standards, making the generated UI easier to review, refine, and integrate into real applications.

The Agentic UI Builder is available across multiple platforms, including React, Angular, Blazor, .NET MAUI, WinForms, WPF, and more. In this webinar, the demo focused on the React experience using the Syncfusion React UI Builder.

How Syncfusion Agent Skills power the builder

The latest Syncfusion Agentic UI Builder is powered by embedded Syncfusion Agent Skills. These skills provide Syncfusion-aware implementation guidance inside the project environment.

When a prompt requires grids, charts, navigation, inputs, lists, or other UI elements, the Builder can use relevant component guidance rather than relying solely on generic AI knowledge. This helps it select, configure, and compose Syncfusion components using supported patterns.

Prerequisites

To follow along with the demo, you need:

• APM (Agent Package Manager).
• Node.js version 18 or later.
• A React application (existing or new).
• A supported AI agent or IDE (VS Code, Cursor, Syncfusion Code Studio, etc.).
• An active Syncfusion license.

Demo: Building a React admin dashboard

The demo started by installing the React UI Builder skill into the development workflow.

apm install syncfusion/react-ui-builder -t copilot

The session moved into a practical project management scenario-creating a modern admin dashboard to track projects, active tasks, team updates, and overall progress in one place.

Prompt used in the demo:

Create a modern admin dashboard UI similar to a clean SaaS product. Keep the design simple, professional, and easy to use.

Use a sidebar layout with navigation on the left and the main content on the right. Add a top bar with a page title, search input, notification icon, and user profile.

Include a dashboard page with:
- A few summary cards (projects, tasks, team members, and Rrevenue).
- A chart showing tTask Ccompletion tTrends.
- A list section of recent activities.
- A data grid listing projects with status and progress.

Make sure everything looks clean and well-spaced, with soft shadows and rounded corners.

Ensure the layout works across desktop, tablet, and mobile (the sidebar can collapse or be hidden on smaller screens).

Use realistic sample data and keep the UI minimal and polished.

After the prompt was entered, the Builder processed the request through its eight-stage workflow:

1. Intent analysis
2. Project detection
3. Component mapping
4. Theming and design system
5. Code generation
6. Dependency management
7. Validation
8. Code insertion

This workflow helped turn the original prompt into a working dashboard rather than a disconnected code snippet.

Final output

The generated dashboard included the following UI sections and Syncfusion components:

The final output was also responsive across desktop, tablet, and mobile views. Overall, the implementation showed that the generated UI was not just a static mockup, but a functional interface that developers could review, refine, and extend.

Best practices

To get better results from the Builder:

• Start with a clear prompt.
• Add design preferences.
• Check the setup and installation target.
• Review the generated output.
• Extend and refine as needed.

Timestamps

[00:00] Welcome and session introduction

[00:44] Webinar agenda and overview

[01:15] Common challenges with AI-generated UI

[02:19] Poll: Biggest AI-generated UI challenge

[02:55] What developers need from AI-assisted UI generation

[04:00] Introducing the Syncfusion Agentic UI Builder

[04:54] How agent skills power the UI Builder

[05:39] Prerequisites and project setup

[06:10] Poll: Most time-consuming UI development task

[06:46] Demo setup in Syncfusion Code Studio

[07:48] Installing the UI Builder skill

[10:18] Exploring the installed agent skills

[11:46] Preparing the AI prompt

[12:21] Defining the enterprise dashboard scenario

[13:32] Behind the scenes: The 8-stage workflow

[14:38] Confirming design decisions before generation

[15:03] AI-powered code generation begins

[17:27] Validation and project updates

[18:25] Previewing the generated dashboard

[19:37] Reviewing the generated project structure

[20:07] Exploring the generated CSS architecture

[21:48] Reviewing the main dashboard component

[22:24] Sidebar and navigation components

[22:45] Top bar implementation

[23:08] Projects grid component

[23:44] Recent activity component

[24:12] Summary cards component

[24:27] Task trend chart component

[24:55] Reviewing project file updates

[25:35] Running the completed dashboard

[26:22] Exploring the generated dashboard features

[27:31] Grid interactions: Paging, sorting, filtering, and search

[28:51] Responsive layout demonstration

[30:07] Key advantages of structured UI generation

[30:40] Best practices for AI-assisted UI development

[31:28] Session recap and key takeaways

[32:15] Additional learning resources

Q&A

Q: I’ve spent a weekend and 500+ credits on a layout page that doesn’t work. I only required 3 things

1. An appbar at the top that does not scroll out of sight; it need to be sticky and cover the whole width of the screen.
2. A SideBar for a menu at the left that docks and can expand and collapses by clicking a hamburger placed at the left end of the AppBar.
3. A content area that fills the area beneath the AppBar and to the right of the SideBar. The content should scroll under the AppBar. The SideBar should push the content when expanding. The menu items in the SideBar should open a new page in the content area.

The AI was unable to achieve this with over 500+ tokens. What plan and agent are required to achieve the described layout page?
A: We recommend using advanced models such as Claude Sonnet or other high-capability models. These models generally follow detailed UI instructions and multistep workflows more accurately, resulting in more reliable layout generation and fewer iterations.

Q: Will this work on VS Code or does it require Code Studio as a mandatory env?
A: Agentic UI Builder is not limited to Syncfusion Code Studio. You can install and use it in any supported IDE that provides AI agent and skill integration, including:

• Visual Studio Code.
• Cursor.
• Syncfusion Code Studio.

Q: Is there a plan included for Syncfusion customers?
A: Yes. The Agentic UI Builder is available to all Syncfusion customers.

Q: Does that include Community License users?
A: Yes. Community License users can also install and use Agentic UI Builder.

Q: Do the skills installed along with UI agents provide some testing-specific abilities? Or does it rely on already-there IDE capabilities?
A: The Agentic UI Builder installation includes:

• UI Builder agent functionality.
• Component-specific skills for UI generation.
• Layout and component configuration assistance.

For automated testing, you can install additional testing-focused tools, such as Playwright, depending on your workflow requirements.

Q: What is the difference with Code Studio?
A: The Syncfusion Agentic UI Builder:

• Focuses on generating enterprise UI web pages from natural-language prompts.
• Uses Syncfusion component knowledge and skills to generate production-ready UI code.
• Can be used within supported IDEs.

Syncfusion Code Studio:

• Is a full AI-powered integrated development environment (IDE).
• Understands your codebase and provides context-aware assistance for development tasks.
• Includes AI-powered modes such as ask, edit, agent, plan, and autocomplete.
• Supports feature implementation, debugging, code explanation, and workflow automation.

Q: Does this work with ASP.NET Core?
A: The ASP.NET Core UI Builder support is planned for release this month.

Key takeaways

• Generic AI-generated UI often needs refinement before it is ready for real applications.
• The Syncfusion Agentic UI Builder guides AI through a structured UI generation workflow.
• Embedded Syncfusion Agent Skills provide component-aware implementation guidance.
• Developers can move from prompt to usable UI faster while keeping control over quality and structure.

Related links

• Syncfusion Agentic UI Builder
• Syncfusion Agent Skills
• Syncfusion React UI Builder documentation

What's Changed

• Stream Anthropic /messages responses in E2E fake handlers by @stephentoub in #1868
• [changelog] Add changelog for java/v1.0.5-01 by @github-actions[bot] in #1871
• [changelog] Add changelog for v1.0.5 by @github-actions[bot] in #1869
• Add experimental GitHub telemetry redirection across all SDKs by @MackinnonBuck in #1835
• Update @github/copilot to 1.0.68 by @github-actions[bot] in #1886
• Update Java JaCoCo coverage badge by @github-actions[bot] in #1833
• Remove Java JaCoCo badge auto-update pipeline by @brunoborges with @Copilot in #1826
• Update @github/copilot to 1.0.69-0 by @github-actions[bot] in #1892
• Edburns/1810 java tool ergonomics tool as lambda seeking review by @edburns in #1895
• test(java): add arity 0 and arity 2 coverage to ErgonomicToolDefinitionIT by @edburns in #1897
• Update @github/copilot to 1.0.69-1 by @github-actions[bot] in #1908
• Fix telemetry forwarding handshake CI failures by @stephentoub in #1909
• Improve E2E coverage across SDKs by @stephentoub in #1906
• dotnet: in-process FFI runtime hosting (InProcess transport) by @SteveSandersonMS in #1901
• Update @github/copilot to 1.0.69-2 by @github-actions[bot] in #1914
• Remove P2 installation, use simple retry instead by @edburns in #1916
• Restrict block-remove-before-merge check to PRs targeting main by @edburns in #1898
• docs(java): add ADR-007 native runtime bundling strategy by @edburns in #1923
• Honor inprocess transport in C# E2E harness and fix in-process auth by @SteveSandersonMS in #1920
• Simplify in-process env isolation to snapshot/restore by @SteveSandersonMS in #1929
• fix(python): preserve original JSON keys in Data shim round-trips by @syf2211 in #1900
• C#: make per-client Environment coherent per transport by @SteveSandersonMS in #1930
• Make .NET CopilotClient.DisposeAsync graceful by @SteveSandersonMS in #1932
• Update @github/copilot to 1.0.69-3 by @github-actions[bot] in #1940
• Surface Pydantic ValidationError to LLM in tool arg validation by @idryzhov in #1862
• Update @github/copilot to 1.0.69 by @github-actions[bot] in #1941

New Contributors

• @syf2211 made their first contribution in #1900

Full Changelog: v1.0.5...v1.0.6