I work on systems no one fully understands anymore — the twenty-year-old application that
one report depends on, and the network keeping the business running. When AI agents can compromise a business with no human involved,
there's no such thing as "too small to be a target".
You can't defend what you don't understand. Own your system.
Assume nothing · Verify everything · Know your risks
I came up through mathematics, physics, and systems engineering, and spent my early years on computer vision and reinforcement learning. Working on these projects in the early days of AI required a deep and intimate understanding of the underlying systems. I couldn't rely on what other people said they knew, I had to find out for myself. That's when I started developing the skills that have proved to be valuable to SMBs with technical debt.
These days that means rebuilding load-bearing internal software — the sort of thing a company depends on daily and cannot afford to have break for even an afternoon. My day job is healthcare systems: EDI, protected health information, and the kind of compliance pressure that makes you careful about what ends up in a log line.
My security work grew out of the same instinct. Reverse-engineering a legacy application and testing a network are the same discipline pointed in two directions — one asks what a system really does, the other asks what it really allows. Neither question is answered by reading the documentation, if it even exists.
When I port an old query, it goes over verbatim first, and diffed justto make sure. If something looks like a bug, I mark it and ask. Production often depends on something that was never documented. "Obviously wrong" and "safe to change" are different claims.
Reverse-engineering means most of your questions have nobody left to answer them. I keep the unresolved ones written down and unresolved, rather than filling them with something plausible. A confident wrong guess costs far more than an open question.
The measure of a good cutover is that Monday feels like Friday. No retraining, no surprises, no week of triage. If people notice the new system at all, it should be because I fixed something they hated.
I work daily under rules about protected health information. Log identifiers, never
contents, and adhere to zero-trust principles. Assume every line you emit is a liability. That discipline doesn't
come off when the data is less regulated.
Best practices are best practices for a reason.
Sometimes a compromise in your security is necessary or simply the best option. Internal-only networks gated behind a receptionist have different needs than public-facing system. I proactively test for, document, and patch potential attack vectors to make sure you're well defended, and knowledgable about the real attack surface you're left with.
Every serious project of mine carries durable context files: what's settled, which legacy quirks are load-bearing, and which questions an agent must stop and ask about. An errant hallucination in a mission-critical system carries real costs that most business cannot afford.
Your help desk is an authentication bypass. An attacker calls, impersonates an employee, and gets MFA reset — every "verification" question they're asked is a fact that leaks. Vixxing puts a live possession check on the call itself: read me the six digits, or we're done.
View on GitHubA full replacement for a legacy EDI 837 claim viewer nobody had documentation for. Ported from typed DataSets and report definitions, rendering print-accurate UB-04 and CMS-1500 forms, gated behind Azure identity checks with a per-view PHI audit trail.
Private engagement, contact if interestedTwo agents learning a task together in the browser — a manager choosing sub-goals, a worker executing them. They normally poison each other's value estimates. I fixed it with profit sharing: the worker earns a cut of what the manager's command actually gains. Plus Hindsight Experience Replay (HER).
View on GitHub Internal toolingThe office floor plan, retired from the spreadsheet it lived in. Staff find their desk or claim a free one; admins redraw the map without anyone opening a database.
View on GitHub Legacy migrationA company directory built over a legacy Microsoft Access database — real reporting hierarchy, searchable, with birthdays and work anniversaries on the front page. The Access file kept working the whole time.
View on GitHub MoreDesktop launchers, sprite tooling, normalization visualizers, and the assorted small things that exist because a tool was missing and building it took an afternoon.
Browse GitHubDrawing a map, from ingress to egress
Whether the goal is to replace something or to break into it, the sequence barely changes. Most of the work happens while reading code and testing behavior.
You end up with artifacts you keep regardless of what comes next: a written map of how the thing really behaves, the list of what nobody could answer, and an honest account of what I'd trust it with.
Read everything that survives — source, configs, generated schemas, whatever reports the old system printed. Testing always answers the questions that documentation couldn't.
Write down the real behavior, including the parts that look wrong, and separate what's confirmed from what's assumed. Assumptions get labeled as assumptions.
Rebuild or attack against that map and compare to reality. If the rebuilt behavior doesn't match legacy behavior, or if a predicted vulnerability doesn't really exist, then the map needs updated.
Documentation someone can act on without me: what changed, what's still unknown, and what I'd fix first. No dependency on my continued involvement.
The most useful conversations I have start with somebody admitting they aren't sure what a system does anymore — or what would break it.