A measurement tool grew a whole signal chain this week
I spent a good chunk of this week building out a cross-platform audio measurement tool — the kind of thing that lives at the intersection of DSP and instrumentation: a signal generator (pink noise, white noise, sine sweeps, warble tones), a target-curve fitting engine, and a snapshot store for capturing and comparing measurement runs, all shared math running on both iOS and Android.
This is the part of the job I actually care about — deciding how a pink-noise generator should be band-normalized, how a target curve auto-fits to a captured spectrum, what "frame-stamped weighting" needs to mean so overlays on a live render don't drift out of sync with the audio. None of that is coding in the conventional sense. It's systems design: define the signal chain, define the math, define the failure modes, and let AI implementation handle turning that into working Swift and Kotlin.
What made this week interesting wasn't the feature list — it was how many real, non-obvious bugs got caught before they ever touched a device.
Real-time audio is unforgiving, and AI review found the sharp edges
Audio-measurement software can look perfectly fine right up until it is used under real-world conditions. Then a tiny timing problem becomes an audible glitch, a capture method introduces artifacts, or a control simply stops responding. Those are not cosmetic defects in a measurement tool; they are reasons to stop trusting it.
This week's review rounds found examples of all three. The noise generator had a hidden source of audio glitches. The capture approach could leave subtle artifacts in a measurement. One menu action could appear available and then do nothing. Each issue was easy to miss in a casual review, yet each could make the finished app feel unreliable.
None of these came from me staring at code. They came from structured adversarial review — multiple passes, each one looking for a particular kind of failure: audio stability, interruptions, or differences between the iOS and Android experience. That is much more useful than simply asking whether everything looks right.
Running an actual review board, not a rubber stamp
The pattern that's crystallizing across my whole portfolio this month: don't let one AI vendor review its own work. On the web app side, I ran a full audit this week — 0 critical, 8 high, 14 medium, 7 low findings — and drove every single one to zero before calling it done. The high-severity batch was money-path correctness and paid-output integrity; the mediums included things like an auto-revoke on refunds that wasn't wired up and copy that overstated what the product actually guaranteed.
The structural trick is cross-vendor review: whichever AI vendor wrote a piece of code, a different vendor reviews it — and critically, the reviewer gets the raw diff, not the writer's self-assessment of what it did. Feeding a reviewer the writer's own summary measurably suppresses how many real issues it finds; reviewers are more skeptical of code with no accompanying "I did X and it's correct" framing attached. It's a small methodological detail, but it's the difference between a review that rubber-stamps and one that actually finds things.
A newer landing page (a pre-launch waitlist experiment) went through the same treatment before it ever saw traffic: a 21-finding pre-publish review, driven to zero before launch, covering things like session-bound pricing that needed to stay consistent per visitor and a rate limiter that needed to fail open rather than closed under load. Getting a second (and third) adversarial opinion before something is public, rather than after, is turning into the actual quality gate — not tests, not linting, but a standing review board made of AI vendors that don't trust each other.
The shape of the work
Across the portfolio this week: 169 commits, 13 active projects, everything from DSP feature work to a real-world outbound-call demand test launching with a proper consent gate, to CNC-machined packaging design for physical hardware. The common thread isn't any single feature — it's that the actual bottleneck has moved from "can I build this" to "how many independent, adversarial eyes can I put on it before it ships." Three AI vendors arguing about the same diff, each unable to see the others' blind spots, turns out to be a much better review board than one very capable model reviewing itself.