The art of simplicity

In the previous post, we looked at how to implement IValidateOptions<T> by hand — writing a dedicated validator class, injecting services, and expressing cross-property constraints that Data Annotations can't handle. That approach gives you full control and is the right tool when validation logic is genuinely complex. While researching that post I discovered another feature that's worth knowing about: when your validation can be expressed with Data Annotation attributes, the options validation source generator (available since .NET 8) will write the IValidateOptions<T> implementation for you at compile time. You get the safety of startup validation without the boilerplate, and as a bonus the generated code is reflection-free and AOT-compatible. The problem with runtime data annotations Before the source generator existed, the standard way to add annotation-based validation was ValidateDataAnnotations() : This works, but it uses reflection at runtime to ...

When you build .NET applications with strongly typed configuration, IOptions<T> and its variants give you a clean way to bind appsettings.json sections to C# classes. But binding isn't the same as validating - a missing required value or an out-of-range number will happily bind to a default and silently break your app at runtime. IValidateOptions<T> is the hook .NET provides to fix that. The problem: silent misconfiguration Consider a typical options class: If Host is missing from appsettings.json , your app starts fine. The failure surfaces only when the first email is sent — in production, at 2 AM. Data Annotations ( [Required] , [Range] ) combined with ValidateDataAnnotations() help, but they fall short when you need: Cross-property validation (e.g., Port must be 465 when UseSsl is true ) Async or database-backed checks Conditional logic depending on environment Reusable validators shared across multiple options types This is where I...

If you've ever been mid-session with Copilot and thought "I want to try a completely different approach, but I don't want to lose everything I've built up here" — the new /fork command is exactly what you've been waiting for. Shipped in the February 2026 release of VS Code, /fork lets you branch a chat session into a new, fully independent thread — complete with the full conversation history — so you can explore an alternative direction without touching the original. The problem it solves Until now, exploring multiple design options or implementation strategies with Copilot meant one of two things: Start a new session — losing all the context you've already established. Stay in the same session — making your conversation messy and hard to track. Neither is great. Especially for larger tasks where the agent has already built up a useful mental model of your codebase, intent, and constraints. How to use /fork There are two ways to ...

There's a specific kind of frustration familiar to anyone who's used an AI coding agent: you send a request, it starts running, and thirty seconds later you realize you forgot to add a critical constraint. Or you think of a follow-up. Or you can see it heading somewhere wrong, and there's nothing you can do but sit there and watch. That's been the workflow. One prompt, one response, wait, repeat. The February 2026 release of VSCode (1.110) changes this in a way that's simple to describe but surprisingly powerful in practice: you can now send messages while a request is still running. What's actually changed The new behavior covers two distinct scenarios. The first is mid-flight intervention : if Copilot is in the middle of generating a response and you realize it's going in the wrong direction, you can now type a corrective message immediately. You don't have to wait. The agent incorporates your guidance and adjusts course without restarting the se...

We've covered modes, session management, parallelization with /fleet , and hooks. To close out the series, we're looking at delegation, the feature that lets you hand off work from your terminal to a background agent in the cloud, and build a network of specialized custom agents for your team. Two flavors of delegation "Delegation" in Copilot CLI means two related but distinct things: /delegate — handing off a task to the Copilot coding agent in the cloud, which works asynchronously on GitHub while you continue with other work Custom agents + /agent — routing tasks to specialized subagents tailored to specific types of work, running locally within your CLI session Both follow the same principle: rather than one generalist agent handling everything, you route work to whatever agent is best suited for the job. Let's look at each in turn. /delegate — Offload to the cloud What it does Running /delegate TASK-DESCRIPTION commits any unstaged ch...

So far in this series we've covered modes, session management, and parallelization with /fleet . This post is about hooks — one of the more powerful features of Copilot CLI. Hooks let you inject your own shell scripts at key moments during a session, enabling everything from audit logging to blocking dangerous commands before they execute. What are hooks? Hooks are custom scripts that run at specific points during a Copilot CLI session. They receive structured JSON input describing what's happening at that moment — which tool is being called, what arguments it received, what the session context looks like — and can optionally respond with a JSON output that influences what Copilot does next. The key thing that makes hooks different from just writing good prompts or instructions: hooks are deterministic. They execute your code at specific lifecycle points with guaranteed outcomes. Unlike instructions that guide agent behavior, a hook can guarantee that a dangerous comman...