Most of my engagements are covered by confidentiality agreements, so this page describes method rather than clients. If you want references, ask; I will arrange them privately.
The first question on a legacy Windows codebase is never “what is wrong with it.” It is “can I build it.” A surprising number of shipped products cannot be rebuilt from source by anyone currently employed, and every other question is downstream of that one.
So the first days of an engagement go to reproducing the build: toolchain versions, missing SDKs, undocumented environment assumptions, the machine in the corner that is the only one that works. The deliverable is a build that runs on a clean box from a checkout, documented. Teams are often surprised at how much anxiety that single artifact removes.
I read a codebase before I propose changing it, and I read it in a specific order: entry points, threading model, error handling, then the parts everyone warns me about. The warnings are informative. Code that people are afraid of is usually afraid-of for a reason that nobody has written down.
I do not recommend rewrites. Almost ever. A rewrite trades a system with known bugs for a system with unknown ones, and discards the accumulated knowledge encoded in every strange conditional somebody added at 2am because a customer was down. The work is nearly always to make the existing system changeable again, incrementally, with the product shipping the entire time.
Legacy native code is usually untestable rather than untested, which is a different problem and needs a different remedy. It means finding the seams: places where behavior can be observed or substituted without restructuring the whole program. Characterization tests come first; they capture what the system currently does, including the parts that are wrong, so that intentional changes can be distinguished from accidental ones.
The goal is not coverage as a number. The goal is that you can change the thing and find out.
Crashes that resist diagnosis are usually one of a small number of things: lifetime and ownership errors, threading and reentrancy, or an assumption about the environment that stopped being true. Native Windows adds its own catalog: handle leaks, COM apartment mismatches, DLL loading order, and code that has been quietly relying on undefined behavior since a compiler upgrade three years ago.
Method is unglamorous. Reproduce reliably before investigating. Read the crash dump properly rather than guessing from the stack summary. Bisect. Instrument. Resist the theory you like best until it survives being tested.
I use agentic coding tools on every engagement, and I will tell you exactly where they help and where they do not.
They are very good at breadth: reading unfamiliar code, exhausting the possibility space, writing the tenth variation of a test, and doing the format-spelunking grunt work that otherwise eats afternoons. They are not good at judgment, and they are confidently wrong in ways that are expensive in systems code. Every line that ships is reviewed by me, and I do not bill you for velocity that produced something neither of us can maintain.
If you want an honest assessment of what AI tooling would actually contribute to your codebase, that is something I will measure rather than assert.
A written assessment you own. A build that reproduces. Code under test. Changes delivered incrementally against a working product. And a clear account of what is still wrong, because there is always something still wrong, and you should hear it from me rather than discover it later.
