The art of simplicity

In 2012(!) I blogged about rubber duck debugging to help me troubleshoot issues. It's a practice I'm still using even today. With GitHub Copilot CLI's newest update, rubber duckis becoming AI driven. Copilot introduces a second AI model from a different family to critique your agent's plans and implementations at the moments where feedback has the highest return. Let's have a look at it in more detail... What rubber duck actually does Rubber Duck is not a general-purpose chat assistant. It's a review agent that will use a model from a complementary AI family to whichever model you've selected as your orchestrator. When you're running a Claude model as your orchestrator, Rubber Duck runs on GPT-5.4. This is intentional: a model reviewing its own output is still bounded by its own training biases. A cross-family reviewer brings genuinely different blind spots to the table. Rubber Duck's output is deliberately narrow — a short, prioritised lis...

Having your AI agent come up with a plan before start coding, has helped me a lot in my agentic development workflow. It allows me to verify the steps the agent will take and allowed me to avoid that the agent goes down the wrong path. To help you with this, Visual Studio got a ‘plan mode’ that once enabled allowed the agent to create a plan. I really liked the feature, the only problem is that is what not always obvious when the agent decides to create a plan and when it just starts executing. To tackle this issue, the plan mode in Visual Studio has evolved to a separate plan agent, similar to what we have in VSCode. Plan first, code second If you have never heard about plan mode or the plan agent, it is a dedicated mode in Copilot Chat that focuses entirely on understanding what you want to build before touching a single file. Instead of jumping straight to implementation, it asks clarifying questions, reads your codebase using read-only tools, and drafts a detailed implemen...

If you're upgrading to the latest version of the Copilot SDK beta, there's a syntax change you need to know about. The .On() method now requires a generic type parameter. As the SDK is still in beta, breaking changes are not unexpected. But this one should be handled with extra care to avoid resource leaks. This post walks you through what changed, why it matters, and how to update your code. What changed In previous versions of the SDK, registering an event handler looked something like this: // Old syntax app.On(evt => { if (ev is AssistantMessageDeltaEvent deltaEvent) { Console.Write(deltaEvent.Data.DeltaContent); }); } In the latest version, the .On() method is now generic. You must explicitly specify the activity or event type you're handling: // New syntax using var subscription = app.On<AssistantMessageDeltaEvent>(evt => { Console.Write(deltaEvent.Data.DeltaContent); }); The method signature has changed from:...

After upgrading the GitHub Copilot SDK to the 1.0.0-beta.10 version, initiating the CopilotClient no longer worked. Instead I got the following error message: System.Text.Json.JsonException: The JSON value could not be converted to System.DateTimeOffset. Path: $.timestamp | LineNumber: 0 | BytePositionInLine: 43.  ---> System.InvalidOperationException: Cannot get the value of a token type 'Number' as a string.    at System.Text.Json.ThrowHelper.ThrowInvalidOperationException_ExpectedString(JsonTokenType tokenType)    at System.Text.Json.Utf8JsonReader.TryGetDateTimeOffset(DateTimeOffset& value)    at System.Text.Json.Utf8JsonReader.GetDateTimeOffset()    at System.Text.Json.Serialization.Converters.DateTimeOffsetConverter.Read(Utf8JsonReader& reader, Type typeToConvert, JsonSerializerOptions options)    at System.Text.Json.Serialization.Metadata.JsonPropertyInfo`1.ReadJsonAndSetMember(Object o...

As a big fan of the GitHub Copilot SDK, I'm trying to keep up with the list of changes. The beta 6 version of the GitHub Copilot SDK now ships a typed CopilotTool.DefineTool helper that lets you configure override flags, skip-permission behavior, and other Copilot-specific metadata without sprinkling magic strings throughout your codebase. This makes working with Copilot tools in C# a lot cleaner. It brings the .NET SDK in line with typed helper APIs already available in other language SDKs and makes tool definitions easier to write, refactor, and reason about. The old way vs the new way Before this change, wiring up Copilot-specific metadata meant relying on loosely typed configuration — easy to mistype, hard to discover, and brittle to refactor. Now, the same intent is expressed through a clean, strongly typed API: Before // Metadata via magic strings options["is_override"] = "true"; options["skip_permission"] = "true"; After ...

If you've been using Entity Framework Core for a while, you've probably written a query like this: var ids = new[] { 1, 2, 3, 4, 5 }; var blogs = await context.Blogs .Where(b => ids.Contains(b.Id)) .ToListAsync(); Simple enough. But under the hood, how EF Core translates that ids collection into SQL has quietly changed(again) in EF Core 10, and this time the change is significant enough to be listed as a breaking change. Let's dig into what's happening, why the EF team made this call, and what it means for your applications. A brief history To understand EF Core 10's approach, it helps to know where things stood before. EF Core 8: The OPENJSON era In EF Core 8, when you passed a collection to a LINQ Contains or Where clause, EF encoded the entire collection as a JSON string and sent it as a single parameter. SQL Server would then unpack it using the OPENJSON function: SELECT [b].[Id], [b].[Name] FROM [Blogs] AS [b] WHERE [b].[Id] IN ( ...