The art of simplicity

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...

In the previous posts we covered the different CLI modes and session management. This time we're looking at one of Copilot CLI's most powerful features: the /fleet command. If you've ever wished you could clone yourself to tackle several parts of a codebase at once, this is the closest thing to it. What is /fleet ? When you send a prompt to Copilot CLI, by default a single agent works through the task sequentially. /fleet changes that model entirely. The /fleet slash command lets Copilot CLI break down a complex request into smaller tasks and run them in parallel, maximizing efficiency and throughput. The main Copilot agent analyzes the prompt and determines whether it can be divided into smaller subtasks. It then acts as an orchestrator, managing the workflow and dependencies between those subtasks, each handled by a separate subagent. In practice, this means a task that might take 20 minutes sequentially can complete in a fraction of the time — because independ...

In the first post we covered the different modes in Copilot CLI. This time we're looking at something that becomes essential once you're doing serious work in the CLI: session management. Sessions let you pause, resume, and organize your work — across terminal restarts, across machines, and across multiple concurrent workstreams. What is a session? Every time you launch Copilot CLI, you're working inside a session. A session captures your full conversation history, the tool calls Copilot made, the files it touched, and the permissions you granted — all stored locally under ~/.copilot/session-state/ . Sessions are identified by a UUID and automatically receive an AI-generated name based on your first message, making them easy to identify later. Most important is that sessions persist after you close the CLI. That means nothing is lost when you shut down your terminal — you can always pick up right where you left off. Resuming a session Pick up where you left off ...

Welcome to the first post in my series on getting the most out of GitHub Copilot in the terminal. We'll kick things off with one of the most important things to understand: the different modes Copilot CLI operates in, and when to reach for each one. A quick intro to GitHub Copilot CLI GitHub Copilot CLI is a terminal-native coding agent — not just a chat wrapper. It can plan complex tasks, edit files, run tests, and iterate autonomously, all without leaving your terminal. But to get the most out of it, you need to understand how to control how much autonomy you give it at any point in time. That's exactly what the different modes are for. You cycle through the main modes using Shift+Tab . A mode indicator in the CLI's footer tells you which one you're currently in. The three main modes 1. Standard Mode — The default When you launch copilot , you start in standard (interactive) mode. This is the classic back-and-forth: you submit a prompt, Copilot responds o...

Between all this AI craziness, we often forget to appreciate the small tools and features that make our lives easier. Such  a feature is Central Management Servers (CMS) , a built-in SQL Server feature that lets you manage a whole fleet of instances from one place. Let's walk through what it is, how to set it up, and when it'll actually make your life easier. So, what is a Central Management server? At its core, CMS is a SQL Server instance that acts as your hub for organizing and talking to other SQL Server instances. You register your other servers under it, group them however makes sense (by environment, team, region — you name it), and then query all of them at once. The metadata about your registered servers gets stored in the msdb database on the CMS host. Nothing fancy — it's just a central directory that SSMS knows how to use. Setting it up in SSMS Here's how to get going in SQL Server Management Studio: Step 1: Open the Registered Servers panel ...

The timeout appeared without warning. A migration pipeline that had run fine in staging suddenly ground to a halt in production, throwing lock wait timeouts across multiple worker threads. The application was querying and writing to the same table, and somewhere in that dance of reads and writes, things had seized up entirely. Here is a walk through the investigation, from the first diagnostic query all the way to the fix — along with an explanation of why it worked. Find the blocker The first tool in any SQL Server lock investigation is sys.dm_exec_requests joined against sys.dm_exec_sessions . This query shows you every session that is currently blocked, who is blocking it, and what SQL both parties are running: A second query dug into the exact lock modes held on the specific table in question: The output told the story The results were unambiguous. Three sessions. One blocker. Two victims. Blocking Blocked Wait type ...

We recently discovered a bug in one of our legacy ASP.NET MVC applications — the kind that doesn't throw an exception, doesn't log a warning, and doesn't announce itself in any way. It simply silently drops a filter on the floor. Unfortunately, that filter happened to be a security control. Here's the story of what happened, why it happens, and what we're doing about it. Remark: If you don’t have any legacy .NET Full Framework ASP.NET MVC apps remaining (good for you), you can stop reading. What we were trying to do Our application uses action filters for authorization. We had a global filter registered for all controllers that enforced a baseline set of access rules. For certain controllers, we wanted a stricter policy, so we added a local filter attribute directly on those controllers. Both filters shared the same attribute type. The attribute was decorated like this: The intention was clear: the local, more restrictive filter on the controller would...

I only recently started using the ASP.NET Core's minimal API style, but an annoying thing I already encountered is the "long parameter list" problem. Route handlers that accept five, six, or seven parameters start to feel unwieldy fast. The good news is that a solution exists through the [AsParameters] attribute, introduced in .NET 7,  that gives you a clean way out. The problem it solves Minimal APIs are appealing precisely because they're lightweight — no controllers, no ceremony. But that simplicity starts to break down as your endpoints grow more complex. Consider this example endpoint: That's eight(!) parameters before you've written a single line of business logic. It's hard to read, hard to test, and grows more painful every time requirements change. Enter [AsParameters] [AsParameters] lets you group related parameters into a plain C# class or record and bind them all at once. ASP.NET Core inspects the type's constructor and public ...

Minimal APIs are the recommended approach for building fast HTTP APIs with ASP.NET Core. They allow you to build fully functioning REST endpoints with minimal code and configuration. You don't need a controller but can just declare your API using a fluent API approach: This makes it very convenient to build your APIs. However you need to be aware that a lot of magic is going behind the scenes when using this approach. And this magic can bite you in the foot. Exactly what happened to me while building an autonomous agent invoked through a web hook. The code In my application I created the following API endpoint using the minimal API approach: The minimal API injects an AzureDevOpsWebhookParser that looks like this: Nothing special… The problem The problem was when I called this endpoint, it failed with the following error message: InvalidOperationException: TryParse method found on AzureDevOpsWebhookParser with incorrect format. Must be a static method with for...

Over the course of my career, I've been part of multiple initiatives to start internal communities at work. Some of them became something genuinely special — people showing up, contributing, looking forward to the next gathering. Others quietly died after a few months, victims of low attendance and dwindling energy. For a long time I couldn't figure out what separated the successes from the failures. Was it the topic? The timing? The right people involved? I kept searching for the formula. Then I listened to an episode of the ReThinking podcast last week where Adam Grant sat down with Dan Coyle — author of The Culture Code and his new book Flourish — and one thing Coyle said stopped me in my tracks. Community, he pointed out, literally means shared gifts . And shared gifts aren't something you passively receive. They're something you participate in . We've been thinking about it the wrong way Maybe you’ve tried to build an internal community before. You ...

Being new to Microsoft Fabric I noticed that you have multiple options when writing notebooks using Python: run your code with PySpark (backed by a Spark cluster) or with Python (running natively on the notebook's compute). Both options look almost identical on the surface — you're still writing Python syntax either way — but under the hood they behave very differently, and picking the wrong one can cost you time, money, and unnecessary complexity. In this post I try to identify the key differences and give you some heuristics for deciding which engine to reach for. Python vs PySpark: what's actually different? When you select PySpark in a Fabric notebook, your code runs on a distributed Apache Spark cluster. Fabric spins up a cluster, distributes your data across multiple worker nodes, and executes transformations in parallel. The core abstraction is the DataFrame (or RDD), and operations are lazy — nothing actually runs until you trigger an action like .show() ...