Most discussions about AI-native development jump from this problem – agents’ tendency to accumulate tech debt – directly to tests. … Tests verify that code does what it did before.
Whether what it did was even the right way to do it is a separate question.
She argues that while agents make it easy to have rigorous traditional test coverage, at best unit tests maintain local code cohesion. At worst, they can actually make it harder to improve what agents are worst at: the wider coherence of the entire codebase.
So far I’ve been impressed with how effective the broader automated checks she describes can be to guard against agentic nonsense.
Crane is a migration assistant for GitHub repositories that plans, executes, and verifies code migrations in small agentic steps while keeping humans in control.
Just a warning, unless a topic is personal, I’m going to start mostly writing on the JasperFx Software website to try to drive more traffic there.
Don’t throw exceptions for an entity that isn’t found or a value out of range — fair. But swapping that for Result<T> everywhere just trades one kind of noise for another: wrappers, .Match() calls, discriminated unions in every layer.
With Wolverine, most endpoints skip both:
[Entity(Required = true)] → your 404
FluentValidation → a 400 ProblemDetails
Endpoint stays clean, and the OpenAPI metadata still comes out right — no .Produces() calls, no IResult “mystery meat,” no fake C# discriminator union ugliness
Exceptions still earn their place for real failures — Wolverine turns those into retries, re-queues, and dead-lettering. But error handling shouldn’t be your control flow, and neither should a Result wrapper with idiomatic Wolverine usage.
Less ceremony, less noise. Full write-up with code in the comments
Microsoft Build 2026 is a wrap, and there was a LOT. Whether you were there in person, streaming live, or catching up now, this recap covers the biggest announcements, top sessions, and everything you need to keep building.
Vision lead-off: the system around AI is the differentiator
The GitHub Copilot app is a new desktop experience designed for directing multiple agents in parallel. From a single “My Work” view, you can see active sessions, issues, pull requests, and background automations across connected repositories. The app is now available in technical preview for Copilot Pro, Pro+, Business, and Enterprise users.
Key capabilities in the Copilot app:
Parallel agent sessions run in isolated git worktrees, so agents don’t step on each other. The app handles worktree setup and cleanup automatically.
Canvases are bidirectional work surfaces where agents update plans, diffs, browser sessions, and deployment state in real time, and developers can edit, reorder, or redirect on the same surface.
Cloud and local sandboxes give agents a bounded environment to run code, inspect results, and iterate without touching production. Organizations define their own policies.
Agent Merge carries pull requests through review, CI, and merge by monitoring checks, tracking reviewers, and addressing failures. You choose how far Copilot goes.
Copilot code review now supports medium-tier review with higher-reasoning models, a /security-review skill, and native Azure DevOps support.
Copilot SDK is now GA in Node.js/TypeScript, Python, Go, .NET, Rust, and Java, exposing the same agentic runtime that powers the app.
Copilot CLI has a redesigned TUI, voice input (on-device, audio never leaves your machine), and /every for scheduled recurring tasks.
MAI-Code-1-Flash in GitHub Copilot
MAI-Code-1-Flash is now available for GitHub Copilot. This is Microsoft’s latest small-tier coding model, and it’s the first in a new wave of purpose-built coding models from Microsoft designed and tuned specifically for GitHub Copilot. MAI-Code-1-Flash delivers best-in-class quality for its size, outperforming other small models in early testing, making it well-suited for lightweight coding workflows.
MAI-Code-1-Flash is rolling out to Copilot Free, Student, Pro, Pro+, and Max plans, starting with a limited set of users and expanding gradually. You can select it from the model picker in Visual Studio Code. To learn more, see the MAI-Code-1-Flash model page.
Coreutils for Windows is now generally available, bringing Linux-like command-line utilities that run natively on Windows.
Windows Development Skills is now generally available, providing structured skills for agentic native app development using WinUI 3 and WinApp CLI.
WinUI and WinApp CLI guidance is being operationalized through those Windows Development Skills so agents can build native Windows apps end-to-end more efficiently.
Windows Developer Configurations is now generally available, powered by WinGet for one-command setup of a developer-ready Windows 11 environment.
WSL containers were announced as coming to public preview, with built-in CLI and API support for Linux container workflows on Windows.
Intelligent Terminal was announced in experimental preview to add context-aware agent support directly in terminal workflows.
Building desktop apps, local AI tools, or enterprise-managed developer environments? This post should be near the top of your reading list.
OpenClaw + Scout: always-on agents, from open source to enterprise
One of the biggest crowd moments at Build was OpenClaw running natively on Windows. OpenClaw is an open-source, self-hosted AI agent framework created by Peter Steinberger that can execute multi-step workflows, control apps, browse the web, and manage files autonomously. Scott Hanselman and Steinberger demoed it live on the keynote stage.
On Windows, OpenClaw runs securely inside Microsoft Execution Containers (MXC), a new policy-driven containment layer that enforces what agents can access at runtime. The new Windows companion app makes setup straightforward: install, connect your claws, and you’re running. Microsoft also showed cloud-based ephemeral sandboxes for OpenClaw with managed identity, full isolation from your local machine, and rebuild times around six minutes.
On the enterprise side, Microsoft launched Scout, an always-on personal agent built on OpenClaw’s architecture and integrated with Microsoft 365. Scout brings persistent identity, proactive task management across email, calendar, and reports, and enterprise policy conformance through Agent 365.
Developers who already use agents for coding workflows will feel right at home here. OpenClaw treats agents as long-running, multi-session processes rather than single-prompt responses, and the MXC sandboxing model is the same one adopted by GitHub Copilot CLI for process isolation. If you’ve been looking for a way to run always-on local agents safely, this is the stack to explore.
Agent Harness made production patterns first-class, including context compaction, instruction merging, todo tracking, and extensible providers.
Foundry Hosted Agents introduced a direct path from local development to managed production hosting with scaling, session persistence, and built-in observability.
CodeAct support (via Hyperlight) was introduced to reduce orchestration overhead by collapsing many tool calls into fewer model turns.
GitHub Copilot SDK integration reached 1.0 support in Agent Framework for .NET and Python.
Multi-agent Handoff orchestration reached 1.0 with explicit topology and guardrails.
Two open-source releases from the Command Line blog round out the agent governance picture:
Agent Control Specification (ACS) is a portable, vendor-neutral spec for runtime agent governance. It defines eight lifecycle interception points (input, pre/post model call, pre/post tool call, output, startup, shutdown) with a declarative YAML manifest that works across Python, Node, .NET, and Rust. Write your policies once, enforce them in any framework.
ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) turns natural-language behavior specs into executable evaluation pipelines. Describe what your agent should and shouldn’t do, and ASSERT generates stratified test cases, runs them against the agent, and scores each trace with rationale and policy citations.
Union types in C#: one of the most requested language features is finally landing! Union types model closed sets of data shapes for wire protocols and domain modeling.
AI Building Blocks for .NET: a practical, opinionated guide to adding AI capabilities to C# apps, from model integration to agent patterns with production-ready code.
Building for the agentic web with .NET 11: ASP.NET Core and Blazor gain new building blocks for agents, tools, skills, and components, closely integrated with Aspire.
Simplifying .NET installs with dotnetup: a new cross-platform tool to manage .NET SDK and Runtime installations, making developer onboarding smoother than ever.
It also links to skilling resources like the Build Skills Challenge, Skills Hub, Marketplace resources, MVP resources, and Build event info. Pro tip: start here if you want a structured way to follow up on everything from Build!
Watch now: Build Day 2 livestream
A full day of what’s new in GitHub Copilot and Visual Studio Code, straight from the people building it. New features, live demos, and a few surprises.
The Terminal Live: Day 1 and Day 2
The GitHub Copilot team coded live from Microsoft Build across both days. Segments covered cloud agents, code review, GitHub Copilot CLI, MCP, Visual Studio 2026, Windows Terminal, Aspire, the GitHub Copilot SDK, and Visual Studio Code agents.
Top on-demand sessions
Couldn’t watch everything live? Here are some of the top sessions you can catch on demand right now.
Why your AI code doesn’t ship: Closing the gap to production (BRK200)
The Microsoft Build CLI is a GitHub Copilot CLI skill that connects your local project to the Build session catalog. It reads your dependencies, finds relevant sessions, and helps you act on what you learn. Install it with /plugin install microsoft/Build-CLI in GitHub Copilot CLI, or search @agentPlugins microsoft-events in VS Code Extensions.
Beyond code: other keynote highlights
While this post is about top developer news and releases, I can’t help but mention some power-user goodies and nerdy toys from the keynote:
Majorana 2: Microsoft’s next-generation quantum chip based on topological qubits. Not something you’ll ship code against today, but a signal of where the compute horizon is moving.
Project Solara: A new chip-to-cloud platform for agent-first devices, with concept reference designs for a wearable badge and a desk companion. Agents built with Microsoft 365, Copilot Studio, and the Agent Framework will be able to surface on these new form factors.
Surface RTX Spark Dev Box: A developer-focused device with NVIDIA RTX Spark silicon, delivering 1 petaflop of AI compute and 128 GB unified memory for running models locally. Available later this year.
Frontier Tuning: Demoed on the keynote stage as a new approach to fine-tuning frontier models within Microsoft Foundry.
Seven new MAI models: Mustafa Suleyman unveiled seven new models across the MAI family, expanding the range of model sizes and capabilities available in the platform.
So cool! Looks like I need to start saving up for that Surface RTX Spark Dev Box…
Keep building
Build delivered a clear message for developers: this is about end-to-end systems now, not isolated AI features. The most successful teams will combine model capability with strong engineering workflows, platform fundamentals, governance, and continuous improvement.
We’re incredibly excited about everything that was announced, and we can’t wait to see what you build with it! For code samples, repos, and practical follow-up paths, start with:
Today, I wanted to show you how to detect when an element’s visibility changes using the JavaScript IntersectionObserver API. Let’s dig in!
The Use Case
I was recently working on a Web Component that calculates how much of the viewport it occupies, and automatically resizes itself to make sure it never overflows.
As a standalone component, it worked fine. But in real-world use, it was nested inside Kelp’s toggle tabs component. When it ran it’s calculations, it was inside a [hidden] parent element, and the math was all wrong.
I originally tried listening for all of the custom events emitted by Kelp components that show or hide content, but that was both error prone and not particularly sustainable.
I decided to focus on detecting when the web component’s visibility changed, and learned that you can use the IntersectionObserver API for that.
How It Works
When an element is [hidden] (or display: none, or visiblity: hidden), even if if the hidden parent is in the viewport, the element is not considered to be intersecting with the viewport.
As soon as it becomes visible, it is, and the IntersectionObserver callback method runs.
Create your observer, and run whatever callback function you need on the intersecting element (entry.target). Here, I’m running calculateSize().