The art of simplicity

A few weeks ago I wrote about Copilot Memory in VS Code - the GitHub-hosted system that lets Copilot learn repository-specific insights across agents. Since then, VS Code has shipped a second, complementary memory system: the Memory tool . These two systems solve related but distinct problems, and understanding both helps you get the most out of Copilot in your daily workflow. What is the Memory Tool? The Memory tool is a built-in agent capability that stores notes locally on your machine . Unlike Copilot Memory, which lives on GitHub's servers and requires a GitHub repo to function, the Memory tool writes plain files to your local filesystem and reads them back at the start of each session. You enable or disable it with the github.copilot.chat.tools.memory.enabled setting. It's on by default. Three memory scopes VSCode organizes memories into three scopes: Scope Persists across sessions Persists across workspaces Good for ...

I regularly clone repos on Github. I explore other codebases to learn other coding approaches and improve my understanding of specific libraries. Sometimes these repos have good documentation available but most of the time I end up spelunking through source files trying to reverse-engineer what this thing does. Until I discovered DeepWiki DeepWiki is built to fix that. What is DeepWiki? Launched by Cognition AI — the team behind Devin — DeepWiki is the free public version of their internal Devin Wiki and Devin Search tools, designed to help developers quickly understand complex codebases. The idea is simple: whether it's a public repository or a private project, DeepWiki generates Wikipedia-like documentation pages through simple operations. The quickest way to try it? Just replace github.com with deepwiki.com in any public repo URL. If your repo is not indexed yet, you can ask to index it. Enter an email and you are good to go.   That's it. No install, no acc...

With all this AI features available, you would expect that you no longer loose time on stupid issues. Unfortunately, we are not there yet. I lost a chunk of time today to a behavior in SQL Server that, once you know it, is totally obvious — but until then is absolutely maddening. I'm sharing it here so hopefully you don't lose the same time I did. The setup I had a script meant to be idempotent: create a database user if it doesn't exist, or update it if it does. Standard stuff. Here's a simplified version: Looks fine, right? Run it once — works. Run it a second time and SQL Server throws an error saying it can't find usr_SampleDB_reader . The user you just created. In the same database. With the same script. What's actually happening When you run ALTER USER [...] WITH LOGIN = [...] , SQL Server renames the user to match the login name — by default, silently, without a warning. So after the first run, usr_SampleDB_reader no longer exists. It's...

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