When you let Copilot edit your code in agent mode, every change waits for a decision: Keep or Undo. For a small change that's fine. After ten prompts in a row, you're clicking Keep more than you're reading code. VS Code has a setting to take that click away. Why do we need this? By default, edits from chat are pending until you accept or discard them. The pending state survives closing VS Code, so you can come back later and still decide. That's a good default. But if you already review everything in a diff before you commit, the extra step per edit adds little. Accept edits after a delay Add this to your settings.json : "chat.editing.autoAcceptDelay": 5 Edits are now accepted automatically after the delay. The default is 0 , which means auto-accept is disabled. You are not locked out. While the countdown runs, hover over the editor overlay controls to cancel it, and you can still Undo afterwards. Keep approval for sensitive files Auto-...
I think that is the clearest blog title I used in years. Why do I mention this? Let me explain... Some time ago we stumbled over a performance issue in our applications. The root cause was a fragmented index, caused by the usage of a standard guid instead of a sequential guid. While looking for the right fix, I had to revisit one of my own posts: Sequential GUIDs with .NET 9 . In that post I mentioned that you can use Guid.CreateVersion7() to create a sequential guid. That is technically correct, but it is NOTa solution for SQL Server. Why does a random guid hurt? A clustered index in SQL Server is a sorted B-tree. When the key is random, every insert lands on a random page. If that page is full, SQL Server has to split it, which leaves you with half-empty pages, a fragmented index and more I/O. A sequential key always appends at the end, so pages fill up and stay put. Why is a version 7 guid not sequential for SQL Server? A UUID version 7 (RFC 9562) starts with a 48-bit U...