Fifteen years of reverse-engineering undocumented systems, migrating legacy control software to new hardware, and rebuilding engineering practices from the inside, most recently leading an AI-assisted legacy modernization effort at a research and manufacturing lab. Now applied full-time to the question every engineering team is quietly asking: is our codebase actually safe to hand to an AI coding assistant?
Is your team sitting on a codebase nobody fully understands anymore?
Are you being told AI coding tools will make your developers faster, and finding that promise doesn't hold up against fifteen years of undocumented C++?
Are you worried the next AI-assisted change to your system will look fine, and be wrong in a way nobody catches until it matters?
It would be nice if legacy code were simply old code, code that still works, just written a while ago. But it never is. It's code with decisions baked in that nobody remembers making. It's code where the comments stopped a decade before the requirements did. It's code that runs a piece of physical equipment, and where "the AI generated a plausible-looking fix" is not good enough.
No matter your need, I can help you make sense of it on your terms.
A one to three week review of your codebase: what's safe to automate, what needs a human in the loop, and what needs to be reconstructed before anyone should touch it.
details →Embedded engagement to reconstruct architecture and requirements, then modernize, including AI-assisted refactoring where it's safe and useful.
details →Firmware, motion control, and real-time systems for hardware that doesn't have an off-the-shelf solution.
details →What is the true condition of your codebase, and is it safe to hand to an AI coding tool?
Most engineering leaders evaluating AI coding assistants are asking the wrong first question. The question isn't which tool to buy. It's whether your codebase has the context, structure, and documentation an AI tool (or a new hire) needs to work in it safely. Most legacy codebases don't, and no amount of tooling fixes that on its own.
I review your codebase the way I'd review one I was about to inherit: what's well-understood and safe to automate, what's fragile and needs a human in the loop regardless of tooling, and what's simply undocumented and needs to be reconstructed before anyone, human or AI, should touch it. I've done this kind of reconstruction work for over a decade, including rebuilding a proprietary algorithm from scratch after the engineer who wrote it, and all record of how it worked, had already left.
You've decided your legacy system needs to change. The question is how to do it without breaking what already works.
I know that legacy modernization done badly is worse than doing nothing. I understand that a rewrite can quietly drop requirements nobody wrote down the first time. I've seen what happens when a system that controls physical hardware gets handed to a team, or a tool, that doesn't understand what it's touching.
This is the deeper engagement that follows an audit, or that I can scope directly if you already know where the risk lives. I embed with your team, reconstruct the architecture and requirements your system was actually built on, and do or directly supervise the modernization work itself, including AI-assisted refactoring where it's safe and useful. I've led a complete legacy control system transition to new hardware with full requirements traceability and zero disruption to the equipment it operated, and I most recently led exactly this kind of modernization, using the same agentic AI tooling I'd bring to your project, on a research lab's legacy codebase.
Talk through your migrationDo you build hardware that needs software nobody else quite knows how to write?
Firmware, motion control, real-time systems, and the software that sits directly on top of physical equipment are a different discipline from general application development, and it shows the moment something goes wrong in production. This has been the core of my work since 2010: firmware for high-precision positioning equipment, real-time control systems for robotics and motion platforms, and the software layer connecting custom hardware to the tools that manage it.
If you need software built for hardware that doesn't have an off-the-shelf solution, this is where I've spent most of my career.
Discuss your hardware projectI started Portable Knowledge in 2010, after nearly a decade building radiographic imaging software in an FDA-regulated environment. Since then, I've been embedded inside client organizations, more often than not the ones with the codebase nobody wanted to touch.
I've reverse-engineered algorithms after the person who understood them was gone. I've moved safety-critical control software onto entirely new hardware without losing a day of operation. I've rebuilt broken development practices from the inside, leaving a team better equipped than I found them. Most recently, I did the current version of this work at a semiconductor research lab, standardizing how the engineering organization used AI coding tools against its own legacy systems, before that engagement wrapped up in mid-2026.
AI tooling didn't create this work. It made it faster, for the people who already know how to do it.
I'll tell you, plainly, what I think it needs, whether that's an audit, a modernization engagement, or just an honest answer about whether AI tooling is a good fit for it yet.
Technology on Your Terms.