svnscha - productivity

Introducing Native Windows Debugging for VS Code: Kernel & Remote Debugging

2026-06-07T00:00:00+00:00

Remember the Cliffhanger?

A while back I wrote about the joy of writing a debugger adapter for Visual Studio Code. It started with a simple wish - I just wanted a faster way to remote-debug a service running in a VM - and ended with a working proof of concept: VS Code driving WinDbg through a custom Debug Adapter Protocol implementation.

But that post ended on an honest note:

I have not implemented remote debugging or kernel debugging yet, but I now feel ready to take a real shot at both without getting lost in the basics again.

Well. I took the shot.

Remote debugging works. Kernel debugging works. And the whole thing is now a real, installable VS Code extension: Native Windows Debugging (dbgeng).

Debug native Windows code - C and C++ programs, services, and even the Windows kernel - straight from Visual Studio Code, using the same engine that powers WinDbg.

That's the whole pitch in under two minutes. Now let me show you what's behind it.

Get It Right Now

No waiting, no building from source:

Marketplace: Native Windows Debugging (dbgeng)
Source: github.com/svnscha/dap-dbgeng (MIT licensed)
Docs: svnscha.github.io/dap-dbgeng

The adapter is bundled inside the extension, so there's nothing separate to build, download, or point at. Install it, write a launch.json, press F5. That's it.

Four Ways to Debug - Two of Them Were Never Possible Before

VS Code has always had great local debugging for plenty of languages. But the moment you wanted native Windows remote or kernel debugging, you hit a wall. That stack lives in Visual Studio and WinDbg, not in VS Code - because of course it does.

This extension closes exactly that gap. One adapter, four scenarios:

Local - the debugger starts your program and debugs it from launch.
Attach - connect to a process that's already running, by its PID.
Remote - debug a user-mode process on another machine via dbgsrv.
Kernel - debug kernel-mode drivers and the OS around them.

The first two are the comfortable ones. The last two are the gap I set out to close. Let's walk through them.

Local: The Comfortable Starting Point

Start simple. The debugger launches your program and you step through it like any other debugger in VS Code. It's just a launch.json:

{
  "name": "Debug myapp",
  "type": "dbgeng",
  "request": "launch",
  "program": "${workspaceFolder}/build/Debug/myapp.exe",
  "stopAtEntry": true
}

program is the only thing you really have to provide. dbgeng.dll is found automatically from your installed Windows SDK, so you usually don't even set a path. Set a breakpoint, press F5, and you get the full loop: continue, step over, step into, step out, call stack, locals, watch expressions, and a Debug Console that evaluates expressions through the real engine.

If you use the CMake Tools extension, you can even drop the program line entirely - the adapter defaults to your selected CMake launch target. Point CMake's debug command at the dbgeng type and CMake: Debug just works.

Attach: Already Running? Just Connect

Sometimes the process is already alive and you don't want to restart it. Attach to it by its process ID:

{
  "name": "Attach to myapp",
  "type": "dbgeng",
  "request": "attach",
  "processId": 12345
}

Don't know the PID off the top of your head? Set "processId": "${command:dap-dbgeng.pickProcess}" and you get a process picker at debug time. Same familiar VS Code interface, with the real Windows debug engine underneath.

Remote: My Favorite Part

This was the first scenario I implemented: debugging a user-mode process on another machine while keeping the debug engine and symbols on the local system.

The trick is the Windows process server, dbgsrv. You run it on the target, and your machine connects to it over TCP (or a named pipe).

On the target, start the process server:

dbgsrv -t tcp:port=5005

On your machine, point a launch.json at it:

{
  "name": "Attach on TARGETPC",
  "type": "dbgeng",
  "request": "attach",
  "processId": "${command:dap-dbgeng.pickProcess}",
  "connectionString": "tcp:port=5005,server=TARGETPC"
}

Press F5, pick the remote process from the list (the picker now shows processes on the dbgsrv host), and you're debugging it remotely. The engine and symbols never leave your machine - only the debuggee lives on the other side.

This is precisely the workflow I wanted at the very beginning: compile locally, deploy to the VM, attach, get back to work. Now it's a one-keystroke thing.

Kernel: Yes, Really

And then there's the big one. Kernel-mode debugging from VS Code.

Kernel debugging is whole-machine, so you need two boxes: a host (VS Code + the adapter) and a target being debugged - almost always a throwaway VM, because kernel debugging halts the entire target at breakpoints.

On the target, enable kernel debugging and reboot:

bcdedit /debug on
bcdedit /dbgsettings net hostip:<HOST-IP> port:50005 key:1.2.3.4

On the host, point a kernel config at it:

{
  "name": "Debug driver (KDNET)",
  "type": "dbgeng",
  "request": "attach",
  "kernel": true,
  "connectionString": "net:port=50005,key=1.2.3.4"
}

kernel: true flips the adapter into kernel mode and turns connectionString into a kernel transport. There's no processId here - the session is the whole machine. Press F5, it connects over KDNET, and breaks at DriverEntry. From the same editor people keep telling me is "just a text editor."

Kernel debugging. Just another breakpoint. That still feels a little unreal to type.

KDNET isn't the only option, either - the same connectionString field speaks serial (named pipe), 1394, and USB transports too. Whatever your VM or test box gives you.

How It Works

A few things changed since the proof of concept, and they're worth a mention.

It talks to the engine natively. The adapter uses the real DbgEng APIs throughout - IDebugClient, IDebugControl, IDebugSymbols, IDebugSystemObjects, with IDebugEventCallbacks and IDebugOutputCallbacks for events. No fragile text-scraping of WinDbg console output. When the engine knows something, the adapter asks it directly.

The protocol layer is still generated. That code-generation step I was so happy about last time paid off again. src/protocol/ is generated from the official DAP schema, so every request, response, and event stays in lockstep with the spec instead of drifting from hand-written DTOs.

The POC grew up - and changed language. The original proof of concept was C#. Hardening it into something I'd actually ship meant rebuilding the adapter in C++20 (CMake + Ninja, vcpkg manifest mode), sitting much closer to the engine it wraps. That was part of the "harden the rough edges" plan, and it made the kernel and remote work far less painful.

It records itself. There's a built-in session-trace recorder that doubles as the project's replay-test format. Recorded sessions get replayed against real test debuggees in CI, so the behaviors you see in those videos are the same behaviors the test suite asserts on.

An Honest Word on Scope

I'm keeping the same promise I made in the first post: the adapter advertises only what it implements correctly, rather than dangling buttons that misbehave.

What works today: line and conditional breakpoints, step over/into/out, continue, pause, instruction-level stepping in the disassembly view, call stack with delayed frame loading, variables and scopes (including registers), set-variable, expression evaluation in the Watch pane and Debug Console, disassembly view, and clean terminate/disconnect.

What's planned but not advertised yet: function breakpoints, data breakpoints (watchpoints), hit-conditional breakpoints, logpoints, read/write memory, a modules view, evaluate-on-hover, and hex formatting toggles. The engine can do all of these - the adapter just doesn't expose them yet. The features reference keeps the full, deliberately conservative list.

And here's the escape hatch: anything the UI doesn't surface, you can usually still do by typing native debugger commands straight into the Debug Console. It's the real engine - it'll answer.

Getting Started

If you want to try it, the whole loop is about ten minutes:

Install Native Windows Debugging (dbgeng) from the Marketplace.
Make sure you have Debugging Tools for Windows (it ships dbgeng.dll, via the Windows SDK or WDK installer). The adapter finds it automatically.
Drop a dbgeng configuration into .vscode/launch.json - pick the scenario from above.
Set a breakpoint, press F5.

The Getting Started guide walks through it in detail, and each scenario has its own page in the docs.

Your Turn

This is open source, and it's at the stage where real-world usage is the most valuable thing it can get. So:

⭐ Star it on GitHub if it's useful to you.
🐛 Report a bug through the issue tracker - the templates tell you what to include.
🔧 Contribute if you're into native Windows debugging internals; see CONTRIBUTING.md.

Summary

Last time I closed with "I just want to remote debug a service on a VM." That was the entire ambition.

It turned into DAP, a code generator, a dbgeng wrapper, a pile of state-machine bugs - and now remote debugging, kernel debugging, a published extension, and a documentation site.

The gap between "VS Code can't do native Windows kernel and remote debugging" and "actually, now it can" is closed. With the same engine that powers WinDbg, sitting quietly behind the editor you already use every day.

And yes - it still started with "I just want to remote debug a service on a VM."

P.S. - One More Thing About Those Videos

While you're here: how did you actually like the videos? Be honest.

Because here's the fun part - this is the first time I generated end-to-end videos, all the way from Claude to YouTube. No editing suite, no timeline scrubbing, no manual voiceover takes. Just prompting and vibing until it looked right.

The stack, if you're curious:

Remotion for the video itself - everything you see is React, rendered to MP4. Code as video turns out to be a really nice fit for the "iterate fast" loop.
My DGX Spark doing the heavy lifting locally.
MOSS-TTS for the voice. And here's a little detour: I first deep-cloned my own voice. The result was genuinely impressive - but not quite perfect, and the "almost me" uncanny gap bugged me more than I expected. So I switched to a fully synthesized voice instead, and I was happier with that than with a not-quite-right clone of myself.

I think that's pretty cool. A little surreal, honestly. The same "describe what you want, iterate, ship" loop that built the debugger also produced the launch video for it.

So let me know what you think - of the extension and of the videos. What worked, what felt off, what you'd want next. There's no comment box here, so just hit me up (LinkedIn or GitHub) or open an issue. I'm genuinely curious.

The Joy of Writing a Debugger Adapter for Visual Studio Code

2026-04-15T00:00:00+00:00

Current State

Before I get into the story, here is the current result: Visual Studio Code debugging a C++ application with WinDbg under the hood through my first proof of concept integration.

Right now this is still an early POC, not a finished debugger experience. It proves the architecture works and that VS Code can drive WinDbg through a custom adapter, but it still needs a lot more iteration before I would call it really useful.

One detail I already like is that the debugger command window is not a fake simplified console. I can type regular WinDbg commands straight into it.

Why

Because I do what I always do when a workflow annoys me: I build a tool until the annoyance goes away.

This time the pain point was remote debugging a service application running inside a VM. My ideal flow was simple:

Compile locally
Deploy to the VM
Start or restart the service
Attach a debugger
Get back to work without ten minutes of clicking around

That sounded perfectly reasonable: a small helper extension for Visual Studio Code, a bit of automation, some launch configuration glue, and done.

That was the plan.

It did not stay the plan.

Removing Friction

I started with the pragmatic part first: automate the annoying steps.

I wired up a helper extension that could compile the service, copy the binaries to the VM, and prepare the remote machine for debugging. This is my favorite kind of productivity work, because the payoff is immediate. Every bit of friction you remove saves time again and again.

Once the plumbing was in place, I expected the final step to be easy: tell VS Code to remote debug the service and call it a day.

Instead, I hit a wall.

VS Code Is Not Visual Studio

At first glance, this feels like something that should already exist. Visual Studio has mature debugging capabilities. VS Code has debugging. Microsoft builds both. Surely there must be a supported path to do classic remote Windows debugging from VS Code, right?

Not really.

The more I dug into it, the clearer it became that the debugging stack in VS Code is a different world. VS Code speaks the Debug Adapter Protocol, or DAP. It expects debugger extensions to implement that protocol and sit between the editor and the actual debugger engine.

That part is good. DAP is a clean idea.

The frustrating bit was this: the specific native Windows remote-debugging flow I wanted was not available through a supported public route in VS Code. The Visual Studio native debugger stack is not something you can just plug into from your own VS Code extension and say, "Thanks, I will take remote debugging from here." And the VS Code side does not magically inherit Visual Studio's remote debugging capabilities just because both products come from Microsoft.

So after spending time exploring options, the conclusion was simple:

There was no supported way to get the workflow I wanted with the existing pieces.

Building It Anyway

Once I accepted that I would not be wiring together existing public APIs, the problem changed shape.

The question was no longer, "How do I enable remote debugging in VS Code?"

It became:

"What debugger engine can I control myself, and how do I make VS Code talk to it properly?"

That is where WinDbg entered the story.

WinDbg already knows how to do the important parts. User-mode debugging. Remote debugging. Kernel debugging. Crash dump analysis. It is a serious tool with decades of capability behind it.

But again, my tool of choice did not give me the VS Code experience I wanted out of the box.

So the next step was clear:

Build a debugger adapter for WinDbg.

Learning DAP

If you want to integrate a debugger with VS Code, DAP is the contract. Once I sat down and read it properly, a lot of things clicked.

The official home for it is the Debug Adapter Protocol website, and that site is worth bookmarking because it has both the overview and the actual specification. At the time I was working through this, the important mental model was simple: VS Code and the adapter exchange JSON messages with a very predictable shape, and the protocol defines what those messages are supposed to mean.

The protocol is straightforward. VS Code sends requests like initialize, launch, attach, setBreakpoints, stackTrace, variables, continue, next, and so on, and your adapter answers them while emitting events like initialized, stopped, continued, and terminated.

That sounds simple enough until you remember that a debugger is mostly state, timing, and edge cases.

Still, the protocol gave me exactly what I needed: a structured way to make VS Code think in terms of debugging, while I figured out how to translate that into WinDbg behavior.

This was the moment where the project stopped being a helper extension and became a real debugger adapter.

To make that a bit more concrete, a minimal launch payload for the current POC looks roughly like this:

The adapter currently points at the debugging engine directly, so the windbg setting names the WinDbg stack even though the configured path is dbgeng.dll rather than windbg.exe.

{
	"type": "dapwdbg",
	"request": "launch",
	"name": "Launch through WinDbg",
	"windbg": "C:/Program Files (x86)/Windows Kits/10/Debuggers/x64/dbgeng.dll",
	"program": "${workspaceFolder}/build/Debug/testapp.exe",
	"stopAtEntry": true
}

That stopAtEntry flag is a small but useful quality-of-life feature. I added it because it is a familiar debugger option and useful to have. By default it is false, so the adapter continues after configurationDone. If you set it to true, VS Code stays paused at entry and waits for the next command.

And on the wire, the messages are simple, which is exactly what you want from a protocol. A stop event coming back from the adapter looks roughly like this:

{
	"seq": 17,
	"type": "event",
	"event": "stopped",
	"body": {
		"reason": "entry",
		"description": "Paused at process entry.",
		"threadId": 1,
		"allThreadsStopped": true
	}
}

That might not look exciting, but it is the important part: once VS Code receives something in that shape at the right time, it knows how to show the stack, scopes, variables, and stepping UI around it.

Step 1: Parse the Schemas Instead of Hand-Writing Everything

One thing became obvious very quickly: I did not want to manually model the entire protocol by hand in C#.

That is the kind of task that feels fine for the first ten message types and becomes a waste of time by the next fifty.

DAP is defined by schemas. Machines should read schemas. Machines should generate code. Humans should not write all of that by hand.

So one of the first pieces I built was a small toolchain around the protocol definitions.

The idea was straightforward:

Parse the protocol schemas
Convert them into C# types
Use generated models for requests, responses, events, and payloads
Stop wasting time on repetitive plumbing

This bought me two things immediately:

Better consistency with the protocol
Faster iteration whenever I needed to expand coverage

It also reduced a whole category of annoying bugs where hand-written DTOs silently drift away from the spec.

That generator phase was not glamorous, but it kept paying off. Every time I added another request handler later, I was very happy not to be hand-authoring another stack of protocol classes.

The nice part is that the generated code stays very literal. For example, the generated LaunchRequest model is basically just a strongly typed wrapper around the DAP shape, with Command = "launch" baked in and a typed Arguments property. A generated event model like StoppedEvent then points at a generated StoppedEventBody class with fields such as Reason, Description, ThreadId, and AllThreadsStopped.

That is exactly the level of abstraction I wanted. The protocol layer should be boring and explicit so the interesting work can happen one layer above it.

Step 2: A Python Generator That Produces C#

Yes, the adapter is in C#.

Yes, I used Python to generate part of it.

That combination made sense for the job. Python is still one of the fastest ways to build a transformation tool, especially when the task is basically: read structured input, normalize it, and generate source code.

So I built a Python tool that parsed the protocol definitions and generated the corresponding C# code.

That generator handled the boring but important parts:

Request and response classes
Event payloads
Shared protocol types
Optional fields and enum-like shapes
Enough structure to keep serialization predictable

This turned out to be one of the highest leverage steps in the whole project. Instead of spending my time on protocol plumbing, I could focus on the parts that actually matter: session management, command execution, state transitions, and debugger behavior.

In other words, I automated the boring part so I could focus on the interesting part.

Step 3: Wrap WinDbg Through dbgeng

Once the protocol layer was under control, the next question was how to talk to the debugger engine itself.

For that I went with dbgeng, the Windows debugging engine behind the debugger family. That is where the real power is. It is also where some of the complexity is.

On the package side, the current codebase still reflects some iteration. The wrapper layer currently leans on the public DbgEng interop exposed through the ClrMD packages Microsoft.Diagnostics.Runtime and Microsoft.Diagnostics.Runtime.Utilities. Separately, the broader adapter codebase also references Microsoft.Debugging.Platform.DbgEng and Microsoft.Debugging.Platform.DbgX, which are part of the newer Microsoft debugging platform stack. That split is real in the code today, but I do not want to pretend it is already the final architecture.

In the wrapper itself, the core interfaces in use right now are IDebugClient, IDebugControl, IDebugSymbols, and IDebugSystemObjects. For callbacks, I register IDebugEventCallbacks and IDebugOutputCallbacks. That gives me the essential surface area I need to launch or attach, execute commands, inspect symbols, enumerate threads, and react to breakpoints, exceptions, exits, and debugger output.

This wrapper layer became the core of the adapter. Its job was to expose the debugger in a way that fit the expectations of DAP rather than the expectations of a human typing commands into a debugger console.

That means translating concepts like:

Launching or attaching to a target
Resuming and breaking execution
Enumerating threads
Building stack traces
Reading locals and variables
Handling modules and symbols
Surfacing exceptions, exits, and other stop reasons

If you have ever worked with debugger APIs, you know they do not hide much complexity. You need to be explicit. You need to think about ownership, state, timing, callbacks, and edge cases that often show up only once things are already going wrong.

One small example was line stepping. I had already enabled source line support and saw source locations show up, so for a moment I thought step over was working.

It did not.

What I had actually proven was that WinDbg could show me line information. That is not the same thing as telling it to do source-based stepping. I had forgotten to enable that part as well. The fix was one extra command:

public void EnableSourceLineSupport()
{
	ThrowIfDisposed();
	ExecuteDebuggerCommand(".lines -e", "Could not enable source line support");
	ExecuteDebuggerCommand("l+t", "Could not enable source-based stepping");
}

That was a very debugger-adapter kind of bug. Everything looked correct for just long enough to be misleading.

Step 4: Implement the Real Requests and Iterate

With the generated protocol types on one side and the WinDbg wrapper on the other, I could finally work on the adapter loop itself.

At this point, the adapter was useful for actual debugging.

I began with the core requests: initialize, launch, attach, setBreakpoints, configurationDone, threads, stackTrace, scopes, variables, continue, pause, next, stepIn, stepOut, disconnect, ...

On paper that looks like a clean checklist. In reality, each of those requests is a conversation between at least three parties:

VS Code and its expectations
The adapter and its internal state machine
The debugger engine and its current state

So the implementation loop looked roughly like this:

Add one request
Run it in VS Code
Watch it fail in an interesting way
Fix the translation layer
Hit the next state mismatch
Repeat until the experience works the way it should

This is also where you learn that "technically works" and "feels right to use" are not the same thing.

It is not enough to answer the request. You have to answer it in the right order, at the right time, and with enough fidelity that the editor can build a coherent UI around it.

That was one of the more interesting parts of the project.

Here is a tiny slice of what that translation layer looks like today. After launch, the adapter records whether it should remain paused at entry or continue once VS Code finishes sending its setup messages:

_launchAwaitingConfigurationDone = true;
_launchStopAtEntry = DapArgumentReader.TryGetBoolean(arguments, "stopAtEntry")
	?? DapArgumentReader.TryGetBoolean(arguments, "stopOnEntry")
	?? false;

This is the kind of code that looks harmless until you realize it decides whether the whole session feels smooth or broken.

When It Worked

At some point the pieces clicked together.

I could launch a debugging session from VS Code, talk to WinDbg through the adapter, and use the editor as if this had always been a normal supported workflow.

It also stopped being just about the original VM service scenario. Because the adapter sits on top of WinDbg, it opened the door to more than the first use case:

Local launch and local attach already work in the adapter
Dump-file attach is wired in
Remote attach and kernel scenarios are the next serious end-to-end targets
Crash dump debugging is now a realistic extension of the same architecture

That was the point where the project started to feel solid.

Why This Was Fun

This was fun for the same reason good tooling work is always fun: it changes how you work.

You remove friction once, then benefit from it every day after that. And along the way, you learn where the real product boundaries are. Visual Studio and VS Code may look adjacent from the outside, but their debugging plumbing is very different. Once that became clear, the path forward became clear too.

What I Learned

This project taught me a few things very clearly:

If a workflow matters enough, it is often worth productizing it for yourself
DAP is a really good abstraction for debugger integration
Code generation is the right answer when a protocol brings lots of repetitive structure
Debugger adapters are mostly about state, timing, and translation
WinDbg becomes much more approachable when you put a good UX in front of it

Also: if you think you fixed stepping, make sure you actually fixed it and did not just make the debugger show line numbers.

Most importantly, I was reminded again that some of the best side projects start as practical attempts to make tomorrow less annoying than today.

Summary

I only wanted a better remote debugging workflow for a service running in a VM.

That turned into DAP, schema parsing, code generation, dbgeng, and a long series of state-machine bugs.

The result so far is a working first proof of concept: a WinDbg-backed debugger adapter for Visual Studio Code with local launch, local attach, dump-file attach, stack traces, scopes, variables, breakpoints, and step commands working well enough to prove the architecture.

That matters because it means I finally have a base I can build on. I have not implemented remote debugging or kernel debugging yet, but I now feel ready to take a real shot at both without getting lost in the basics again.

Next Steps

The next step is to use this base for the work I actually set out to do:

Harden the current adapter and clean up rough edges in the state machine
Start implementing the actual remote debugging flow for the VM scenario
Take a first real implementation shot at kernel debugging too
Keep the scope under control so the project does not drift again like it did at the start
Open source the project once the foundation is stable enough
Keep turning WinDbg power into something that feels normal inside VS Code

And yes, this all started with "I just want to remote debug a service on a VM."

That is usually how the best tools start.

The Passenger Seat Developer

2025-10-27T00:00:00+00:00

The Great Prototype Experiment

Here's what nobody tells you about AI-assisted rapid prototyping: After six months and nearly 100 projects, I had to face an uncomfortable truth.

Every prototype feels like success. But is it really?

Why, You Ask?

Picture this: Me, armed with Claude, spinning up project after project like I'm some kind of coding machine gun. A productivity suite here, a file manager there, throw in some web scrapers, automation tools, data processors - you name it, I've probably built a prototype of it in the past six months.

Nearly 100 projects. The dopamine hits were insane. Every idea that popped into my head, no matter how half-baked, could become a working prototype in hours instead of weeks. The velocity felt otherworldly.

The result took me too long to acknowledge: out of nearly 100 prototypes, only one reached production.

One. Literally. One.

That project? mcp-windbg. And guess what made it special? It's the only one where I spent those classic, grinding hours sitting there, actually understanding every line of code, debugging the edge cases, and wrestling with the gnarly implementation details.

The Dopamine Factory

Let me be real with you about what those early days felt like. I'd wake up with some random idea - "What if I built a tool that automatically organizes screenshots by content?" or "I need a better way to manage my development environments" - and by lunch, I'd have a working prototype.

Six months ago, I was writing about vibe coding like I'd discovered fire. The euphoria was real - watching AI refactor entire codebases, generate complex implementations, solve architectural problems in seconds. I was living in that perfect state where "the barrier between thinking and implementing just got so much thinner."

Me: Build me a screenshot organizer that uses OCR to categorize images
Claude: *Generates Python app with OCR integration, file management, GUI*
Me: This actually works perfectly!

The rush was incredible. Idea to implementation in hours. No tedious boilerplate. No debugging mysterious dependency issues. No wrestling with documentation. Just pure, frictionless creation.

I felt like a goddamn wizard. Every prototype that worked felt like validation that I'd cracked some secret code of productivity. Friends would ask what I was working on, and I'd rattle off a dozen projects like I was running a software factory.

That euphoric beginning? It was exactly six months ago. Time has a funny way of providing perspective.

The Reality Check: Why Nothing Shipped

After several months, my project folder had grown to nearly 100 directories, but I still had not shipped anything.

Why? Because prototypes aren't products.

Every time I'd come back to one of these AI-generated prototypes to actually finish it - to handle edge cases, add proper error handling, write tests, or make it production-ready - I'd hit the same wall: I had no clue how the thing actually worked.

The code looked familiar. The structure made sense at first glance. But when it came time to:

Debug why it crashed with certain file types
Add a feature that required understanding the data flow
Optimize performance bottlenecks
Handle edge cases the AI hadn't considered

I was lost. Completely, utterly lost.

The One That Made It: mcp-windbg

So why did mcp-windbg succeed when 99 others failed? It wasn't because I spent months on it - it was a small weekend project. But I approached it differently.

I started by vibe-coding with Claude, just like the other prototypes. Got the basic structure working, had it generating and parsing WinDBG commands. But then - and this is the crucial difference - I actually went back and reviewed what the AI had built. Debugged the edge cases myself. Traced through the subprocess communication to understand how it really worked.

When pytest failures popped up, I didn't just ask Claude to fix them. I sat there and figured out why they were failing. When the CDB interaction got weird with certain commands, I debugged it manually until I understood the communication protocol.

The result? A weekend project that actually solved a real problem in my daily work. Something I could confidently maintain, extend, and explain to others.

I owned the code because I'd taken the time to understand what Claude had built.

The Brutal Truth About AI-Generated Prototypes

Those 99 failed projects weren't failures because the code was bad. Most of them actually worked pretty well for their basic use cases. They failed because I'd delegated understanding to AI instead of using it as a tool to support my understanding.

Here is what was happening:

Week 1: "Holy shit, look at this amazing prototype!"
Week 2: "I should probably clean this up and ship it"
Week 3: "Hmm, there are some edge cases I need to handle"
Week 4: "Why is this crashing? Let me ask Claude to fix it"
Week 5: "The fix broke something else. This is getting messy"
Week 6: "Maybe I'll just start a new project instead..."

Sound familiar? This cycle repeated so consistently I could set my calendar by it.

The Sitting-There Hours: Why They Matter

You know those classic hours every developer has experienced? The ones where you're just sitting there, staring at code, trying to figure out why something isn't working the way you expect? Those moments when you're debugging line by line, tracing execution paths, and slowly building up a mental model of how everything fits together?

Those hours aren't wasted time. They're investment time.

When you skip those hours - when you let AI generate the solution and just accept it - you never build that intimate knowledge of your own system. You become a tourist in your own codebase.

With mcp-windbg, I didn't spend weeks wrestling with it - it was just a weekend project. But during that weekend, when I hit issues with subprocess communication or weird CDB behavior, I actually debugged them myself instead of immediately asking Claude for fixes. I took the time to understand why certain commands failed and how the debugging session management worked.

That weekend of actually understanding what I was building made the difference between prototype #99 and shipped product #1.

The False Productivity Trap

I felt productive while building those 99 prototypes. Each working demo felt like progress, and my GitHub activity supported that impression. It did not mean I was finishing useful products.

But productivity isn't about how much code you generate. It's about how much value you ship. And by that metric, I had a 1% success rate.

The problem was not AI itself, but how I used it. I treated it as a replacement for understanding instead of a debugger or knowledge base that could help me learn faster.

How I Use AI Now

I still use AI regularly, but now I treat it like any other development tool.

AI as a knowledge base: "How does subprocess communication work in Python?" "What are the edge cases for file parsing?" "Show me different approaches to error handling."
AI as a debugging partner: "Here's my stack trace, what could be causing this?" "This function isn't behaving as expected, help me trace through the logic."
AI for the boring repetitive stuff: Boilerplate code, test scaffolding, documentation generation, refactoring patterns I've done a million times.
AI as a code reviewer: "Does this implementation handle edge cases properly?" "Are there performance issues with this approach?"

The key difference: I use AI to accelerate my understanding, not replace it.

For anything I might ship, the rule is simple: If I can't explain how the core functionality works without looking at the code, I don't ship it. AI can help me get there faster, but it can't get there for me.

This isn't about being a purist or rejecting AI assistance - it's about maintaining professional competence and shipping software you can actually support.

What Success Actually Looks Like

After six months of this experiment, here's what I've learned about successful AI-assisted development:

Delegate the repetitive stuff: Boilerplate generation, test scaffolding, documentation, refactoring patterns you've done before.
Use it as a knowledge multiplier: Research APIs, explore different approaches, get explanations of complex concepts, debug tricky issues.
Keep the understanding: Architecture decisions, core business logic, data flow design, system integration points.
Invest in the sitting-there hours: For anything you plan to ship, spend the time to truly understand how it works.

AI is similar to a good debugger or profiler: it can make you more effective, but it does not replace understanding the system you are building.

The Uncomfortable Question

Here's the question that keeps me up at night: How many developers are building careers on AI-generated code they don't understand?

This is also a matter of professional responsibility. If you own a piece of code, you should be able to explain, modify, and debug it, especially when a production issue occurs and the AI assistant is unavailable.

I don't have a good answer to that question. I just know I don't want to be that kind of developer.

Summary

After six months and nearly 100 AI-assisted prototypes, only mcp-windbg shipped. The difference was that I used AI to speed up my learning instead of asking it to replace that learning.

Remember that uncomfortable truth from the beginning? Every prototype feels like success, but success is measured by shipping, not building. The dopamine hits from rapid prototyping are real, but they're not the same as the satisfaction of maintaining code you actually understand.

The lesson isn't to use less AI. The lesson is to use it better.

AI is like having a brilliant research assistant, debugger, and code reviewer all rolled into one. Use it to explore ideas faster, understand concepts deeper, and eliminate the boring repetitive work that burns you out. But don't delegate the understanding itself.

Next Steps

If this resonates with you, here's what I'd suggest doing right now:

Audit your current projects: Look at your recent work. Can you explain how the core functionality works without looking at the code? If not, spend some time diving into those systems.
Set a new rule: For anything you plan to ship, implement the "explain it without looking" test. If you can't walk someone through how it works from memory, you're not ready to ship.
Change how you prompt: Instead of "Build me X," try "Help me understand how to build X" or "What are the key concepts I need to know for X?"
Embrace the sitting-there hours: When you hit a bug or weird behavior, resist the urge to immediately ask AI for a fix. Spend 15-20 minutes trying to understand it yourself first.

Someone still needs to own the code. AI can help you move faster, but it cannot take that responsibility from you.

How to extend GitHub Copilot with prompt files

2025-09-10T00:00:00+00:00

Why, You Ask?

Remember when I went absolutely euphoric about vibe coding? Well, that honeymoon phase taught me one crucial lesson: context matters, and you really need to spend time writing good prompts.

At first, I was frantically scribbling prompts in my notes app like some kind of digital hoarder. Then I graduated to GitHub Copilot instruction files, adding rules like "when asked for review, do this and that." But constantly switching between apps and copy-pasting prompts? I'm tired of it.

GitHub Copilot's prompt files solve this by keeping reusable instructions in the repository.

Using `.prompt.md` Files

Prompt files turn your best prompts into reusable slash commands. VS Code gives you two flavors:

Workspace prompts (.github/prompts/): Travel with your repository, perfect for team-shared helpers
User prompts: Stored in your VS Code profile, available everywhere for personal tools

Both become accessible as /my-prompt directly in VS Code chat. Instead of hunting through notes for that brilliant review prompt, you just type /svnscha-blog-review and boom, there it is.

Note: Prompt files are currently in public preview and may change in future releases.

Real-World Example: Blog Review Prompt

Let me show you what this looks like in practice. I use project prefixes for workspace prompts and /my-... for personal ones.

For this blog, I created /svnscha-blog-review - a specialized prompt that understands my writing style:

---
mode: "agent"
description: "Review blog posts for svnscha.github.io with focus on style, grammar, and technical accuracy"
---

# Blog Post Review for svnscha.github.io

You are an expert editor reviewing a blog post for svnscha's technical blog.

Focus on:

## Writing Style & Tone

- Consider using "Why, You Ask?" openings when it makes sense for the topic (not mandatory for all posts)
- Keep the direct, slightly sarcastic but helpful voice
- Ensure smooth transitions between sections
- End posts with a short summary or practical next steps when they add value

## Technical Accuracy

- Verify code examples are correct and practical
- Check that technical explanations are clear and accurate
- Ensure all file paths and commands are properly formatted

## Grammar & Spelling

- Fix any grammatical errors or typos
- Improve sentence structure where needed
- Maintain consistency in technical terminology

## Content Structure

- Ensure headings flow logically
- Verify examples support the main points
- Suggest a brief summary or actionable next steps when appropriate
- Check that the conclusion ties back to the opening

Provide specific, actionable feedback that maintains the author's voice while improving clarity and correctness.

This becomes available as /svnscha-blog-review in VS Code, giving me instant access to a specialized editor that knows my style.

Smart Naming & Location Strategy

The naming convention is simple: project prefixes for workspace prompts, /my-... for personal ones. So /svnscha-blog-review is specific to this blog, while /my-commit works everywhere.

Choose your location based on scope:

Workspace prompts: Team-shared, project-specific helpers
User prompts: Personal tools that follow you across all projects

Dynamic Prompts with Variables

Make your prompts adapt to context with VS Code variables:

# Code Review Prompt

Review the following code in ${file}:

${selection}

Focus on:
- Security vulnerabilities in ${fileBasename}
- Performance implications 
- Code style consistency with ${workspaceFolderBasename} standards

The most useful variables include:

Workspace: ${workspaceFolder}, ${workspaceFolderBasename}
File context: ${file}, ${fileBasename}, ${fileDirname}
Selection: ${selection}, ${selectedText}

For the full list of available variables and advanced features, check out the VS Code prompt files documentation.

Setting Up Your Prompt Arsenal

Getting started is simple:

Workspace Prompts

Create .github/prompts/ in your repository
Add your .prompt.md files
Commit and push - your team now has access

User Prompts

Open Command Palette (Ctrl+Shift+P)
Run "Chat: New Prompt File"
Choose "User profile" for location
Author and save your prompt

Both methods make prompts available with /prompt-name in GitHub Copilot chat. Workspace prompts travel with your repository, while user prompts sync across devices with Settings Sync.

For examples and community contributions, check out the Awesome GitHub Copilot prompts collection.

Summary

Prompt files transform good prompting from an exclusive skill into a shared superpower. Your team gets expert-level guidance, your hotfix deployments get proper review, and your collective wisdom becomes instantly accessible with slash commands.

Next Steps

Start small - Convert your three most-used prompts to .prompt.md files
Choose scope wisely - Workspace prompts for teams, user prompts for personal tools
Use variables - Make prompts dynamic with ${selection}, ${file}, and ${input:variableName}
Follow naming conventions - Project prefixes for workspace, /my-... for user prompts
Explore the community - Check out Awesome GitHub Copilot prompts
Read the docs - VS Code prompt files documentation has the latest features

The main benefit is simple: useful instructions live with the project and can be reused without copying them into every chat.

Vibe Coding is So Damn Real

2025-04-27T00:00:00+00:00

Why, You Ask?

Ever had that moment when your coding flow is so perfect it feels like you and your tools are in some kind of cosmic alignment? That's vibe coding. It's when the friction between thought and implementation practically disappears. And let me tell you, with GitHub Copilot and VS Code, this isn't just a fleeting sensation-it's a consistent reality.

I'm tired of writing about theoretical capabilities. Let me show you something concrete.

A Childhood Dream Come True

Let me share something personal: since I first started coding, I've had this recurring dream. A dream where I could simply talk to my computer, tell it what I want in plain language, and watch as it translates my intentions into working code. No syntax gymnastics. No hunting for semicolons. Just pure, frictionless creation.

"Hey computer, refactor this module to use dependency injection instead of globals."
"Computer, optimize this database query, it's running too slow."
"Add translation support to all user-facing strings in this module."

For decades, this remained firmly in the realm of science fiction-something for Star Trek episodes where they casually ask the computer to "reconfigure the deflector dish" and it just... happens.

DAMN, we're just there now. Not in some distant future, not as a tech demo, but as a practical, everyday reality in my development workflow.

Real-World Context: Nofidoc

A little context: In my free time, I've been pushing the boundaries of what's possible with AI-assisted coding-well beyond just casual experiments. While I also use these workflows at work, Nofidoc has become my personal playground for exploring how far I can take this technology. It's a space where I can try things that aren't always ready for the spotlight, but the results have been too compelling not to share (even if I'm keeping things a bit low-key for now).

The codebase uses Qt for the UI components, has a wizard-based document import flow, and handles various document formats with a focus on PDFs. It's exactly the kind of mid-sized C++ project where refactoring used to be tedious and error-prone.

The Perfect Pairing

VS Code with GitHub Copilot doesn't just assist your coding-it transforms it. No more wasting precious brain cycles on trivial tasks. No more tedious refactoring operations that make you question your career choices at 2 AM.

I recently needed to refactor the document import workflow to remove direct database dependencies in the wizard component. Why having that in the first place? Well, getting something proof-of-concept-ish is the answer. Anyways, this is a classic case of improving architecture by decoupling components, but it typically requires careful changes across multiple files and understanding the entire call hierarchy.

See The Entire Workflow In Action

I've recorded a full ~6-minute video showing the entire refactoring process from start to finish. You'll see me:

Prompt Copilot with my refactoring requirements
Watch the initial code changes being proposed
Hit compilation errors (because real-world code is messy!)
Provide additional guidance to Copilot
Get a complete, working solution

Your browser does not support the video tag.

What's remarkable here is not just that Copilot could make the changes, but how the entire interaction feels like working with a senior developer who deeply understands your codebase.

The Real Example: DocumentImportWizard Refactoring

Here's a snapshot of what happened in the video. I needed to update the DatabaseWidget class to use the new API of our DocumentImportWizard that we had refactored to remove direct database dependencies.

Copilot analyzed the code and came up with this solution:

// Before refactoring, direct database dependency:
void DatabaseWidget::onDocumentImportWizard()
{
    auto importWizard = new DocumentImportWizard(_database, this);
    importWizard->exec();
}

// After refactoring, using callback approach:
void DatabaseWidget::onDocumentImportWizard()
{
    auto importWizard = new DocumentImportWizard(this);
    importWizard->setGetDocumentTypesCallback([this]() {
        if (!_database)
            return QList<DocumentType>();
            
        auto docTypeService = _database->getDocumentTypeService();
        if (!docTypeService)
            return QList<DocumentType>();
            
        return docTypeService->getDocumentTypes();
    });
    importWizard->exec();
}

Copilot explained its reasoning:

"I've updated the onDocumentImportWizard() method in DatabaseWidget to use the new refactored API of our DocumentImportWizard class. The key changes were:

1. Removed passing the _database parameter directly to the DocumentImportWizard constructor 2. Added a call to setGetDocumentTypesCallback() with a lambda that:

Checks if _database is valid

Gets the document type service from the database

Returns the document types list from the service

Returns an empty list if any step fails

This completes the refactoring work by updating all the calling code to use the new API. The change maintains the same functionality but with a cleaner design that removes direct dependencies on the database pointer.

The implementation follows modern C++ practices by using a lambda to encapsulate the specific functionality needed (getting document types) while keeping the rest of the database access logic out of the wizard class. This makes the code more maintainable and easier to test."

This is exactly the kind of architectural improvement that typically takes deep understanding of both the codebase and software design principles. Yet Copilot produced it in seconds.

The Key Lesson: Human-AI Collaboration

My main takeaway is simple: AI tools work best when you bring your own domain knowledge.

Just before that, I was debugging a frustrating issue with field registration in that document import wizard. The fields weren't passing values between pages correctly. I asked Copilot to help fix the bug and it initially proposed an overly complex workaround that would have been a maintenance nightmare.

So I gave it a hint:

"I think there's an issue with the registerField calls for 'importSuccessCount' and 'importErrorCount'. The implementation doesn't specify the property name correctly."

And just like that, it had an "aha!" moment. It immediately identified the real issue:

// Before (buggy implementation):
registerField("importSuccessCount", this);

// After (Copilot's correct fix):
registerField("importSuccessCount", this, "importSuccessCount");

This simple fix resolved the entire issue. The fix works because it properly uses the Qt property system (third parameter) as the remaining code and pages expected, whereas Copilot's initial workaround was mega ugly - setting properties directly with setProperty() calls. With just a small hint about the actual problem, we were back on track. This perfectly illustrates why domain expertise remains critical - AI tools can suggest solutions, but knowing which ones make sense in your framework requires human judgment.

Sometimes AI tools need a gentle nudge in the right direction, and then they're off to the races again.

Not Always Perfect Magic

Let me be real with you - it's not all sunshine and rainbows. AI assistance sometimes misses the mark, and when it does, you need to steer it in the right direction. But I've found that:

The initial attempt is usually close
AI is exceptionally good at understanding feedback
With the right hints, it can quickly recover and find the optimal solution

The collaboration workflow is what makes all the difference. Instead of wrestling with a tool, it feels like having a junior developer who's eager to learn and quick to adapt.

What I Learned

This isn't just about saving time (though I saved HOURS). It's about changing how we think about coding. When you can express your intent in natural language and have it accurately translated into code changes, you're no longer programming computers-you're conversing with them.

The barrier between thinking and implementing just got so much thinner.

Getting This Setup Yourself

Want this superpower? Here's what you need:

VS Code
GitHub Copilot
A clear understanding of your codebase - To craft effective prompts

That's it! No complex configuration, no elaborate plugin chains.

Oh, which model? Right now I am using Claude 3.7 - it's so good.

Where This Is Going

You know that saying about technology and magic? This is it. We're witnessing the early days of a transformation in how software gets built. The tools are evolving to understand not just the syntax of our code, but the intent behind it.

Could I have written a complex bash script to do some of this refactoring? Maybe. Could I have used search-and-replace with regex? Probably. Would either approach have understood the semantic meaning of my code well enough to know which strings need translation? Absolutely not.

Summary

Vibe coding isn't just some feel-good developer term. It's that perfect state where you and your tools are in sync, where expressing your intent feels natural and immediate. With GitHub Copilot and VS Code, I'm experiencing this daily while building Nofidoc.

If you're still doing manual refactoring in 2025, you're not just missing out on productivity-you're missing out on the pure joy of frictionless development.

Try it. Feel it. Vibe code.

A Git feature I should've met sooner!

2025-04-04T00:00:00+00:00

Why, You Ask?

Because I thought I knew Git. Like really. Branches? Merged. Rebased. Cherry-picked. Heck, I've even force-pushed into production (don't judge me). I've danced the git stash tango more times than I care to admit, and I've rage-quit after realizing I checked out the wrong branch with uncommitted changes.

But then-then-I discovered git worktree.

And everything changed.

The Problem With the "Normal" Way™

Let's say you're working on a feature. You're knee-deep in uncommitted changes, and suddenly you need to switch to another branch to hotfix or review something. What do you do?

git stash
git checkout other-branch
Try to remember what you were doing in your branch later.
Forget what you stashed and why.
Cry

This is the standard Git workflow we all just kind of accept. It's chaotic good at best.

Enter: `git worktree`

What if I told you... you could just check out multiple branches at the same time? Each in its own separate folder. No stash. No backflips. No existential dread.

git worktree is a built-in Git feature that lets you:

Check out multiple branches at once
Work on each one in its own directory
Keep your mental state and filesystem intact

Examples

Create a new worktree for a feature branch

git worktree add ../feature-x origin/feature-x

This checks out the feature-x branch (fetched from origin) into a new directory ../feature-x.

If it's a new feature you start locally, do this:

git worktree add ../feature-x -b feature-x

This creates a new local branch feature-x from your current HEAD (usually main) and checks it out into ../feature-x.

Wow. 🥳 No more "wait lemme stash real quick."

Now you can commit your fix, push it, and go back to your mess later. Like a civilized developer.

List all worktrees

git worktree list

Because you will forget what you spun up after the third coffee.

What's the Catch?

Honestly? Not much. A few things to keep in mind:

You can't check out the same branch twice. Git will yell at you. That's fair.

Deleting a worktree is easy: just git worktree remove ../feature-x (the directory) and that's it.

Why You Need This in Your Life

If you're working on multiple features, doing code reviews locally, fixing stuff mid-feature, or just trying to keep your brain from melting-git worktree is the gift you didn't know Git included.

No more stash juggling.
No more "which terminal had which branch again?"
No more "accidentally committed to main" horror stories.

Just clean, parallel workspaces from a single clone.

Use it. Love it. Regret not learning it sooner. I know I did.

PowerShell with oh-my-posh

2024-11-16T00:00:00+00:00

Why, You Ask?

I use PowerShell on Fedora because I like having the same shell across workstations, VMs, dev containers, and Windows. oh-my-posh gives that shell a useful and consistent prompt.

Here is how I set it up with Cascadia Code Nerd Font and KDE Konsole.

Oh and guess what: This all works on Windows using Windows Terminal, too.

Step 1: Install oh-my-posh

First, we need to install oh-my-posh. It's as easy as running this command:

curl -s https://ohmyposh.dev/install.sh | bash

This script downloads the latest version of oh-my-posh and installs it. Feel free to inspect the script if you're cautious. If you're running Windows the installation is slightly different, but I guess you figure this out.

Step 2: Install Cascadia Code Nerd Font

oh-my-posh relies on a Nerd Font for its icons and styling. I chose Cascadia Code Nerd Mono because it's clean and works beautifully across different environments.

oh-my-posh font install

Set the Font in KDE Konsole:

Open Konsole.
Go to Settings > Edit Current Profile > Appearance.
Click Edit Font and select Cascadia Code Nerd Mono.

Set the Font in Windows Terminal:

Open Settings
Navigate to Font and choose Cascadia Code Nerd Mono.

Step 3: Configure PowerShell

To load oh-my-posh in PowerShell, edit your $PROFILE file.

code $PROFILE

Add the following lines to load oh-my-posh with your configuration:

oh-my-posh init pwsh --config "/path/to/oh-my-posh.json" | Invoke-Expression
clear

This initializes oh-my-posh with your chosen theme and clears the screen for a clean start.

Step 4: My oh-my-posh configuration

Here's my oh-my-posh config file. It's simple but does the job perfectly:

{
  "$schema": "https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/schema.json",
  "blocks": [
    {
      "type": "prompt",
      "alignment": "left",
      "segments": [
        {
          "properties": {
            "cache_duration": "none",
            "style": "full"
          },
          "template": "{{ .Path }} ",
          "foreground": "#77E4F7",
          "type": "path",
          "style": "plain"
        },
        {
          "properties": {
            "cache_duration": "none"
          },
          "template": "{{ .HEAD }} ",
          "foreground": "#FFE700",
          "type": "git",
          "style": "plain"
        },
        {
          "properties": {
            "cache_duration": "none"
          },
          "template": "$ ",
          "foreground": "#43D426",
          "type": "text",
          "style": "plain"
        }
      ]
    }
  ],
  "version": 3
}

Path Segment: Displays the current directory in a bright cyan.
Git Segment: Shows the current Git branch in yellow, if applicable.
Prompt Character: Displays a green $, keeping it clean and minimal.

Step 5: (optional) Create a New Profile for PowerShell in Konsole

Let's set up a dedicated profile for PowerShell in Konsole:

Duplicate an Existing Profile:

In Konsole, go to Settings > Manage Profiles.
Select your default profile and click Duplicate.

Configure the PowerShell Profile:

Rename it to PowerShell.
Set the command to pwsh.
Under Appearance, set the font to Cascadia Code Nerd Mono.
Save your changes.
Set it as default (optional)

Summary

With oh-my-posh, Cascadia Code Nerd Font, and a dedicated profile in KDE Konsole, my PowerShell setup is consistent, stylish, and super effective. Whether I'm on Fedora, a VM, or a devcontainer, my terminal always feels like home.

If you're a PowerShell fan like me, give this setup a try. Trust me, your terminal (and your productivity) will thank you.

Simplify SSH

2024-10-03T00:00:00+00:00

Why, You Ask?

I was tired of entering my SSH key passphrase every time I connected to a server. The setup below lets ssh-agent remember it for the current terminal session and also keeps host settings in one place.

It's time-consuming and frustrating. I'm tired of it.

Getting Started

So, you've got your shiny new SSH key and every time you want to connect to a server, you're greeted with that ever-familiar password prompt. Sure, typing your SSH key passphrase every time is good for security, but, come on - who wants to do that? I mean, I don't know about you, but I've got enough passwords to remember without constantly dealing with this nonsense.

Let's save ourselves some time and effort by getting the SSH agent to remember our keys for us. That way, you can just run your commands like the seasoned developer you are without worrying about the whole "password entering" thing every single time.

Step 1: Start the SSH Agent

First things first - let's get the SSH agent up and running. It's like your personal SSH butler, here to remember your key so you don't have to.

Open up your terminal and type:

eval $(ssh-agent -s)

Boom! Now the agent is running in the background, ready to hold your keys like the responsible little daemon it is.

Step 2: Add your key to the SSH Agent

Now that the agent is up, let's give it your key. You only need to do this once per session, and the agent will keep it ready for you.

ssh-add ~/.ssh/your_key

Replace your_key with the name of your private key file. Enter the passphrase once and ssh-agent will remember it for the rest of the terminal session.

Step 3: Configure your SSH setup to be even lazier (I mean efficient)

Okay, we've got the agent running and the key added, but we can take it one step further. Why not tell SSH exactly what key to use for which server, so you never have to worry about it picking the wrong one?

To do this, we're going to set up a ~/.ssh/config file. If you don't have this file yet, don't worry - it's as easy as creating it:

touch ~/.ssh/config

Now, crack open that file with your favorite text editor and set things up like this:

Host your-server-alias
    HostName your.server.com
    User your-username
    IdentityFile ~/.ssh/your_key
    IdentitiesOnly yes

Breaking it down

Host: You can use any alias here that makes sense to you. This is what you'll type when you want to connect to this server.
HostName: The actual domain or IP address of the server.
User: Your username on that server, so you do not have to specify it each time.
IdentityFile: The path to your SSH private key.
IdentitiesOnly yes: Tells SSH to use only this key, rather than trying every key it can find in the agent (which is how you avoid that annoying "user mismatch" issue).

Step 4: Create a wrapper script for SSH Agent control

Alright, you want control over when your SSH agent starts up - totally understandable! Instead of running the agent automatically on login (which might feel a bit too autonomous), we'll create a neat little wrapper script. You can trigger it whenever you feel like starting the agent and adding your SSH key for the session.

Here's how to set that up.

Create the wrapper script

Let's create a script that starts the SSH agent, adds your key, and gives you control over when it runs. We'll call this script init-ssh, and we'll stick it somewhere like /usr/local/bin so it's available from anywhere in your terminal.

Create the script: Open your terminal and create the init-ssh script:
```
sudo nano /usr/local/bin/init-ssh
```

Add the script content: Paste the following content into the file:

#!/bin/bash

# Start the SSH agent
eval $(ssh-agent -s)

# Add the key to the agent
ssh-add ~/.ssh/your_key

# Optional: Display agent status for peace of mind
ssh-add -l

Make the script executable: Give the script executable permissions:
```
sudo chmod +x /usr/local/bin/init-ssh
```

How to use the script

Whenever you want to start your SSH agent for a session, just run:

. init-ssh

This will start the agent, add your key, and show you a list of the keys currently loaded in the agent. You've got full control - start the agent when you want, stop it when you're done, and enjoy a password-free SSH experience for the duration of that session.

Optional: Stopping the SSH Agent

If you want to stop the SSH agent after you're done with it, you can either let it die when you close your terminal or manually kill it with:

eval $(ssh-agent -k)

That way, you get all the convenience of an SSH agent when you need it, without it running indefinitely in the background. You're now in complete control of your SSH setup, and you can keep things secure and efficient, exactly the way you like it.

Happy SSH'ing!

Blog Motivation

2024-02-10T00:00:00+00:00

Why, You Ask?

We all have those annoying little tasks that pop up a few times a year. They're too rare to make fixing them a big deal but happen just enough to be really annoying. Think about setting up a new laptop, sorting out files, refactor that NULL to nullptr or those updates that take forever. It eats up time and patience. I'm tired of it.

Changing Things Up

I started this blog not just to talk tech but to tackle these annoying moments head-on. My goal? To stop saying "it's not worth fixing" and start finding ways to make these tasks less of a headache. Even those things we do once in a blue moon? Yeah, I want to automate those too. And I'll share every step right here.

This blog is my playground and my megaphone. It's where I try out new ideas to make life easier and then shout out what works. Each post starts with my cheeky

"Why, You Ask?"

and always circles back to me spilling the beans on how I truly feel, which usually is

"I'm tired of it."

It's my unique approach, sprinkled with a dash of sarcasm, as I navigate through the mayhem, assuring you that behind every vent, there's a solid reason and, believe it or not, a solution waiting to be uncovered.

Making things easier is only part of it. I also want to share useful ideas, opinions, and the occasional rant. When I find a good way to avoid repetitive work, I'll write it down here so others can use it too.

Come Along for the Ride

If that sounds familiar, have a look around and share your own ideas. None of us should spend more time on repetitive work than necessary.

Welcome to my quest for a smoother, simpler tech life. Here's to less frustration and more time doing what we love. Let's kick those annoying tasks to the curb.

svnscha - productivity

Introducing Native Windows Debugging for VS Code: Kernel & Remote Debugging

Remember the Cliffhanger?

Get It Right Now

Four Ways to Debug - Two of Them Were Never Possible Before

Local: The Comfortable Starting Point

Attach: Already Running? Just Connect

Remote: My Favorite Part

Kernel: Yes, Really

How It Works

An Honest Word on Scope

Getting Started

Your Turn

Summary

P.S. - One More Thing About Those Videos

The Joy of Writing a Debugger Adapter for Visual Studio Code

Current State

Why

Removing Friction

VS Code Is Not Visual Studio

Building It Anyway

Learning DAP

Step 1: Parse the Schemas Instead of Hand-Writing Everything

Step 2: A Python Generator That Produces C#

Step 3: Wrap WinDbg Through dbgeng

Step 4: Implement the Real Requests and Iterate

When It Worked

Why This Was Fun

What I Learned

Summary

Next Steps

The Passenger Seat Developer

The Great Prototype Experiment

Why, You Ask?

The Dopamine Factory

The Reality Check: Why Nothing Shipped

The One That Made It: mcp-windbg

The Brutal Truth About AI-Generated Prototypes

The Sitting-There Hours: Why They Matter

The False Productivity Trap

How I Use AI Now

What Success Actually Looks Like

The Uncomfortable Question

Summary

Next Steps

How to extend GitHub Copilot with prompt files

Why, You Ask?

Using .prompt.md Files

Real-World Example: Blog Review Prompt

Smart Naming & Location Strategy

Dynamic Prompts with Variables

Setting Up Your Prompt Arsenal

Workspace Prompts

User Prompts

Summary

Next Steps

Vibe Coding is So Damn Real

Why, You Ask?

A Childhood Dream Come True

Real-World Context: Nofidoc

The Perfect Pairing

See The Entire Workflow In Action

The Real Example: DocumentImportWizard Refactoring

The Key Lesson: Human-AI Collaboration

Not Always Perfect Magic

What I Learned

Getting This Setup Yourself

Where This Is Going

Summary

A Git feature I should've met sooner!

Why, You Ask?

The Problem With the "Normal" Way™

Enter: git worktree

Examples

List all worktrees

What's the Catch?

Why You Need This in Your Life

PowerShell with oh-my-posh

Why, You Ask?

Step 1: Install oh-my-posh

Using `.prompt.md` Files

Enter: `git worktree`