Dominic Hanzely

Systems architecture & integration · Minnesota — remote or Twin Cities

I work at the seams. Nearly every interesting problem I have had is the same problem in different clothes: keep a system running while the thing underneath it changes.

A lot of that work has meant putting incompatible systems behind one coherent model, then evolving that model without breaking what depends on it.

BuzzFeed, 2015 to 2026

Software Engineer, 2015. Senior Software Engineer, 2017. Staff Software Engineer, 2022.

For eleven and a half years I was a continuous technical thread through BuzzFeed's content-distribution platform: about thirty-five services abstracting six third-party publishing APIs (Facebook, Instagram, YouTube, X, TikTok, Threads) behind a single model of drafts, jobs, and credentials, fed by an event-driven automation pipeline. I was there at its inception, operated and evolved it through a decade of production use, and became its second-largest backend contributor.

The work I would actually want to talk about:

What I am building now

Since July 2026 I have been building Uncompose, an open-source toolkit that separates recorded music into stems, alone, in public. I have played guitar for forty years, and it began with a practice problem I wanted to solve: isolate the part you are learning, keep the audio on your own machine, and be honest about how good the separation actually is.

It is three Rust command-line tools sharing one command namespace. uncompose does the separation, over a runtime-provisioned PyTorch engine. uncompose-project keeps a portable manifest of assets, derivations, and evaluations. uncompose-compare is a blind A/B listening workbench with an embedded browser frontend. All three are published on PyPI under MIT.

The architecture is the part a résumé cannot tell. The separation models are Python and PyTorch; the Rust core never links against them. It provisions the engine environment at runtime and drives it across a process boundary, with a fake-engine crate as the test seam and an acceptance suite that runs against the installed artifact, so engines can be swapped, pinned, and faked without touching the core. The tools themselves are connected by documented contract rather than shared code: an external-dispatch convention, where uncompose finds uncompose-* subcommands on PATH, plus versioned JSON schemas with integrity states, atomic writes, and advisory locking, so each tool ships, versions, and fails independently. Listening comparisons run blind by design, with identity concealment and psychoacoustic loudness matching tested in their own harness, because an evaluation you can peek at is not an evaluation.

48 seconds, reproducible on any Linux machine: the demo slice builds a project from synthetic stems (seeded noise, no GPU), then a tampered file fails uncompose project verify. The stems are fake so the demo runs anywhere; the manifest contract is the real one.

It is also where my current engineering practice sits on the public record. I work spec-first, and AI agents do the implementation, gated by human review: thirty-plus architecture decision records and roughly 135 issues and 80 pull requests across the family, agent-authored branches merged through review, releases tag-driven with trusted publishing to PyPI and no long-lived credentials. That workflow is a big part of how first commit to three published packages and a live site took thirteen days, in a domain that was new to me.

uncompose.org →

Before that

Contact

email@dominichanzely.com · résumé · uncompose.org

software that is {test,read,maintain,extend,st}able